Multiple legal entities issue with the Fin & Ops Apps connector in Power Automate

In this blog post, I will share a workaround to update or delete records in different legal entities when using the Fin & Ops Apps connector. This connector can be used with Microsoft cloud services: Power Automate, Power Apps, and Logic Apps. When the records to be updated or deleted are not part of the default company of the user, you will get an error “No resources were found when selecting for update”. Continue to read how to solve this error.

Fin & Ops Apps connector

A few years ago, I wrote multiple blogs about the Fin & Ops Apps connector with a series Let your operations flow. When you read the older blogs, you have to keep in mind that the name of the cloud service and connector has been renamed. Microsoft Flow is now Microsoft Power Automate and Dynamics 365 for Operations is not the Fin & Ops Apps connector.

At that time, I mentioned that the update and delete actions didn’t work if the company where you need to update or delete the records is not the default company of the user which is used on the connector in your flow. This issue is still present.

With a simple test, you can check the current behavior yourself. In my demo environment, the default company is USMF for my user account. I created a simple Power Automate Flow which creates a new record in the customer groups table in the company DEMF with the Customer group field set to DEMF. As the second action, the record will be deleted. You will receive the next error in case the default company is not DEMF.

So, how to bypass the limitation? One option would be using different users with different default companies. This is not the best approach if you need a single flow for automating actions for different legal entities. This could determine one company for the flow or have a loop across multiple companies within a single flow. So, how to bypass the limitation effectively?

Update default company in your flow

It is possible to change the default company of the user while running the flow. It would be recommended to first store the original value and revert a change at the end of the Flow.

In the example below, you can see the high-level steps which I approached to solve the issue. It needs to have a variable initialized to store the original default company; then the actual actions will be executed to get the current default company of the user who is running the flow. Once we have that information, the next block will change the default company of this user. After these steps, I included the actions from the flow shared above which was failing. At the end of the flow, the default company will be reverted to the original value.

Let’s take a deeper look in the details of all steps. I’ll start with the details of the block Get current default company for user.

The first action required is to find the SystemUsers record for the current user. This is not a perfect solution as theoretically there might be a difference in the user used for the connector and the user who runs the Flow. Assuming they are the same, you can find a SystemUsers record based on the User email variable which contains the Azure AD login account which is also stored in the Alias field of the SystemUsers. As the Alias field is not the primary key, we have to use the action Lists items present in table and not the action Get a record as the last mentioned action needs an object key based on the entity key fields. To limit the number of records, the Top count value is set to 1.

When we have the record, we can set the Company value for the DefaultCompany value. This will be stored to be used at the end of the flow when we have to revert a changed company value. When you add the action based on the outcome of Get SystemUsers record for current user, automatically the Apply to each control will be added as theoretically the value could contain multiple records.

The next block contains the logic to change the default Company value of the same user.

Now we changed the company, we can update a record. For demo purposes, I first created a new record in the customer groups. Then I updated the Description in the update action.

After we updated the record, we have to revert the users’ default company. In the last step, we will use the company value stored in the variable DefaultCompany.

Like setting another company, we also have to update a record. The only difference here is the value used for the Company field. When you save the flow, you can test or run it. You will now notice that the flow will run correctly without the error.

Download

I have created a zip-file with a Power Automate package that you can use in your own environment. When you have imported the Power Automate flow, you have to change the Finance and Operations environment in the Fin & Ops Apps actions.

If you have questions or feedback, please use the Contact form or leave a comment below.

There is more…

I do consider the method above as a workaround as this should be fixed by Microsoft in the future. In my opinion, you should be able to do the updates and deletes without changing user options. There are a few potential issues with changing the default company in the flow. If multiple flows will run simultaneously, there might be a little chance that changing the company can have an impact on updates from other flows. Also when you will open the Dynamics 365 F&O client, it might startup with the wrong legal entity. For these downsides, ensure you switch back to the default company as soon as possible. When you need to change the company, do this just before the update and revert as soon as possible.

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!