Dual-write async in finance and operations apps FAQ (preview)

[This article is prerelease documentation and is subject to change.]

Note

Community interest groups have now moved from Yammer to Microsoft Viva Engage. To join a Viva Engage community and take part in the latest discussions, fill out the Request access to Finance and Operations Viva Engage Community form and choose the community you want to join.

This article provides answers to frequently asked questions about dual-write async in Microsoft Dynamics 365 finance and operations apps.

Important

This feature is a preview feature. Preview features aren't meant for production use and might have restricted functionality. These features are available before an official release, so that customers can get early access and provide feedback.

What does "eventual consistency" mean in the context of dual-write async?

In eventual consistency for distributed systems (finance and operations apps and Dataverse), data is available for a finite time. It eventually becomes consistent, based on the business validations and logical constraints that one platform or the other imposes. The async process decouples live transactions from committing the transaction at the same instant. The data movement is offloaded to an internal processing queue, so that a background process can sequence and transfer it. Dual-write async doesn't replicate the transaction, because platform limits affect the performance of the data movement and constrain its scalability. Dual-write async uses parallelization and dependency charts to scale the data movement in an optimal way, as defined by the parameters of the integration job.

Which type of entities should I use for dual-write async?

Use entities that you can group as part of a single transaction and that you expect to have high volumes. For example, a worksheet header and worksheet lines are grouped into a single transaction, where one or more header rows might have multiple child rows. During live synchronization, these entities routinely fail because of transaction, timeout, and size limits. Check for functional correctness of the data movement based on the application logic, because some logic might be coded for real-time synchronization, not for eventual consistency.

What entities are supported for dual-write async?

Some application entities that are being evaluated during public preview might not work for dual-write async.

Which type of operations does dual-write async support?

Dual-write async supports only create and update operations. If a transaction has a delete operation, the operation goes through as a live synchronization operation and skips the async pipeline. Delete operations that are dependent on relationships can't easily be removed from either system, or they have a greater risk of failure in an eventual consistency model.

What happens if a transaction has entities configured for live synchronization and dual-write async?

If a transaction has a combination of entities that are configured for live synchronization and entities that are configured as asynchronous, the transaction fails. The error message shows which entities are misconfigured. Application customers need to fine-tune their dual-write async and live synchronization configuration. A transaction should have either all asynchronous entities or all synchronous entities. Deletes are an exception to the rule, because they're always synchronous.

What does "primary for conflict detection" mean?

If the same record is edited at the same time in both systems, conflict detection determines which side is primary and overrides the record accordingly. For example, if finance and operations apps are primary for conflict detection, the finance and operations apps record overrides the Dataverse record. The update from Dataverse to finance and operations apps is rejected. Because an eventual consistency model is used, conflict detection depends on a snapshot in time. It doesn't depend on the record time, because records might not have a time field, and clocks aren't coordinated between systems.

What impact does the sequencing of entities have in a group?

Sequencing defines the priority order of execution. The lower the number, the higher the priority order of execution. This sequencing helps address referential integrity from a data perspective.

How are errors categorized?

Errors are categorized in the following way:

• Application failures – Failures that result from business validations or logical errors are categorized as application failures.
• System failures – Failures that result from unresolvable system errors are categorized as system failures. The system can retry these failures. During a retry, if the record version is the latest, it's synced.
• Concurrency failures – In eventual consistency models, the records that are being processed sometimes aren't the latest versions. In these cases, the system skips the records and categorizes the failures as concurrency failures. This behavior helps prevent multiple phantom updates for the same record. These failures can't be retried.
• Conflict failures – Failures that encounter a conflict are categorized as conflict failures. These failures aren't visible in the synchronization errors. However, they're visible in the back-end table. For more information, see the What does primary for conflict detection mean? section of this article.

Does dual-write async use DIXF for import into, or export from, finance and operations apps?

No, dual-write async doesn't use the Data Import/Export Framework (DIXF) to import data into, or export it from, finance and operations apps. Instead, the technology stack uses internal sequencing and queues to manage data movement. The queues don't hold data. They hold references to information to help with data movement.

How does dual-write async compare to the asynchronous data synchronization capability of the Data integrator tool?

Data integrator also supports asynchronous data synchronization between finance and operations apps and Dataverse. However, some fundamental differences exist between the two options, besides the technology stack. The following table describes these differences.

Capability	Dual-write async	Data integrator
Support for bidirectional synchronization	Yes	No. Custom logic is required.
Loopback control and conflict management to ensure data integrity	Yes	Application layer customizations are required to ensure that bidirectional synchronization doesn't trigger multiple writes of the same record.
Support for functionality of dual-write synchronization, such as templates, company striping, and out-of-box default mappings	Yes	There are limited templates, and the functionality isn't applicable to dual-write maps.
The nature of the synchronization	Just-in-time events drive synchronization.	Synchronization is based on a schedule. The number of recurring jobs imposes limits.