Dynamics 365: Virtual Entities for F&O vs Dual-write
When integrating Dynamics 365 F&O with Power Platform (Dynamics 365 CE) there are today two different “standard”/no-code options of doing it, Virtual Entities for F&O and Dual-write. In this blog post I will walk you through the pros and cons of each option and try to guide you on which option you might want to use for your scenario.
Dual-write
Dual-write is the option that has been around the longest and the most known of the two options. It is like a package containing several different features that preferably should be used all together but also can be used stand alone. The two main feature arias that is contains is an integration engine and pre-setup template scenarios.
Integration Engine:
It pushes data from one platform to the other based on tables and fields that you map buy yourself via drag and drop.
With Power platform (Dataverse) the API communicates directly with the tables and fields In a 1:1 relationship . With the F&O platform the API communicates via the data entities before it comes to the actual tables and fields, in some cases the data entities are aggregate or subsets of the tables and fields. In some cases, new data entities in F&O need to be setup or existing ones needs to be modified in order to be able to access certain data.
When setting up new mappings in Dual-write the integration engine automatically sets up the required trigger points/ business events in both systems. It also runs as Microsoft phrases it “near-real-time” which means that if you perform an action in one of the platforms, and it does not pass the business validation in the other platform, then it does not get saved in the first platform ether that the user was preforming the action in, the user will get promoted with an error message as well.
The “near-real-time” experience has in some cases been criticized since some of the user experiences gets slower and there have been talks about making it asynchronous instead. Personally, I think the extra second is worth the wait compared to getting un-synced data and dead letter queue handling that an asynchronous setup always comes with.
Pre-setup template scenarios:
Dual-write also comes with ready template scenarios so that everyone does not need to re-invent the wheel in every project. The templates scenarios each have a Power platform (Dataverse) solution containing fields tables that by standard exists in F&O but not in any of the Power platform apps (Sales, Field Service etc).
Each template scenario also has ready mappings of tables and fields that are all tested from a process stand point, if they are used exactly as documented by Microsoft they will work out of the box.
It also has a relationship assistance showing all other needed tables (as meta data) to perform the template scenario connected to mapping.
The one thing to keep in mind with dual-write, and its pre-setup template scenarios, is that it is sold as a “out of the box feature, just setting it up buy next next”. This is true if you keep 100% to the template scenarios that’s documented by Microsoft, the smallest of change in one of the platforms can lead to a lot of work and remapping in both platforms.
You can run the Dual-write integration engine with any table without the pre-setup template scenarios, but the most common way of doing it is by setting it up with the pre-setup template scenarios.
Virtual entities for F&O
Virtual entities for F&O is a function in Dataverse that reads data directly from the F&O platform and then enables the data to be acted on just as any other Dataverse data within Power platform. You can create, read, update, and delete the F&O data within Model driven apps, Canvas apps (using the Dataverse connector) and Power pages. You can also use other Power Platform features/ Dataverse connector features on it such as running Power automate etc, but still the data only exists in F&O and you do not need to pay for any double data storage witch you need to do when running Dual-write.
Just as Dual-write the Virtual entities for F&O communicates with the data entities in the F&O platform so in some cases additional data entries and or changes to data entities might be needed to be done in order to access the data. Another important aspect of the data entities when working with the Virtual entities for F&O is that they are set up correctly from a relationship perspective, otherwise data that’s referring to another entity might just show up as a text field in Dataverse and not as a lookup as you might expect it to.
It does not require any code to setup the Virtual entities for F&O and ones its up you simply enable the F&O data entities you would like to have within Dataverse in the advanced find.
Scott Gaines wrote an awesome blogpost on the setup process that you can find here or you can find Microsoft’s official documentation about it here
Virtual entities for F&O also have the awesome feature that you can add on additional fields and relationships to an entity/table in Dataverse. Those fields and relationships are not created in F&O, they are instead stored separately in Dataverse but for the user it’s just displayed as one table.
Compared to Dual-write Virtual entities for F&O is more of a technical solution, and it does not (today at least) have any business templates scenarios connected to it so if you are using it for bigger scenarios it should be considered as development tool where all scenarios needs to be build and designed from scratch.
An important thing to be aware of is that it is handling all F&O Data entities as new tables in Dataverse and it’s never connecting any of the existing Dataverse tables with F&O Data entities. This becomes a issue with some of the out-of-the-box Dataverse tables such as accounts (customers), contacts and others which the out-of-the-box Dataverse apps fetchers are built on. If you as an example are not using the Dataverse out-of-the-box contact table when using the App for outlook you won’t get the majority of the apps features.
When to use which?
As always, there is not just one easy answer to it, if so both options wouldn’t have existed. What to use always depends on the business scenario and the customer’s needs. In some cases, you might even use both options in the same solutioning for different parts of the solution but here are some of my personal guidelines!
Virtual entities for F&O — Is from a technical point and as a tool my favourite of the two options, you always read directly from the source of the data so there’s never any discrepancies in the data. Another big win is of course that you do not need to pay for the double storage of data. How ever in many cases it does disqualifies itself due to the fact that it can’t be connected to the standard Dataverse tables which is a must to not need to rebuild a lot in the Power platform (Dynamics 365 CE) apps (Sales, Field service, Marketing, Customers service, Project Operations) and other features such as the App for Outlook. From a project time keeping perspective the fact that there are no pre-built template scenarios is of course also a big minus.
Dual-write — The pre-built scenarios is of course its biggest plus and compared to the most other integration options (except Virtual entities for F&O) its “near-real time” feature with the business rules validations in the other platform is also a strong contributor. Given that it can connect to existing Dataverse table Dual-write is definitely the preferred way to go in in many use cases.
Compared to Virtual entries for F&O that has zero risk of un-synced data between the systems that risk is a minus for Dual-write and the cost of the double storage of data is of course another minus.
If we break it down buy the data types:
Meta data:
Both options are really good here, Dual-write might be slightly faster for the user experience perspective in Dataverse, which might be beneficial given that meta data doesn’t change that often and it´s often not in larger volumes. On the other hand, when data doesn’t change that often it´s harder to catch if the sync of some reason would be down, that issue you would never have with Virtual entities for F&O.
Master data:
As long as its data that needs to be connected with the Dataverse tables Dual-write is the way to go. If the master data records are a part of the pre-setup template scenarios, stick to what’s there in Dual-write! If neither of the two previous conditions are true, the one data source aspect with Virtual entities for F&O is the most preferable as I see it.
Transactional data:
If you can stick to the Dual-write template scenarios for the transactional data you should use it, but my experience is that it’s not always the case. In the cases you need to configure something on your own you might what to consider the Virtual entities for F&O instead.
If you as an example would like to display and edit transactional data that does not exist in Dataverse in Power pages like Purchase orders Virtual entities for F&O is the preferred way to go.
References
We are looking for Dynamics 365 Finance and Operations professionals, plus other Microsoft Business Applications and Azure skills. If you’d like to hear more, please view our open roles.
