In my previous post, we learned company semantics as well as security construct in Dynamics 365 FO & Dataverse especially when Dual-write & Virtual entity technologies are involved.
In this blog post, you will learn how these two different concepts are getting configured in multiple legal entities' business scenarios and how it works under the hood.
We will also understand what product offers as part of Out-of-box capability & some of the recommended design configurations based on my learning.
Business scenario
CliffsNotes is a fictitious organization, planning to implement Cross apps functionality using Dynamics 365 Customer Engagement Apps, Power apps & Dynamics 365 Finance and Operations Apps. CliffsNotes operates in India & Europe geographies as part of its line of business. Therefore, it was needed to have more than one Legal entity to manage operations and track cost, revenue, and global reporting. The business team was expecting to implement strong control on record ownership as well as security boundaries across apps i.e., Dynamics 365 Customer Engagement Apps, Power apps & Dynamics 365 Finance and Operations
What are the benefits of considering all these options when developing Dynamics 365 Cross-apps solution?
When it comes to the implementation, no doubt one dynamics, one platform offers lot many features to customers. However, it is important to understand how canonical and non-canonical implementation models to suit company and security construct in Cross-apps scenarios.
In a nutshell, what product offers an out-of-box approach, and what are the other supported options?
Let's understand, that the recommended approach is to implement Business units in Dataverse equivalent to Dynamics 365 FO LEs
And why it is recommended because it simplifies the solution design by enabling one-to-one mapping of Dynamics 365 FO LE with business units in Dataverse.
So, let's now study what works best for this business scenario.
Solution approach recipe
Let's jump in and understand the solution approach for the above business scenario which is somewhat Canonical implementation.
As I mentioned earlier, business units and companies are different concepts and do not need to be the same thing.
As part of CliffsNotes Implementation, it is recommended that business units and companies maintain one-to-one records. By default, Dataverse contains company records associated with business units. It makes it easy to create a company in D365 FO and then exposes it to Dataverse with the default securities and it works by default.
As you can see in the above diagram, we have a ITCO company in D365 FO and the same company exists in Dataverse as well. If we talk about business units, they fall under the root business unit. And every time you create a business unit, Teams is included by default.
In addition to creating default Teams, Dataverse also establishes dedicated Teams for Dual-write related to that business unit. i.e., ITCO DW
In nutshell, we have two companies in D365 FO and therefore two companies in Dataverse and related business units.
By design, business units roll up to the root business unit. You can, however, change it according to your business requirements. In addition, it changes the visibility of records in Dataverse in accordance with this change. However, it will not change the company record since the company and business unit are separated in Dataverse for Dual-write.
Additionally, it does not affect visibility in D365 FO.
What's under the hood
Creating a record in D365 FO, associated with DataAreaid, and the user who created that record may not exist in Dataverse. Dual-write infrastructure ensures that records move to Dataverse with the correct company id and who is the owner of this particular record.
The default owning team created by the Dual-Write setup is the owner of a record. By default, it means that any user with access to the ITCO company in D365 FO will create a record in Dataverse and will be able to see that record in Dataverse if they are also assigned to the ITCO business unit.
The company record in Dataverse has a field called "Default owning team" and when the record is created in D365 FO and moves to Dataverse then this field indicates which team owns the record. Later on, you may need to change the same depending on the business scenario.
Supported/Valid Configuration
Conclusion
By understanding the above business scenario, it is clear that CliffsNotes has dedicated business units in different countries and also has dedicated security boundaries for Customer Engagement, Power Apps, and Dynamics 365 FO apps, and no cross-sharing business roles are involved. Implementing a standard OOB model will help business users to work with the record associated with it for modification and deletion.
Thank you for Reading - Let's Connect!
Enjoy my blog? For more such awesome blog articles - follow, subscribe and let's connect on LinkedIn , Twitter ,YouTube
Stay tuned!
