The legal entity data aspect of Dual-writes

Dynamics 365 has, for many years been sold by Microsoft as one system even if there are different platforms that are connected. To get F&O and Dataverse business flows to work properly, and to get the platforms to communicate with each other you need to set up some kind of integration. Usually, the low code ones such as Dual-writes or Virtual entities for F&O are used for this (the two are described in this post) but it can also be done by custom integrations.

That F&O and Dataverse are two different platforms that has two different backgrounds is undeniable, but the dual platform setup has many upsides such as getting the flexibility from Dataverse and Power Platform and at the same time, it gets the stability and larger transactional handling from the F&O platform. However, there are some major differences in the underlying capabilities of the systems, and in the mindsets of the people delivering the systems. These needs to be aligned before you can connect the two systems.

Legal Entities vs Business units

Both systems are from a security aspect dividing and placing data in different “divisions”. In F&O they are called legal entities and in Dataverse they are called business units. When you set up Dual-writes you also connect each legal entity that you want to integrate to a specific business unit.

So far so good!

The big difference is that the legal entities, F&O security and data setup is a lot more isolated then the Dataverse’s. In F&O there are some tables that are system global, but they are very few. The most common is that the data is legal entity specific. When something is legal entity specific, and you want to use the same data in several legal entities you need to create the same record several times. If you create the same record several times, it will in integrations also go over several times, meaning it will end up in Dataverse as several records.

Some F&O consultants might argue that you in F&O can connect the records between the legal entities with party ids/ the global address book. They are right in the sense that you do connect the data by pointing the two records to a parent record. Unfortunately, this still leaves us with different datasets on the record (one in each legal entity), so it’s not the same thing as sharing the data between the legal entities.

In Dataverse, on the other hand, you have total flexibility. Just as in F&O, when you create a table, you can define the record ownership to be “Organization” or to be “User or Team” (attached to a business unit). The big difference is that in Dataverse you can also in your security roles allow users to see data records and work cross business units and share data records between business units in a way that you cannot do in F&O.

Consequences on different data types

To really understand what effects this integration has to the two systems we will break it down in data types.

Meta data
Typical meta data that you would integrate often has its inheritance from F&O such as customer group, payment terms, delivery terms etc. All of these are legal entity specific in F&O. If we take payment term as an example the consequences would be that for each legal entity that has “30 days net” as a payment term set up, a new “30 days net” record will be created in Dataverse giving you several “30 days net” records.

On a form level that’s not an issue because there you can filter the lookups based on a pre-set legal entity lookup value:

But if you in advanced find would like to search for all accounts or quotes that has 30 days net you would need to select all the 30 days net values.

Master data
The two big ones when it comes to master data are accounts/customers and contact persons, they are both legal entities specific and if you are working with/ selling to the same customer in several legal entities that will mean that you will get several records of the same customer in Dataverse as well.

The same thing applies to other master data tables such as vendors, sites, warehouses, and many others.

Transactional data
Transactional data is usually never an issue when it comes to this since its always connected to a specific business unit or legal entity.

App for Outlook

Contact persons are legal entity specific as mentioned above, and we might have several legal entities selling to the same customer, that will lead to that you create the same customer in several legal entities and create the same contact person in several legal entities. Getting several contact persons (with the same email) in Dataverse will then give you an issue since when trying to track an email the App for Outlook it won’t know which contact to track it towards.

Exactly what happens when you do so and how the app for outlook handles this you can read about in this Microsoft learn post.

What’s notable, that isn’t written in the above-mentioned Microsoft learn post, is that if a user does not have read access to a specific contact person in Dataverse it won’t track against it. Meaning that as long as the user that is trying to track is only allowed to see one of the contact persons with the same email address you do not have an issue.

Usual reactions:

As I wrote in the beginning of this post, depending on what platform a person is coming from there are different mindsets and when explaining what I just wrote above, the reactions tend to diverse.

A typical reaction from a person coming from an ERP/F&O background would be:

“That sounds about right”

since the isolated setup is the backbone of most of the ERP systems.

When explaining it to someone with a CRM/Dataverse background the usual reaction tends to be something like:

No ***** way! This won’t work!!%!?!

since CRM has always been about one customer and getting different divisions to work more together.

This is why it´s super important to align Dataverse implementers, F&O implementers, and end users on how the data setup will look, before starting to set the system up and migrating the data.

Solution

What’s the solution then? There is as always not one solution only that will solve it all for everyone, but for each setup you can find different solutions to different parts of the issue.

Regarding the meta data issues, I have so far not seen that it’s an issue big enough to do something about. The form filter solves a lot and many times the base users are not allowed to read outside of their own business unit so then it´s just a training thing for a couple of super users.

The master data issue is a bigger one especially regarding accounts and contacts. Some setups don’t have several legal entities or down work with the same customers cross business unit and then it’s not an issue. But if they do, the workarounds I have found so far are for:

Accounts in Dataverse to have parent accounts that are connected to a business unit that everyone can read from (either via team sharing or just by having an open security module) and then filtering out the parent accounts from dual-write so they never gets synced over to F&O.

You might also lock some of the child accounts fields from being editable (both in Dataverse and F&O) and having a cascading update on all of them if you update the same field on the parent in Dataverse. The users can then collaborate regarding the parent account.

The catch with that solution is that the transactional data still needs to be tagged with the child account to get the integrations for the transactional data to work. Another downside with it is that you won’t be able to edit very much of the customer values in F&O.

Contacts to restrict end users to only read and edit contacts within their own business unit. At first sight that solution feels a bit obnoxious but when discussing with my clients it is usually not that big of a deal. In other cases, the solution can be that you might not actually need to integrate the contacts and just have them connected to the parent account.

For other master data records, you need to look at what they will be used for within Dataverse and handle them case by case. It might be that other ones of them will need the same parent setup as explained for accounts.

Dual-write taking the fall

In the title of this post I gave Dual-write the blame for the “Legal entity data aspect” which is a bit unfair, in the end this issue comes down to how data is structured between the two platforms and that issue will remain regardless of what integration engine you use.

My number one advice is that you always have a plan and are aligned across the system implementers on how “Legal entity data aspect” should be handled before starting to setup, migrate or develop anything between the systems.

We are looking for Dynamics 365 Finance and Operations professionals, plus other Microsoft Business Applications and Azure skills. If you’d like to hear more, please view our open roles.