Changes automation
The visual never writes to your source directly — see Edit Mode for what a reader can change and how a changeset is built. This page is about what happens next: getting that changeset to an approver, deciding whether approval is required at all, and applying it to the authoritative source without anyone hand-editing a spreadsheet.
On this page
Export to email
The Email changes button gets a changeset from the reader's screen into an approver's inbox without either side touching a file share. Two things happen when it's clicked:
- The changeset JSON — with a short routing header (chart name, chart GUID, chart id, base revision, change count, and the reader's note) prepended above it — is copied to the clipboard as one block of text.
- Outlook Web opens in a new tab with the To and Subject already filled in. The reader pastes the copied text into the body and sends.
Why the body isn't pre-filled too. Power BI's own confirmation dialog for opening an external link shows the full raw URL before the reader can proceed. A URL carrying an entire JSON changeset, percent-encoded, reads as a wall of gibberish in that dialog — it looks like something has gone wrong rather than a normal, safe navigation. Keeping the URL to just an address and a subject line keeps that confirmation looking like what it is.
Where the mail actually goes is set in the format pane, not hard-coded: Format visual → Editing → Approver inbox. A distribution list works fine here if more than one person should see submissions.
Approval process options
Whether a changeset needs a human's sign-off before it's applied is a choice you make in two places: the visual's own format pane, and permissions on whatever receives the export.
Bypass approval
Leave Format visual → Editing → Statuses that lock editing blank — the default. A chart is always editable regardless of its review status, and whatever receives the exported changeset (a SharePoint library, a flow, a mailbox someone monitors) can apply it without anyone formally signing off first. This suits small teams where the person editing the chart already has the authority to make the change, and the "approval" is really just informing the source owner it happened.
Require approval
Set Statuses that lock editing to the review status or statuses that should
freeze a chart — typically Approved, Final. Once a chart carries one of
those statuses (set via the Chart review status field, bound like any other
column), editing locks entirely until the status changes. The intended cycle: a reader edits a
Draft chart freely, submits it, an approver reviews the exported changeset and
either applies it or sends it back, and the status only moves to Approved once
that's happened — at which point the chart is read-only again until someone deliberately
reopens it.
This is a soft lock, not a security boundary. Statuses that lock editing stop a chart from being edited in Power BI's UI — they say nothing about who is allowed to write to your actual source. That enforcement has to live where the write happens: see the receiving flow's Authorize step below.
Where to set permissions
The visual has no concept of "this reader may edit, this one may not" — Edit Mode itself is gated only by having a valid license (see Licenses), not by identity. Real permission enforcement happens in two other places instead:
- Who can submit a changeset at all is naturally limited by who has Edit Mode unlocked and access to the report.
- Who can get a submitted changeset actually applied is enforced downstream — on the mailbox the changeset arrives at (the default path, via Email changes), or on the SharePoint library it lands in if you're using the file-drop alternative instead. Group membership checks against the source's own owning group is the reliable way to do this; see Authorize in the flow outline.
The receiving flow
The visual has no network path to reach your systems directly — adding one would disqualify it from AppSource certification — so a changeset always arrives as an email or a file, not a call. Something on your side has to pick it up, decide whether to trust it, and write it into your authoritative store. Power Automate is the natural fit if your source is already in Microsoft 365; the same stages apply to any equivalent (Azure Logic Apps, a small Azure Function, anything that can watch a mailbox or a folder and call your data store).
No flow ships with the visual. This section is a tested design for one, not a one-click import — your source (SharePoint lists, Dataverse, SQL), your group structure, and your notification preferences are specific to your organization. The full, detailed version of what's below — every field to check, every edge case found during development — is available as a downloadable outline to build from directly in Power Automate.
Three ways to receive one
All three feed the same validate/authorize/apply pipeline below — only how the changeset arrives differs.
| Trigger | How it works | Best for |
|---|---|---|
| When a new email arrives (default) | Email
changes already copies the changeset and opens Outlook Web with the approver's
address and subject filled in. An Office 365 Outlook trigger on that mailbox, filtered on
subject containing MilOrgChart Update ChangeSet, needs nothing else configured
on the report author's side. | Most reports. Changes arrive as they happen, with no extra setup beyond pointing the trigger at the approver inbox. |
| When a file is created (SharePoint — also works) |
Switch Format visual → Editing → Export as to Download and the Export changes button saves a real file instead, which the reader drops into a watched library. | Batching changes for review together, or organizations where email isn't the preferred handoff. |
| A Power App (embedded or standalone) | A text box for pasting the copied changeset, wired to a flow with a Power Apps trigger — can front either path above with a purpose-built review screen rather than replacing them. | Approvers who want a dedicated screen — a summary of the op count and comment before committing — rather than reading a changeset in an email or a file. |
What each stage does
| Stage | What happens |
|---|---|
| 1. Trigger | An email arrives at the approver inbox, by default — the visual has no network path, so email (or file-drop, or a Power App - see above) is the handoff. Filter the trigger on the subject line the visual always uses, so anything else in that inbox is ignored. |
| 2. Validate | Schema version matches, op_count equals the changeset's actual length, every op is a known type. Reject the whole batch on any mismatch — partial application is how charts end up with orphaned edges. |
| 3. Check revision | Compare base_revision against the source's current state. If they differ, someone else saved first — reject and tell the submitter to refresh and resubmit, rather than silently overwriting their draft. |
| 4. Authorize | Resolve the caller from an identity the submitter can't forge from inside the visual - the email's own From address, SharePoint's Created By, or the Power App user, depending on which trigger received it - and check it against the group that owns the chart's UIC. This is where edit rights are actually enforced — not in the visual. |
| 5. Apply, in order | Nineteen op types sorted into dependency phases — creates before the things that reference them, deletes after. Reject on any cycle in a proposed reporting chain. |
| 6. Write | Upsert into the authoritative store — SharePoint lists, Dataverse, or SQL. Never hard-delete: set is_active = false and stamp effective_to, so a billet's history survives it disappearing from the chart. |
| 7. Respond | Move the file to processed/, mail the submitter a confirmation naming the chart and op count, and append the envelope plus resolved caller to an audit log. |
| 8. Notify | Post to the Teams channel that owns the chart, so changes stay visible without anyone watching a list. |
Idempotent by design. The same file may arrive twice if a submitter
retries. Keying the write step on each op's own op_id is the simplest guard, and
the visual's own reconciliation on refresh means a duplicate apply is recoverable rather than
corrupting — ops whose end state already matches the data drop out of the reader's draft
automatically.
Alternatives to Power Automate
Anything that can watch a folder and call your data store works the same way:
- Azure Logic Apps — near-identical trigger/action model, better fit if the rest of your automation already lives in Azure rather than the Power Platform.
- A small Azure Function or scheduled script — more control over the authorization and validation logic, at the cost of building the plumbing Power Automate gives you for free (retries, run history, the visual designer for troubleshooting).
- A person, for a small team — someone reviews the emailed changeset and applies it by hand. Not automation, but a completely reasonable place to start; the envelope's ordered op list reads clearly enough to apply manually while volume is low.