Step 5: Add the Control XML

Paste the following as a  inside that section's element.

  
    
      
    
    
      
        00000000-0000-0000-0000-000000000000
        588b7578-927c-426e-a274-5600f6e54269
        https://app.powerbi.com/reportEmbed?reportId=588b7578-927c-426e-a274-5600f6e54269
        { "Filter":"[{\"$schema\":\"basic\",\"target\":{\"table\":\"contact\",\"column\":\"parentcustomerid\"},\"operator\":\"In\",\"values\":[\"$a\"],\"filterType\":1}]", "Alias":{"$a":"accountid"}}
      
    
  

        

What you need to change

One easy-to-miss detail: TileUrl must be clean, unescaped URL text. If you copy this snippet out of a blog post or chat message, markdown link syntax sometimes comes along for the ride and you end up with stray [ and ](...) characters wrapped around the URL. That produces a control that silently fails to render. Paste into a plain text editor first and eyeball it.

Understanding the Filter — The Part That Makes It Contextual

The PowerBIFilter parameter is where the real work happens, and it's worth understanding rather than copying blind.

Reformatted for readability, the filter is:

{
  "Filter": "[{
      \"$schema\":\"basic\",
      \"target\":{\"table\":\"contact\",\"column\":\"parentcustomerid\"},
      \"operator\":\"In\",
      \"values\":[\"$a\"],
      \"filterType\":1
  }]",
  "Alias": { "$a": "accountid" }
}

Breaking that down:

• target — the table and column to filter on. These are names in the Power BI semantic model, not Dataverse logical names. If you renamed things during transformation, use the Power BI names. And the column has to actually be present in the model: if parentcustomerid was dropped to tidy up the dataset, there is nothing to filter on and no amount of XML will fix it.
• operator: "In" — tests membership against the values array, so the same expression works whether you pass one value or several.
• values: ["$a"] — $a is a placeholder, not a value. This is the key idea.
• Alias: {"$a": "accountid"} — tells the platform to replace $a at runtime with the accountid of the record currently open.

So when a user opens an account, the platform reads that record's accountid, substitutes it for $a, and the report renders showing only contacts whose parentcustomerid matches. Open a different account, get a different set. One report, filtered per record.

The alias value must be an attribute on the form's table — accountid on Account here. A nice side effect of the platform doing the substitution: you never deal with getId() returning a braced, uppercase GUID, which is the classic failure mode when people build these filters in JavaScript instead.

Need to filter on more than one thing? Add a second clause to the filter array and a second alias ($b, and so on) to the same map.

Step 6: Validate, Save, and Publish

In the FormXML Editor, validate the XML, then Save and publish. Reload the form and click your new tab.

The Result

Here is the finished tab on an Account record. The report is embedded directly in the form, and every row it returns belongs to the account currently open:

Look at the accountidname column — every row reads the same account name. That is the filter doing its job. Open a different account and the same report returns a different set of rows, with no change to the report itself.

For contrast, this is the identical report opened directly in Power BI with no filter applied:

Same report, same semantic model. Here accountidname shows a mix of different accounts and blanks, because nothing is scoping it. The only difference between these two screenshots is the filter the form passes in — which is the whole idea: one report, filtered per record, instead of one report per customer.

If your report appears but shows everything, the filter isn't being applied — see troubleshooting below.

Security: Read This Before You Ship It

The two screenshots in the previous section make this concrete, so it's worth being blunt.

The record filter is a convenience feature, not a security boundary. The unfiltered screenshot is what the underlying report actually contains: every contact in the environment. The form filter narrows what gets displayed; it does not remove the rest of the data from the report.

What follows from that:

• Dataverse security does not carry into Power BI. A user restricted to their own business unit in D365 has no such restriction inside the embedded report. Their access is governed by Power BI, not by their D365 security role.
• Power BI workspace or report access is required separately. Users without it see an error or a blank control regardless of their Dynamics privileges.
• If the data shouldn't be universally visible, configure row-level security (RLS) in Power BI based on the user's identity. That's the only mechanism that actually enforces restriction.

Use the record filter for convenience and RLS for security. Don't let the filtered-looking form lull you into thinking the data is scoped — it isn't.

Data Freshness

Users on a record form assume what they see is current. Depending on your model, it may not be:

• Import mode with scheduled refresh means the report is only as fresh as the last refresh, potentially hours old.
• DirectQuery over the Dataverse TDS endpoint gives near-real-time data, at some cost to report performance.

Pick deliberately and tell your users. On import mode, a visible last-refresh timestamp on the report page saves a surprising number of support tickets.

Troubleshooting

Limitations Worth Knowing

• The control can't be configured from the form designer — FormXML is the only route, so this customization is effectively code and belongs in source control with the rest of your solution.
• Embedded reports don't work offline in the mobile app, and mobile rendering has caveats that shift between releases. Test on the clients your users actually use.
• The control adds load time. Its own tab mitigates this.
• Report authoring stays in Power BI. Whoever maintains this afterwards needs Power BI access and skills, not just D365 ones.

Wrapping Up

The mechanism is small once it clicks: one report, one control in the FormXML, and an alias that resolves to the open record's ID. Most of the effort is in the surrounding details — enabling the feature per environment, confirming the filter column survived into the semantic model, generating a unique cell ID, and being honest about whether you need RLS.

Get those right and users get something they notice immediately: analytics where the work is happening, scoped to the thing they're already looking at.