Power Automate – Nishant Rana's Weblog

Open a Power Automate Flow for Edit Without Fixing Broken Connections First

While reviewing Power Automate flows recently, we ran into an issue where we could not open a flow in edit mode

When opening the flow, Power Automate displayed the “This flow will connect to” screen and requested that we fix one or more connections before proceeding.

In our case, the flow contained an Office 365 Outlook connection reference that required attention. The problem was that we did not have access to create or repair that connection. Because of this, the Continue button remained disabled and we were unable to open the flow designer to understand what the flow actually did.

At first glance, it appeared that fixing the connection was the only option. However, in our scenario, we were simply analyzing existing flows to understand their purpose and determine whether they were still required.Repairing the Outlook connection would have required additional investigation, coordination with the appropriate users, and potentially creating or reassigning connection references. Since our immediate goal was only to review the flow logic, spending time resolving the connection issue first did not make sense.

Fortunately, we found another approach that allowed us to access the flow designer without fixing the connection immediately.

Instead of trying to fix the connection, open the flow’s Details page. From the details page, locate the Connections section and select Edit.

Next, add your user account as a Co-owner of the flow.

Once we added our user account as a co-owner, we refreshed the page and tried opening the flow again.This time, we were able to open the flow designer and review the flow logic even though the Outlook connection issue was not resolved.

Seems that adding our account as a co-owner provides the permissions required to access and inspect the flow. This simple workaround can save considerable time when reviewing large numbers of flows across an environment.

Hope it helps..

Advertisements

Action ‘Update_a_record’ failed: An error has occurred. No resources were found when selecting for update – Fixing Cross-Company Update Issues in Finance & Operations Using Dataverse Virtual Entities (Power Automate)

Recently, while trying to update the Projects table in Finance & Operations using the Fin & Ops Apps actions in Power Automate, we ran into below error:

An error has occurred. No resources were found when selecting for update.

A screenshot of a computer

AI-generated content may be incorrect.

After digging deeper, we realised the issue had nothing to do with the payload or field mappings. The root cause was that the default company of the connection user in Finance & Operations was different from the company of the record we were trying to update. The Fin & Ops connector always operates in the context of the user’s default legal entity, and unlike the “List items present in table” action, it does not offer any “Cross Company” option for update operations. The result is that Power Automate looks for the record in the wrong company and, naturally, F&O returns a “record not found” error.

In our scenario, we had dual-write and virtual entities enabled. When this is the case, Finance & Operations exposes many of its data entities as Dataverse Virtual Tables. These tables are essentially real-time proxies: Dataverse reads and writes directly into F&O while automatically handling the underlying company and key structure. So instead of updating the F&O Projects table directly, we switched our Power Automate logic to update the corresponding virtual entity in Dataverse. That simple change immediately resolved the issue. The update worked flawlessly across companies, and we didn’t have to worry about the user’s default company or any cross-company flags.

This completed without errors, even for multi-company data.

There are other approaches as well, depending on how your environment is set up. We could bypass the connector entirely and make raw OData PATCH calls to F&O, as long as we manually specify the full composite keys, including the DataAreaId. Another option is to build a small custom API or X++ service that accepts a legal entity parameter, executes a changeCompany call in F&O, and safely performs the update on the server side. Both approaches work, but they require more configuration, authentication handling, and careful error management. For most day-to-day automation scenarios, the virtual entity route remains the simplest and most reliable.

In our case, switching to the Dataverse Projects (mserp) virtual table solved the issue immediately. The update completed without errors, even for multi-company data, and the flow became much cleaner.

A detailed explanation of this limitation can be found here, and was very helpful in troubleshooting:

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

Hope it helps..

Advertisements

Fixing the “Only 1 of 2 keys provided for lookup, provide keys for dataAreaId, ProjectID / Not found” Error in Power Automate (Fin & Ops Apps)

Recently, while working with the Projects table from a Finance & Operations (F&O) environment, we ran into an error while using the Get a record action in Power Automate. (BTW this was the first we were using the Fin & Ops connector)

The flow kept failing with the following message:

Only 1 of 2 keys provided for lookup, provide keys for dataAreaId, ProjectID.

This error appears when we try to fetch a record from an F&O using only the ProjectID. But unlike normal Dataverse tables, F&O tables often come with composite keys.

Instead of passing just the ProjectID, we must pass the full composite key in the format:

dataAreaId,ProjectID

In our case, the correct value was:

AUST P-REP-34

Below, we can see it working properly

At one point, even after passing the correct composite key, we started getting a NotFound error:

Action ‘Get_a_record’ failed – NotFound

A screen shot of a computer error

AI-generated content may be incorrect.

Nothing had changed in the inputs — it was just not working. The fix was surprisingly simple..

We deleted the Get a record step, re-added it, provided the same inputs again, and the error disappeared. It could be related to the connection reference not being updated properly in the background.

Hope it helps..

Advertisements

Flows getting triggered multiple times / missing callbackregistration record – Power Automate / Dataverse

Recently, we observed that one of our flows was getting triggered multiple times in our UAT environment; however, the flow was working properly in our Development environment.

On comparing the flows trigger, we didn’t find any differences.

However, when checking for the callbackregistration record, we observed that for the Dev env, we had the callbackregistration record available.

However, it was missing for our UAT environment.

Turning the flow on and off didn’t create the corresponding callbackregistration record.

https://nishantrana.me/2025/09/02/fixed-flow-not-getting-triggered-incorrect-callback-registration-record-power-automate-dataverse/

Eventually, we deleted the trigger and recreated it in the UAT.

After recreating the trigger, we could see our flow getting triggered only once as expected.

However, we also noticed that the name of the callbackregistration record was not just the GUID, but it also had MTA suffixed to it in our UAT.

daf9fae3-a405-ee11-8f6e-00224817f864:MTA

So may this record was already existing and had an incorrect filter expression, which got fixed when we deleted and created a new trigger.

We also deleted this callbackregistration record, and turned our flow on and off. This created a new callbackregistration record with the same MTA suffixed to it.

So the solution here could be to find the callbackregistration record either with a GUID or with MTA suffixed to it, delete the record found, and turn the flow on and off.

Hope it helps..

Advertisements

Fixed – Flow not getting triggered / incorrect callback registration record (Power Automate / Dataverse)

Recently, we faced an interesting issue, where we updated an existing flow in our Dev, basically we removed the Filter Rows condition and deployed it to UAT.

Before –

Now –

In our Dev, it was working fine, getting triggered on the update of the field specified in the Select Columns; however, after deployment to UAT, it was still getting triggered only on the old filter condition, which we had already removed.

Turning off and on the Cloud Flow didn’t help.

The client data did not have the Filter rows condition.

Interestingly, we can still see the filter expression existing for the callback registration record of that flow in our UAT.

Eventually, we deleted the Callback registration record, turned the flow off and on, and it created the correct Callback Registration record with filter expression as null this time.

A computer screen shot of a computer

AI-generated content may be incorrect.

This fixed the issue, and our flow got triggered correctly.

Advertisements

How to – Find Every Cloud Flow That References a Specific Column / Field (Dataverse/ Dynamics 365)

Sometimes we need to find all the flows where a specific Dataverse field is used — maybe before renaming it, removing it, or just checking its usage. Manually opening each flow is slow, but we can do it in seconds with SQL 4 CDS.

For e.g. we want to search for flows that use the field: custom_mysamplefield

For this we can make use of the below query, run it in SQL 4 CDS (XrmToolBox).

SELECT wf.name, wf.workflowid, wf.clientdata
FROM workflow wf
WHERE wf.category = 5
AND LOWER(wf.clientdata) LIKE '%custom_mysamplefield%'

Here table workflow stores flows and workflows details, category = 5 refers to cloud flows, clientdata contains the flow’s JSON Definition.

The result :