Automatically Update Lookup Fields in Dynamics 365 Using Power Automate: From Custom Tables to Standard Entities

Imagine this: you update a product’s purchase date in a registration record and—boom—a related case automatically gets refreshed with the accurate “Purchased From” lookup. Saves time, reduces errors, and keeps everything in sync without you lifting a finger. Let’s walk through how to make that happen using Power Automate.

The goal: When a Product Registration’s cri_purchasedat field is changed, the system will retrieve the related “Purchased From” record and update any linked Case(s) with the appropriate lookup reference.

Let’s break down the step-by-step process of how this is done in Power Automate.

Step 1: Trigger the Flow When Purchase Date Changes

Flow trigger: When a row is added, modified, or deleted (Dataverse)

• Change Type: Modified
• Table: Product Registrations
• Scope: Organization
• Select Columns: cri_purchasedat

This setup ensures that our flow only fires when that specific date field is modified.

Step 2: Pull in the “Purchased From” Record

Next, use List rows on the “Purchased From” table with a FetchXML query. We’re searching for a record whose name matches the updated cri_purchasedat.

Set Row Count to 1, since we expect only one match.

3. Identify Any Linked Case Records

Add another List rows action, this time on the Cases table. We look for records where cri_productregistrationid equals the current product registration’s ID:
We now use the List Rows action to fetch all related Case records tied to the updated Product Registration.

This time we’re targeting the Cases table (which is internally incident in Dataverse) and using a FetchXML query to match records where cri_productregistrationid equals the current record being modified. This step is critical because it gives us the list of Case records we need to update, based on the link with the modified product registration.

<fetch>

<entity name=”incident”>

    <attribute name=”incidentid” />

    <attribute name=”title” />

    <attribute name=”cf_actualpurchasedfrom” />

    <filter>

      <condition attribute=”cri_productregistrationid” operator=”eq” value=”@{triggerOutputs()?[‘body/cri_productregistrationid’]}” />

    </filter>
  </entity>
</fetch>

5. Before updating anything, we add a Condition control to ensure that our previously fetched Purchased From record exists and is unique. Why? Because if there’s no match (or multiple matches), we don’t want to update the Cases blindly. We check if this length equals 1.

If true → move forward with updates.
If false → stop or handle the exception accordingly.

To conclude, this kind of validation builds guardrails into your automation, making it more robust and preventing incorrect data from being applied across multiple records.

After confirming a valid match, the flow loops through each related Case and updates the “Actual Purchased From” field with the correct value from the matched record, ensuring accurate linkage based on the latest update.

Once this step runs, your staging automation is complete—with Cases now intelligently updated in real-time based on Product Registration changes.

We hope you found this blog useful, and if you would like to discuss anything, you can reach out to us at transform@cloudfonts.com.