Nishant Rana

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

Fixed – Error occurred while loading document template / Error occurred while loading preview error in Dynamics 365

Recently, one of the users reported the following error while trying to generate a PDF for a Quote record in Dynamics 365:

Initially, the Export to PDF option was showing a blank list of templates.

This happened because the user was missing a few essential privileges on the Document Template tables.

To fix the blank template list, we updated the user’s custom security role with the appropriate privileges on the following tables:

Document Template
Personal Document Template

After adding these, the templates started appearing in the “Export to PDF” dialog.

Even though the templates were now visible, the user still got the following error while trying to preview or export:

This was due to one missing privilege in the Customization area of the security role.

We added: DocumentGeneration privilege

Once this privilege was granted, the preview and PDF generation started working as expected.

If we are unsure which privilege might be missing in similar situations, a quick way to find out is by using Developer Tools (F12) and monitoring the Network tab while reproducing the error. The failed request, such as ExportPdfDocument, usually reveals the missing privilege directly in its Response section (for example, missing prvDocumentGeneration privilege). This saves time and avoids trial and error when troubleshooting permission issues.

Hope it helps..

Advertisements

How to Identify and Update Power Automate HTTP Request Trigger Flows Before November 2025

Few weeks back, while working on one of our Power Automate flows, we noticed a banner warning on the HTTP Request trigger step. Microsoft has announced that starting August 2025, all flows using HTTP or Teams Webhook triggers with logic.azure.com URLs will move to a new endpoint under environment.api.powerplatform.com. The old URLs will stop working after November 30, 2025.

The screenshot below shows the banner that appears when the flow is opened in the designer.

When we saw this, we wanted to make sure no other flow across environments was using the old logic.azure.com–based URLs. Instead of checking each flow manually, we used SQL4CDS to quickly identify all such flows.

We ran the following query in SQL4CDS:

SELECT wf.name, wf.workflowid, wf.owneridname, wf.modifiedon
FROM workflow wf
WHERE wf.category = 5
AND LOWER(wf.clientdata) LIKE '%"type":"request","kind":"http"%'

This query returns all flows that have an HTTP Request trigger. It checks the clientdata column in the workflow table where the flow definition is stored as JSON and looks for the trigger type “Request” and kind “Http”.

This helped us identify every flow that exposes an HTTP endpoint — typically used for integrations, webhooks, or form submissions from external systems. Once we had this list, we opened each flow and copied the new trigger URL from the message banner.

The same can be achieved using PowerShell with the command: This lists all flows in a given environment that are part of Microsoft’s trigger URL migration.

Get-AdminFlowWithMigratingTriggerUrl -EnvironmentName

After copying the new URL, we updated our calling applications (for example, the website forms and marketing integrations) to replace the old endpoint with the new one. The new URLs are hosted under the Power Platform domain environment.api.powerplatform.com, replacing the older logic.azure.com endpoints.

To confirm that the requests were now reaching the new infrastructure, we captured the request headers after updating the URL.

This header (x-ms-igw-external-uri) is the easiest and most reliable way to confirm that your flow is now routed through the new Power Platform ingress gateway.

If this header is present and points to environment.api.powerplatform.com, the flow has been successfully migrated. If you still see logic.azure.com under the Host or DISGUISED-HOST headers, that flow or calling application still needs to be updated.

In our case, after replacing the URLs and testing, all flows were confirmed to be running on the new platform, and the integrations worked as expected.

So if we see this warning in your environment, you can either use the SQL4CDS query or the PowerShell command to locate such flows, update the calling systems with the new URL, and then verify by checking for the x-ms-igw-external-uri header in the request. That’s all you need to ensure your integrations continue to work smoothly past November 2025.

Hope it helps..

Advertisements

Using Parent Context in Dynamics 365 Plugins — Detecting System-Triggered Operations (Dataverse / Dynamics 365)

In this post, we’ll look at how we used the ParentContext property in Dynamics 365 plugins to determine if a plugin execution was triggered by another plugin and perform logic conditionally. This came up in two real-world cases — one where we needed to prevent duplicate Sales Leads created automatically through Event Management, and another where we wanted to match the correct Campaign when a Lead was updated through a Marketing Form submission.

In the first scenario, we had a plugin registered on the Pre-Create of Lead. We wanted to block duplicate Sales Leads only when they were created via CRM’s Event Plugin, not during manual Lead creation. To achieve this, we checked if the plugin execution had a ParentContext. When present, it meant the Lead creation was triggered by another process, not a user. We confirmed it was the system’s Event Plugin by checking the msevtmgt_originatingeventid field (this field will be auto-populated for a lead created by event) and depth. If the Lead was of Enquiry Type “Sales” and had an email address, we checked for duplicates and stopped the creation if one existed. This ensured duplicates were blocked only for system-triggered Leads.

The second case involved the plugin, registered on the Update of Lead. Here, we needed to identify if a Lead update was triggered by a Marketing Form submission (from the msdynmkt_marketingformsubmission table) and only then run our Campaign mapping logic. We used ParentContext to walk up the plugin chain and confirm the origin. Once verified, we called our logic to assign the correct Campaign based on the Region or Village. This made sure the Campaign logic only ran for Leads updated by Marketing automation, not for regular user edits.

In both cases, using ParentContext gave us precise control over when the plugin logic should run. It allowed us to differentiate between user actions and system-triggered updates, avoiding redundant execution and maintaining a cleaner automation flow.

Hope it helps..

Advertisements

Fixed – “Action cannot be performed. This quote is not owned by Dynamics 365 Sales” in Dataverse / Dynamics 365

Recently, while working with Quotes in Dynamics 365 Sales integrated with Supply Chain Management (SCM) through Dual-write, we encountered an interesting error while trying to activate an existing quote.

When attempting to activate Quote, the system threw the following error message:

Checking the Plugin Trace Log, we found the following details:

Entered Microsoft.Dynamics.SCMExtended.Plugins.QuotePreUpdate.Execute(), Correlation Id: 97636eb7-a10c-4503-918f-6dd7b8c1a671, Initiating User: 2953f4a9-ffca-ea11-a812-000d3a6aa8ae

QuoteService: PreUpdate.

Validate calling user $2953f4a9-ffca-ea11-a812-000d3a6aa8ae.

Calling user not DataIntegrator

Feature: Dynamics. AX.Application.SalesQuotationD365SalesFeature; Enabled: True

QuoteService: update from CE.

Validate calling user $2953f4a9-ffca-ea11-a812-000d3a6aa8ae.

Calling user not Dual-write.

SCM plugin exception: Action cannot be performed. This quote is not owned by Dynamics 365 Sales., at Microsoft.Dynamics.SCMExtended.Plugins.Services.QuoteService.ValidateIntegrationOwnerOnStateCodeChange(LocalPluginContext localContext, Guid quoteId)

Interestingly, this issue occurred only for old quote records — the ones created before Dual-write was enabled.

All newly created quotes after enabling Dual-write worked perfectly fine and could be activated without any error.

When comparing both sets of records, we noticed one key difference:

The msdyn_quotationownership (Ownership) field was blank for old quotes, while it was populated for the new ones.

This field plays an important role once Dual-write is enabled. The Microsoft.Dynamics.SCMExtended.Plugins.QuotePreUpdate plugin checks the Ownership field during operations like quote activation to validate the integration source.

If this field is empty, the plugin assumes the quote doesn’t belong to Dynamics 365 Sales and blocks the action, resulting in the error we saw.

Here we simply needed to set the missing ownership field.