As it stands right now, the CRM and former AX functionality has been wrapped under the Dynamics 365 umbrella. All nice, but with the changes made to the former Dynamics AX to bring it to a modern state, and a cloud model, the old style integrations have to be “adjusted”.
As announced by Microsoft, there is an integration planned, but few month into the new platform, we’re not seeing it just yet.
The roadmap site, at roadmap.dynamics.com is now publishing some details on the expected functionality. The integration is described under the heading “Prospect to cash integration of Dynamics 365 for Sales and Dynamics 365 for Operations”. As you can see, it now all follows the business functionality model familiar to the platforms.
The proposed integration leverages the somewhat recently released Common Data Service. If you still don’t know what that is, see the description HERE.
The idea of this proposed integration is to allow users to start the sales process in Dynamics 365 for Sales, and complete the order fulfillment on Dynamics 365 for Operations. This leverages both platform functionalities for their strengths. Or does it? Let’s look at the details available so far.
Accounts and Contact
For both Accounts and Contact, the plan is to sync these records from Sales to Operations.
Nagging question here being what happens if these records get updated on the Operations side, or simultaneously on both sides? No details yet.
Workaround is to have editable access only on the Sales side, and read-only on the Operations side. As such, financial or operations users must have a Plan 2 license most likely, or possibly get away with a Team Member license for light usage. For additional licensing implications see the licensing guides, as linked to in THIS earlier post.
Product Catalog
This is to be maintained in Operations, and synchronized back into Sales.
Question here is how bundles and packaged offerings for up-sell are going to be handled. An assumption is that these groupings will be created and maintained on the Sales side, which means that a user managing products must use both Sales and Operations for maintaining the product catalog. Or maybe have a team/user maintaining the products in Operations, and another team/user managing bundles and sales artifacts on the Sales side.
Again, licensing implications, as well as additional coordination between the platforms and/or users/teams.
Possibly 3rd party products might actually help here a little? There’s an opportunity.
Quotes
These are actually following the same model as in the previous versions with the integration. Quotes are fully created and managed on the Sales side.
One could argue why even synchronize them into Operations, but this is in line with the old model where you could jump to the former AX either at the Quote or the Order level. See the next paragraph on Orders.
Orders
Now it looks like the recommendation is to proceed all the way to the order generation in the Sales module, and then sync to Operations at the Order level. This should be ok for most situations.
Invoices
Invoices are to be generated and processed, as expected, on the Operation side. No issues here. They are to be synchronized back to Sales for visibility, so I would see the Invoice records as a complete read-only on the Sales side. The financials implications of changing an invoice can not really be handled on the Sales side to begin with, so there is no real reason to have these records editable on the Sales side.
Conclusion
While this puts us on the right path, somewhat, it is far from ideal for the following reasons:
Licensing implications could possibly require users to hold a more expensive license to be able to handle a complete business flow along with related needs.
This only covers a standard sales process. As soon as you step outside of this model, the amount of work involved could easily become similar to simply starting from scratch. This is just an assumption right now, we’ll see.
While leveraging the Common Data Service has it’s advantages, including the use of Flow and Power Apps, you now have data in flow in 3 places that must stay in sync. This brings up the next point.
Real-time or near-real-time possible issues. As discussed in Accounts and Contact, if you don’t lock the data on one side to be read-only, simultaneous updates to the same record, in Sales, Operations, etc. applications, could potentially result in unexpected results and overwrites. A robust solution with proper record locking on one side when edited on the other side becomes essential. The roadmap description does not hint to any of this. This is potentially the biggest problem here.
In the “Fast implementation” heading of the article, one work sticks out: templates. This begs the question: is this really going to be a production ready option? Or are we back to the “template” integration options available with the old versions, which almost all the times needed to be extended? Or maybe 3rd party solutions fill-in the gap? There’s an opportunity for 3rd party vendors here too.
Until additional details become clear, let’s look at this as what it’s described to be. A possible scenario, that is. A “template”.
Enjoy!
thatcrm.com 
Leave a Reply