How are teams handling AI-driven automation around Power BI Embedded applications?

Hi codeautomation​,

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution I have provided for the issue worked? or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa

I’d keep Power BI Embedded focused on user interactions and move orchestration, authentication, and business logic to the backend. The backend can process report events, validate the context, call approved APIs, and use AI to summarize insights or recommend next steps.

I’ve seen a similar approach in DataToBiz’s work on USPS Tracking Resolution with Custom AI Workflows, where AI-driven workflows are applied to operational processes. The same principle is relevant here: AI can help interpret information and recommend actions, while the backend retains control over execution.

For production, I’d use managed identities or service principals with least-privilege permissions, keep credentials out of the client, and implement audit logging and idempotency to prevent duplicate actions. AI-generated outputs should also be validated against predefined rules before triggering business workflows, with human approval for sensitive or high-impact actions.

This separation keeps the architecture secure and maintainable while allowing Power BI Embedded, Fabric APIs, and AI services to work together without putting sensitive logic in the client application.

We have a similar setup. Our embedded solution connects to Microsoft Foundry for the AI part. Agents are created in Foundry, and in the backend of our embedded solution, admins define which agent is used for which case or semantic model. Some agents let end users ask questions about their data in natural language. Others help create code for visuals in JavaScript, D3 or Vega, or write DAX when needed.

We started with Gemini, but as the requests got more complicated, we switched to Foundry. The main reason was that Foundry gives us models from different providers, like OpenAI and Anthropic, in one place, so we can pick the right model for each agent. So far we've had a good experience with it.

Hi codeautomation​,

We wanted to kindly follow up to check if the solution I have provided for the issue worked? or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa

Hi codeautomation​,

Adding a concrete shape to the advice above, because the pattern that has stayed maintainable for me is: the embedded report only emits events, a backend owns everything else. The key rule is that the backend never trusts data sent from the browser; it re-reads what it needs from the model under the user's identity.

Embedded report (powerbi-client)
  -> emits event: dataSelected / buttonClicked / pageChanged
Your API (Azure Function / App Service, managed identity)
  -> validates the user + maps them to the RLS identity
  -> re-queries the model (executeQueries + impersonation)
  -> calls the AI service with that data
  -> writes result / triggers workflow (queue, Logic App, Power Automate)
  -> returns a summary to the client panel next to the report

Client side stays thin:

// client: only send *intent* + IDs, never the data itself
report.on("dataSelected", async (e) => {
  const sel = e.detail.dataPoints.flatMap(dp =>
    dp.identity.map(i => ({ table: i.target.table, column: i.target.column, value: i.equals })));

  await fetch("/api/insights", {
    method: "POST",
    headers: { "Content-Type": "application/json", Authorization: "Bearer " + appUserToken },
    body: JSON.stringify({ reportId, page: e.detail.page.name, selection: sel })
  });
});

Backend side re-reads the numbers itself so a user cannot spoof data into the prompt or see other customers' rows:

// backend: re-query the model for the selection, with the caller's RLS identity
POST https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/executeQueries
{
  "queries": [{ "query": "EVALUATE SUMMARIZECOLUMNS('Date'[Month], 'Customer'[Segment], \"Revenue\", [Revenue])" }],
  "impersonatedUserName": "<customer user / RLS identity>"
}

A few things that kept it manageable in production: put the AI call behind a queue for anything slow, cache summaries per (report, selection hash, data refresh time), log prompt + model version for auditing, and keep the semantic model the single source of business logic so the AI layer only interprets results. If the action is "write something back from inside the report" (approve, comment, adjust), translytical task flows with a user data function can replace a custom API for that part.

So my overall approach would be:

Report emits events only (no data in payload)
-> Backend authenticates + maps user to RLS identity
-> executeQueries with impersonation for trusted context
-> AI call async + cached, audited
-> Workflow triggers from the backend; write-back via translytical flows

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.