What it does

An in-app Power BI editing surface that lets an authorised user change the out-of-box analytics reports in place — swap visual types, add metrics that exist in the semantic model but not on the default page, add filters, restyle and re-lay-out. Changes are published back into Copilot Service workspace for everyone.

Key facts

• Editing requires the Analytics Report Author role. It is not part of System Administrator by default, and handing it out is a deliberate decision.
• Supported report sets: Customer Service historical analytics, Omnichannel historical analytics, Omnichannel real-time analytics, and real-time analytics for record routing.
• Not customisable: unified routing reports and knowledge analytics reports.
• No extra licence is needed to customise the embedded reports inside Copilot Service workspace. The Fabric-based custom data model route is a different thing with different licensing.
• The flow is Edit report, change, Save, then Publish. After publishing you carry on with Resume editing.
• Reverting is Edit report, Checkout default report, then Reset. Reset permanently discards customisations — there is no version history to roll back to.
• Published changes are visible to every user in the organisation. There is no per-user, per-role or per-team variant of a report.
• Microsoft documents a working limit of around 20 metrics or tiles per report page before performance degrades; the recommended pattern beyond that is multiple pages with navigation between them.
• Customisations survive Microsoft's updates to the default data model, but if metric naming changes in a wave you may need to reselect the affected metrics.
• You can only surface metrics and dimensions that are already in the semantic model. Anything else means data model customisation first.

When to use / skip

This is the right tool for the 80% of report requests that are really presentation requests. "Can we see this as a table", "can we add the escalation rate tile", "can we default the filter to our queue" — all of that is ten minutes in the editor and no infrastructure.

It is the wrong tool the moment someone wants a field that is not in the model, a different calculation of an existing measure, or a report that only one team can see. Those are model-customisation or separate-workspace problems, and trying to force them through the embedded editor produces a mess that the next consultant has to unpick.

Be careful about how freely you hand out the author role. Because published changes hit everyone, a well-meaning supervisor who tidies a report on Friday afternoon changes what the whole organisation sees on Monday. On larger service desks, keep authoring with one or two named people and run report changes through a lightweight change process. On a twenty-seat desk, that is overkill and you can give it to the service manager.

Configuration decisions

• Who gets the Analytics Report Author role, and whether report changes need any kind of approval before publishing.
• Whether you customise the default reports in place or leave them untouched and build separate custom reports through the Fabric route. Mixing both without documenting which is which gets confusing fast.
• Which environment report customisations are authored in, and how they get to production. There is no solution-aware export here, so in practice it is manual reapplication.
• Whether the requested change genuinely fits inside the existing semantic model, or is a model change wearing a visual change's clothes.
• How many tiles you allow per page before splitting into a second page, given the roughly 20-metric guidance.
• Whether you keep a documented record of what was changed from default, since Reset is the only recovery and it takes everything with it.

Gotchas

• Reset is all-or-nothing and permanent. There is no undo and no per-change rollback, so an afternoon's careful work goes in one click if someone reaches for it to fix a single broken visual.
• The organisation-wide visibility of published changes surprises everyone. Consultants demonstrate the editor to a supervisor, the supervisor experiments, and the service manager rings you about the reports changing.
• Customisations do not travel between environments in a solution. Whatever you build in test, someone rebuilds by hand in production — budget for it, and keep screenshots.
• Metric renames in a Microsoft wave can leave a customised visual pointing at nothing. It does not fail loudly; the tile just goes empty and someone notices weeks later.
• Piling tiles onto one page to satisfy a stakeholder wish list is the usual cause of "the reports are slow". Split pages before the client blames the platform.
• The Analytics Report Author role is easy to forget in the go-live security matrix, and its absence looks identical to the feature being broken — the Edit report option simply is not there.

Consultant notes

• Show the editor to the client, but frame it as controlled: one or two authors, changes agreed, not a free-for-all. Clients that treat it as self-service end up asking you to rebuild the defaults.
• Keep a written record of every deviation from default, page by page. It is the only documentation that exists, and it is what makes the production rebuild survivable.
• Use the editor as the first answer to report requests during UAT. Most requests collapse into a visual change, which keeps custom model work off the critical path.
• Before go-live, confirm the author role assignment and do one full edit-save-publish cycle in production so you know the round trip works with the client's tenant settings.
• Push back on per-team report variants here. That requirement points at filters and bookmarks, or at the custom data model route, not at the embedded editor.

---

Worth revisiting if Microsoft adds versioning or role-scoped report visibility — the all-users publish model is the main constraint today.