Determine the technology approach
When working with dual-write and virtual entities, you need to determine which approach is better for different scenarios in your business. In some cases, both can co-exist, while in others, it might be better to choose one over the other. The following table shows the different attributes to determine which technology might be more suitable in different scenarios for integration or implementation needs.
| Attribute | Dual-write | Finance and operations apps virtual entity |
|---|---|---|
| Scenario | Near real-time CRUD | Real-time CRUD |
| Method | Synchronous (live-sync) | Run-time |
| Direction | Bidirectional | Not applicable |
| Data | Data is duplicated | Data remains in source, which is finance and operations apps |
| Logic | Auto business logic implementation | Auto business logic implementation: you can call OData actions |
| Offline scenario | Catch-up capability | Not supported |
| Development | Finance and operations apps data entity + dual-write entity map + Dataverse table | Finance and operations apps data entity + Dataverse configuration |
| Bootstrapping | Might not be needed for existing Dataverse data | Not applicable |
| Application lifecycle management (ALM) | Finance and operations apps package + Dataverse solution (including entity map solution) | Finance and operations apps package + Dataverse solution |
| User | Runs as S2S call; user doesn't need to exist in both apps | Runs against user context; user needs to exist in both apps |
For example, if you need the system to support offline scenarios for your implementation and continue integration, only dual-write can pause the integration. Additionally, when the systems are up again, dual-write resumes the integration and catches up all data that queued during the outage. Virtual entities don't support this scenario.
If you need to run the integration against the user's security in finance and operations apps, then a virtual entity might be a better solution.
Additionally, virtual entities aren't bidirectional, so in cases where bidirectional is needed for an integration, dual-write would be optimal.
The following tables highlight more dos and don'ts with dual-write and virtual entities to help you decide the right technology for situational needs.
The following table outlines considerations for when you're using dual-write functionality.
| Do | Don't |
|---|---|
| Use dual-write if business scenarios require data to be present in both apps and if data is expected by the business process or logic in both apps. | Use dual-write to duplicate data where business logic is only needed in one of the apps. |
| Use dual-write when it's suitable to harmonize the apps' concept and run End2End business processes in both apps. | Use dual-write only to turn on Microsoft Power Platform capabilities and user experience. |
| Consider the Dataverse API performance limits. | Use dual-write to replicate volatile or transaction data, such as retail transactions or available inventory. |
| Consider the Dataverse database size and procedure for add-ons, if needed. | Use dual-write during data migration. |
The following table outlines considerations for when you're using virtual entities.
| Do | Don't |
|---|---|
| Use virtual entities to turn on Microsoft Power Platform capabilities and experience for finance and operations apps. | Use virtual entities as a data copy mechanism. |
| Use virtual entities where your business data and logic reside in finance and operations apps. | Use virtual entities for offline scenarios. |
| Use virtual entities when you plan to extend or add business logic in an app from Microsoft Power Apps or Microsoft Power Automate. | Use virtual entities when extra data points are needed. |
You can use these two powerful technologies in tandem with multiple scenarios in mind. They're designed to work together and to use for multiple business needs.