What it does
Copilot in Customer Service is gated at four independent layers: a tenant switch in the Power Platform admin center, an AI terms opt-in, feature toggles in the Copilot Service admin center, and per-rep control through security roles and agent experience profiles. All four have to line up before a rep sees anything.
Key facts
- The master switch is Enable AI-powered Copilot features in the Power Platform admin center under Copilot > Settings > Copilot > Dynamics 365 Customer Service. It needs System Administrator and nothing below it works without it.
- You must also accept the AI terms in the Copilot Service admin center. Setup does not complete until someone does, and it is a commercial acceptance, not a technical step.
- Feature toggles live under Support experience > Productivity > Copilot settings > Manage: Copilot immersive (Copilot Service workspace only) and Copilot side pane (workspace and Customer Service Hub). Summaries are configured separately under Operations > Insights > Summaries.
- Regional gating is real. Environments in the US, Australia, India, the UK, Europe with default data movement, and GCC/GCC High get Copilot in-region. Everywhere else requires data movement across regions enabled in the Power Platform admin center — again a decision with a data-residency conversation attached.
- Microsoft documents several Copilot features as GA in North America and preview in other supported regions, including respond to questions, compose email and summarisation. The GA/preview label a client sees depends on where their environment sits.
- Out of the box only the Customer Service Representative role carries Copilot access. Custom roles need privileges added explicitly.
- The tables that matter for custom roles:
msdyn_copilotevent,msdyn_copilotinteraction,msdyn_copilotinteractiondata,msdyn_copilotagentpreferenceandmsdyn_copilottranscriptdata, plus theprvIntelligenceUsagemiscellaneous privilege. - Agent experience profiles are the per-rep control surface. Default profiles have Copilot features on; custom profiles are how you give one team Copilot and not another.
- Record transcripts of representative interactions with Copilot under Copilot settings > Support experience data captures what reps do with Copilot, including their feedback. It's optional and has obvious privacy implications.
- Rep feedback on Copilot responses lands in the
msdyn_copilotinteractionandmsdyn_copiloteventtables, verbatim comments included, and can be queried directly. - Optional data sharing with Microsoft is a separate tenant setting in the Power Platform admin center, disabled by default for Azure OpenAI training. Opting out from the Copilot settings or Summaries pages erases the associated training data.
- The Admin Management Agent is preview and has its own User access tab: all reps with Copilot, or specific security roles.
When to use / skip
There's no skipping this — it's the plumbing under every other Copilot doc. What varies is how much of it you design deliberately. A small deployment can run on the default rep role and default experience profiles and be fine.
Design it properly where the client is phasing Copilot rollout by team, running a pilot group, or has an information security function that will ask what data leaves the environment. In those cases the experience profile layer and the transcript setting are the two things to get on paper before enablement, because retro-fitting a "why did everyone suddenly get Copilot" answer is unpleasant.
Also design it properly where the client has heavily customised security roles — which is most enterprise deployments. The default assumption that the Customer Service Representative role is in play is frequently wrong.
Configuration decisions
- Whether to enable cross-region data movement, and who in the client organisation signs that off. This is a data-residency decision, not an IT one.
- Which Copilot surfaces are on: immersive, side pane, or both, and whether Customer Service Hub users are in scope at all given immersive is workspace-only.
- Which agent experience profiles carry which Copilot features, and therefore how the pilot cohort is defined.
- Whether custom security roles get the Copilot privileges, or whether reps are given the out-of-the-box role alongside their custom one.
- Whether interaction transcripts are recorded, and what the retention position on that data is.
Gotchas
- Missing
prvIntelligenceUsageon a custom role is the classic failure. Copilot appears but produces errors or nothing, and the error text points nowhere useful. - Enabling a Copilot feature in the admin center does not push it to reps if their experience profile doesn't include it. Two separate places, and admins routinely only check one.
- The GA-versus-preview status of the same feature differs by region. A client reading Microsoft's docs and seeing "generally available" may be running a preview feature, with the support implications that carries.
- Cross-region data movement is a tenant-level, hard-to-reverse commitment in practice. Get it agreed early rather than discovering it blocks a UAT date.
- The transcript recording toggle is easy to flick during setup and awkward to explain later. Treat it as a privacy decision with a named approver.
- Copilot Studio-based agents do not inherit these toggles. Turning Copilot off in the admin center does not stop an autonomous agent that's billing against PAYG.
- Immersive Copilot is Copilot Service workspace only. Clients still standardised on Customer Service Hub get the side pane and nothing else, and that's not always understood when the licence is bought.
Consultant notes
- Produce a one-page enablement checklist covering all four layers and walk the client's admin through it. This is the single most useful artefact you can hand over on a Copilot workstream.
- Test with a real restricted role before UAT, not with a System Administrator account. Everything works for a sysadmin, which is exactly why sysadmin testing proves nothing here.
- Get the data-residency and transcript decisions into a written record with the client's information security owner. These are the two questions that come back at go-live review.
- If the client wants Copilot usage reporting, point them at the Copilot interaction and event tables rather than promising a dashboard — the verbatim feedback in there is genuinely useful for tuning.
- Push back on enabling everything at once. Summaries and Ask a question first, email and agents later, is a rollout order that keeps the support load survivable.
Worth another look if the regional GA/preview split closes, or if the required Copilot privileges change with a new release.