This is part three in a series of posts, you can find the first one here. In part two we looked at linking environments together. When you have linked F&O to a Dataverse environment with the purpose to start utilizing dual-write, it’s time to think about your specific integration scenario and what templates to start from. Most likely you will need to make modifications to mappings and create your own table maps.
What’s ALM and what to think about related to dual-write? In which should you do your changes to the table maps? How to get your changes to the other environments? That we will look at in this post.
Findings
- Make it a habit to follow the instructions in Microsoft Learn for your specific scenario. (Different templates depending on your scenario)
- Even if you choose to follow one of the common scenarios, you will most likely need to adjust table maps and/or create new table maps.
- Modified and new table maps – ALM for table maps are done with Dataverse Solutions and should be done in a Dataverse DEV environment and then be moved to Test/Production.
- Make it a habit to look for updates under Dynamics 365 apps in Admin Center under your environment and keep an eye on this page: What’s new or changed in dual-write.
Extending the templates
This “OOB integration framework” comes with a set of templates for sample integration scenarios, such as unification of the F&O and Dataverse data model for Customers and Contacts (Global Address Book Templates) or working with Sales, managing e.g. Quotes and Sales Orders (Quotes to Cash templates).
You can utilize and customize these templates according to your own business requirements and you can extend with new integration scenarios. Always follow Microsoft Learn each time you set it up, the official documentation is updated constantly and new templates might have been added.
See it as templates rather than an “OOB integration”. It will most likely not be suitable for you to run it as is. You will need to think about the intended use in your specific case. A lot is two way sync in the table maps templates, but some information is best updated in F&O only and vise versa, depending on the intended use and the business processes in your specific case.
So in which environment should I do the changes to the table maps and create new table maps? In the F&O environment which corresponds to the Dataverse DEV!
What’s ALM?
ALM stands for Application Lifecycle Management and in this context it’s how dual-write table maps are created, modified and moved between environments. Since it’s handled in the same way as Dataverse configuration and deveopment, I’ll bring that up too. You can read more about ALM for table maps in Microsoft Learn, Application Lifecycle Management.
ALM for Table Maps
The ALM story for table maps is the same as Dataverse Solutions. A Solution can contain table maps but also Dataverse config and code. This is your “source” for the Dataverse configration and development and it should be saved/put in a version control system. Learn about Azure DevOps Pipelines or Git Hub Actions for Power Platform in order to automate your deployments and save solutions for version control.
So the mappings (table maps) are stored in Dataverse. But how do they end up in there? Currently, we make changes to mappings in F&O. There is a “dual-write” UI under Data Management -> Dual-write. There you manage e.g. what table maps should be turned on and not, versions of table maps and the initial synchronization.
Here I see a risk that a F&O consultant without Dataverse expertise easily could miss this part and to changes to mappings directly in test/production. You need basic understanding about Solutions and you will benefit a lot with having experience from working with solutions. Change table maps in DEV and move it to the other environments though Solutions. In DEV we haveour unmanaged Solution, in the other environments we have managed solutions.
Dataverse config and development
Now that I have brought up Dataverse and Solutions related to dual-write and the table maps, I might as well let you in on other parts that are also handled in Solutions.
Use the created Business Units and set up appropriate Security Roles to make sure the users are authorized to the right information and to lock Dataverse side updates for certain tables. Make sure to modify the model-driven app you intend to use (e.g. the native app such as Sales Hub or a custom app) so that it includes the new tables which come with the dual-write concept (e.g. Party table in the GAB integration scenario).
You will most likely want to make other Dataverse configuration as well. Such as new columns, modify forms and views and you might also need some custom business logic.
Custom Security Roles, app, columns, forms, view configuration and custom business logic (plugins, Power Automate cloud flows) are all example of components that can be moved to test/production through Solutions.
Manage updates of first-party solutions
In PPAC, under your environment you have access to Dynamics 365 apps and you can check if there are updates available to be installed. Here you will find updates to dual-write related solutions. Make it a habit to look for updates and update in a test environment first.
I have seen some dual-write solutions getting updated automatically by Microsoft. Hopefully there is a good reason for that and we will not get into trouble in our customer projects.
Do you have any ALM related stories to tell? I want to hear about it in the comments to this post!
Photo by Jason Leung on Unsplash
Carina M. Claesson 