
We've had Dual Write setup, and it means if across our group we have a Customer in both Legal Entity A and Legal Entity B in FSCM, we need to represent them in Sales twice (i.e. have 2 account records to represent the same company the group engages with). So when you search for Acme, you end up with two account records for the same company (because their a customer of both LE1 and LE2).
Is there a better way of doing this, whereby one account record can show themselves to be clients of more than one Legal Entity? From the CRM standpoint they're the same company, and we'd want to understand their relationship with our group of companies as a whole.
It feels like we should have one Account, and then a child entity that represents their formal customer relationship with our different legal entities.
Is there a 'best' way of doing this that provides a more 360 degree view of an Account with our whole organisation?
Hi
There are several ways you can go to accomplish what you are asking for but none of these are out-of-the-box. They all require customization. The customization can either be done by coding, low-code-nocode or procuring a non Microsoft product to accomplish this.
One of the first things I usually try to understand in similar use cases is the requirement for near/real-time exchange of data. If you do not have synchronises process that demand data being same across your entire systems domain at all times in near to real-time, then you have more options. Without knowing more details about your exact requirements it is hard to give any definite suggestions but one way could be the following.
Scrap out Dual-write
Enable feature Cross-company data sharing - https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/sysadmin/cross-company-data-sharing (you cannot run Cross-company together with Dual-write)
Setup on finance side logic triggering using feature logic apps, azure function or data events - https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/business-events/data-events
Setup on CRM side logic triggering using logic apps or azure function.
Post the CRUDs for the records and columns you want to have in sync from either CRM or FO to a service bus (if you allow crud in both systems? It might be scenarios you only allow change in FO and not CRM)
Allow both FO and CRM to subscribe to changes in this queue with a logic app or azure function.
WIth this setup you will have all systems using same data with the delay proposed in the service bus and running logic
You can now also easily add any other system to participate in refining your account data.
If you have issues with speed - I suggest you cache all changes in a Azure data lake https://docs.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-introduction or cosmos db if you have environments spread out globally. You can use synapse link to dataverse https://docs.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-synapse.
In this way systems do not need to retrieve the data from the source system when there is a datachange. All systems connect to a central cache of changes.
This is of course very high-level solution. Let me know if you have any further questions. If you find this answer helpful please verify the answer.