Battle of the Connectors – Microsoft Dataverse vs Fin & Ops Apps (Dynamics 365)

As a Microsoft Dynamics 365 Finance and Operations professional, I often need to collaborate with the solutions provided by the Power Platform. In the past years, Microsoft made huge convergence efforts in bringing the different platforms together, allowing both pro-developers and citizen developers to extend Microsoft Dynamics 365 Finance and Operations applications. One of the efforts was making F&O data entities available as virtual tables in Dataverse. The Dataverse connector on the Power Platform supports virtual tables, which brought a second option to interact with Dynamics 365 F&O data in the Power Platform. Which one is better to use? Continue reading the post to find the answer.

Background

For many years already, there has been a specific connector available for Microsoft Dynamics 365 F&O. I wrote a series of blog posts about 6 years ago on how to use the Fin & Ops Apps connector. While using the connector in apps and automation, I encountered some quirks and had to work around them.

A bit later, Microsoft released the Virtual tables framework and added Create, Read, Update, and Delete (CRUD) support for public data entities residing in Dynamics 365 Finance and Operations. By default, you can then use the virtual tables in Power Apps solutions and build model-driven apps. The Microsoft Dataverse connector supports virtual tables. Using this connector, you can also interact with F&O data e.g. when creating canvas apps or using Power Automate.

Fin & Ops challenges

One of the quirks I encountered was that there is a limitation on updating or deleting records in case the records are part of a legal entity that is not the default company of the user. You can read more about the details of the limitation in my post about Multiple legal entities issue with the Fin & Ops Apps connector in Power Automate. In this blog, I also provided a workaround, but that is far from perfect in case multiple flows are running and at the same time you are interacting within Dynamics 365 or other apps connected to the data.

When I reached out to Microsoft, they suggested using the Dataverse connector and virtual entities instead. Indeed, when trying this connector, it is possible to update and delete records regardless of the default company of a user.

Another challenge with the Fin & Ops connector is the ALM story. As part of the Fin & Ops actions, you always select a specific environment from your tenant. This is stored on each action in Power Automate and linked as a data source for a Power App. When moving a flow or app from a development environment to test or production, you must change the environment at each place in the app or flow.

In the screenshot above, you see an example in Power Automate where the Dynamics 365 instance is selected as part of multiple actions. In case you have a complex flow or app, changing the connections is a tedious and error-prone task. You might forget an action or link to another incorrect environment.

When using the Dataverse connector, the actions by default run in the environment where the Power Automate flow is running. This can save a lot of time and possible issues with updating the connections to another environment.

Dataverse connector

To be able to use the Dataverse connector, you must ensure that the solution is configured. In case the environment is linked to a Power Platform environment, then the Dataverse virtual entities are configured as part of the link. Otherwise, you need to perform several steps for configuration. You can read how to do that on Microsoft Learn: Configure Dataverse virtual entities – Finance & Operations

Once the connector is enabled, you must activate the Dynamics 365 F&O data entities you want to use within the Power Platform via the Dataverse virtual tables. Documentation is available on activating entities, but this is not applicable to all environments. You can use the next steps for a single procedure.

Go to https://make.powerapps.com. Ensure you select in the title bar the correct environment. On the left menu, choose Tables. In the Tables body content, select to see All tables. This will ensure all virtual tables will be available. Then filter the Table column with the value that starts with or contains the word Available. You can also search on all tables containing Finance and Operations to trim the list.

Click on the table name Available Finance and Operations Entity to open the table with all available entities. Loading of the contents can take 1 or 2 minutes.

In the table browser you can filter on the Name column to search for entities. In case you want to enable or disable the entity to be used as a virtual table, you can toggle the Visible column. This will start a validation if the entity is meeting all the requirements to be used as a virtual entity. If this validation fails, an error is returned and the changes will not be saved having the data entity not enabled.

The Available Finance and Operations Entity table can be used with the Dataverse connector to check if a data entity is enabled. You can also use the Update operation to change the Visible value in a Power Automate flow.

Let’s dive into all the differences between the Dataverse and Fin & Ops Apps connectors.

Comparing the connectors

In this section, I will list some of the differences between the connectors to be aware of when using the actions.

Environment selection

The first difference you will notice when you add an action from Fin & Ops or Dataverse is the way how to connect to an environment. Using the Fin & Ops connector, you can choose between all the deployed cloud environments in your tenant. The Dataverse connector is by default connected with the environment where you create the action. There are also actions available where you can link another Dataverse environment. This can be useful in case you need to create flows and perform actions across several environments. The actions with the suffix selected environment will show all Dataverse environments in your environment.

Selecting an environment in the Fin & Ops connector or a Dataverse selected environment will give challenges when you want to move a solution or single app/flow to another environment. In case you have a flow with e.g. a lot of Fin & Ops actions, it will require updating them all and this is error-prone. The Dataverse connector wins on this point when the current environment is selected. That is recommended in case you need to move solutions as part of your Application Lifecycle Management (ALM) strategy.

Create

When inserting records there isn’t a difference in usage. The name of the action in Fin & Ops is called Create record where the Dataverse equivalent is Add a new row. With both connectors, you need to select the entity and provide in the parameters which fields will get what value. There is only one difference where you can leave the Company parameter blank in the Fin & Ops action. It will then take the default company of the user running the flow. For the Dataverse connector, you always need to provide the legal entity ID in the Company code parameter.

Using this action, in my opinion, the connectors comparison ends in a draw. Having one parameter for the company not mandatory is not a reason to win the battle or not. To have full control of what is happening, providing the company is recommended.

Read

When reading records, there are some differences to be aware of. The differences are listed in the table below.

Topic	Dataverse	Fin & Ops Apps
Action name	List rows	List items present in table
Company restriction	By default data will be returned for all legal entities. Use a filter to limit the results belonging to a specific legal entity	By default, only records for the default company of the user that runs the flow will be listed. In case multiple legal entities are required, the advanced property Cross Company must be enabled.
Company filter string	mserp_dataareaid eq ‘USMF’	dataAreaId eq ‘USMF’

The difference here is about using the default company of the user or not. When you want to retrieve data using Dataverse from a single company or if you want to change the company for the Fin & Ops connector, you need to filter data in the action using an OData filter query. You can find help with filter options on Microsoft Learn: Filter rows using OData – Power Apps. Note that the field name to be used for filtering the legal entity is different in both connectors.

For both connectors, you will need to set other parameters like the row count if you expect one record in return only or want to limit the loop with a specific number of rows.

Update

As mentioned above, the Fin & Ops connector is not able to update records in case the record is not within the default company of the user.

There are some differences to be aware of. The differences are listed in the table below.

Topic	Dataverse	Fin & Ops Apps
Action name	Update a row	Update a record
Company restriction	No company restriction	Only records from the default company of the user can be updated.
Object ID	Check for items from a previous action and search for the value having the name of the virtual table with a suffix (mserp). This value also has an additional description: Unique identifier for entity instances. You can see an example in the screenshot below.	The Object ID should have all entity key fields separated with a comma. In case the table saves data per company, the first field must be the company ID. In case of a global table, the company ID is not used. See also my previous blog: Let your Operations Flow – Part 3

In the screenshot above, I highlighted the OData id. This is not used for Dynamics 365 F&O virtual entities to get a unique row ID.

The hardest part of using the update action is knowing what to enter as Object ID. Using the Fin & Ops Apps connector, you should have knowledge about the data model. Is the table global or does it store data per company? What fields are used as primary entity key? This is visible in the Power Automate flow, so you must inquire about technical details using Visual Studio.

When using the Dataverse connector, you must add action to retrieve the record. Then it will know the unique identifier for each record. For this purpose you can use the List rows action and use OData filters to retrieve one or multiple records that needs to be updated.

When considering all the characteristics of this action, the Dataverse connector is my favorite. This has not the user’s default company as a limitation and using the current environment is better for the ALM flow.

Delete

The limitation on the default company is also valid for the delete operations using the Fin & Ops Connector. The differences between the connectors are listed in the table below.

Topic	Dataverse	Fin & Ops Apps
Action name	Delete a row	Delete record
Company restriction	No company restriction	Only records from the default company of the user can be deleted.
Object ID	Check for items from a previous action and search for the value having the name of the virtual table with a suffix (mserp). This value also has an additional description: Unique identifier for entity instances. You can see an example in the screenshot above.	The Object ID should have all entity key fields separated with a comma. In case the table saves data per company, the first field must be the company ID. In case of a global table, the company ID is not used. See also my previous blog: Let your Operations Flow – Part 3

For the same reasons above, in my opinion, the Dataverse connector wins on this action.

Execute an action

Both the Dataverse connector and Fin & Ops Apps connector can execute business logic in case a method is decorated with an OData attribute to make it visible. I wrote about this option before. See: Let your Operations Flow – Part 8

Topic	Dataverse	Fin & Ops Apps
Action name	Perform a bound action	Execute action
Company restriction	No company restriction	Only records from the default company of the user can be used to execute an action.
Object ID	Check for items from a previous action and search for the value having the name of the virtual table with a suffix (mserp). This value also has an additional description: Unique identifier for entity instances. You can see an example in the screenshot above.	The Object ID should have all entity key fields separated with a comma. In case the table saves data per company, the first field must be t

I haven’t used the Dataverse action myself, but the parameters are quite simple. You must specify the table, the action, and the Object ID of the record.

Like the other actions with the company limitations, the Dataverse connector has my preference.

Performance

While using the read actions, I noticed differences in performance. Sometimes the Fin & Ops connector is slow. Mainly when running the flow for the first time in a day. After that, the results vary a bit where it looks like in General the Dataverse connector can list the records a bit quicker. Sometimes the Fin & Ops connector returned the records quicker than Dataverse. In this case we talk about several seconds. I haven’t done a full performance analysis, so I will not judge in this area.

Security

The security requirements to interact with the Finance and Operations data are equal for both connectors. A user should be created in Dynamics 365 F&O with a role granting access to the data entity. In a future blog post, I will explain about this security part for data entities.

Conclusion

Overall, in my opinion, the Dataverse connector should be the preferred connector to interact with Dynamics 365 F&O data. For the ALM part, it is a huge advantage of being able to use the current environment where the Power Platform integration also knows the linked F&O environment.

The company restriction in the Fin & Ops Apps connector is silly and a major blocker to recommend this connector. As listed above, the Dataverse connector does not have this limitation as Dataverse tables are not aware of the company concept like there is in Dynamics 365 Finance and Operations.

The Dataverse connector also comes with more advantages. For virtual tables, it is possible to enable data events which can be used as a trigger to start a Power Automate flow. You can read more about this feature here: Data events – Finance & Operations

Lastly, the Dataverse connector and virtual entities make it possible to use Dynamics 365 F&O data as a knowledge source in Copilot Studio. Next to using native Dataverse tables, now also virtual entities. This feature is at the time of posting this blog in preview. You can learn more on Microsoft Learn: Chat with finance and operations data (preview) – Finance & Operations

Featured image

As a bonus, I share some information about the featured image on top of this post. This is AI generated using Microsoft Designer. The next sentence is the prompt I used and after downloading one of the created images, I pasted the logos in the image.

Image representing a battle of software application connectors. The connectors in battle are Dataverse and the Dynamics 365 Finance and Operations connector. Dataverse is represented in green, like the brand icon. Dynamics 365 Finance and Operations is represented in the color purple as per the brand icon.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!