Dual Write: Implementation Considerations

MS365 Dual Write Instance Strategy

Dual Write implementation is based on instance strategy, which supports the only one-to-one link between F&O apps and CDS instance. Keep in mind the following design considerations:

1) MS only supports the instances for F&O and CDS to be hosted in the same tenant. In case you have a CDS instance in a separate tenant – that will not work as it is not supported;

2) The other thing is for the best possible performance. You want to reduce the latency between these two environments, so the recommendation is to host them in the same Azure region. In case you go for North America F&O, you want to do the same for your CDS instances;

3) The last thing to consider is that Dual Write out of the box scenarios can be used only with D365 apps, which have enabled CDS instance. When you create the CDS instance, there is an option of either treating it as a blank CDS instance with the database but without D365 apps, or you can include them at the installation. There are dependencies on those apps, so MS only supports installing the Dual Write application orchestration package on any CDS instance of that type.

Let’s move to things you want to avoid. First things first, avoid hosting F&O files and CDS instances in two different regions with higher latency as that will reduce the overall performance. You cannot link F&O files and CDS instances across different tenants. So even if you want to, that is not possible, and it’s not supported.

Also, you can’t link an F&O apps instance to multiple CDS instances and vice versa. So one of the common patterns, is where people have split their CDS instances by workload. For example, there is one CDS instance for customer service workload, another one for sales workload. If you try to map these two in a single file and operation environment – there will be an error, as Dual-Write does not support that. It is recommended to combine CDS workloads into a single instance and link that F&O.

Finally, you cannot use the out of the box scenarios with a blank CDS instance, the one which does not have any Dynamics 365 apps. If you insist and want to try it out, the installation will fail.

Initial Write

Initial write is best used to create initial data of low volumes. Think of that as the right technology to create the initial reference and set up data (even master data if it’s on low volume). 

In case your data volume is much higher, where you have hundreds of thousands or the millions, you are better to do data migration separately into each app before even enabling Dual-Write. 

MS team encourages to plan for testing any Dual-Write related data migration and data sequencing ahead of the cutover. Before going live, make sure you have that adequately covered in your cutover scenarios as well.

The thing you want to avoid is using an initial write as a data migration replacement. When we get to the data migration mode, you have either very high volume data or very high transformation complexities. Typical data migration exercise requires special performance and error handling considerations. This is suitable to be done outside and before enabling Dual Write.

Application Scenarios

When it comes to application scenarios, there are a lot of out of the box integration scenarios provided by Dual write (66+ entity maps). 

The recommendation is to evaluate the available out of the box scenarios. Don’t think about Dual Write as a pure infrastructure capability or an integration tool. 

You want to evaluate those out of the box scenarios, understand what they are, their limitations, and only then leverage them into your final solution.

Keep in mind that you cannot run two different versions of the Prospect to Cash Scenario (Dual Write and Data integrator) side by side. For that, D365 has a migration path already in preview for you to move you from the data integrator to the Dual Write version.

Applications Roadmap

Moving along to the application roadmap, the general recommendation is to stay along with Dual Write journey and future scenarios. Join the insider program & dual write yammer group to get updates and also, to share your feedback.

You can minimize customizations around knowing roadmap items such as Global address book concepts in CDS (i.e., the ability to sync multiple addresses for a customer); Default dimensions concept in CDS, and project operations integrations.

If you need to build a custom solution – minimize it around those known roadmap items. So as soon as there are out of the box solutions are released, you can simply integrate those into your system.

Data & Error Management

When you manage the data, keep in mind that if you want to run a high volume-bulk-operation on Dual-Written data and get the best possible performance – pause any related Dual-Write maps during bulk operation. Resume only upon its completion for an asynchronous catch-up.

The general recommendation in regards to error management is to configure alerts, setup, and notifications proactively. Pause Dual Write during planned outages and maintenance windows, especially if you know that users will be using the system to avoid them getting some unexpected error messages. 

Application Lifecycle Management

Any Dual-Write related customizations can be added to power app solutions to help you with your ALM story, so MS encourages you to use that, as well as Azure DevOps, to store those solutions instead of moving things manually.