Security roles and persona mapping for service

What it does

Customer Service ships a set of security roles, and on top of Dataverse's normal role-based security it adds a persona layer — Admin, Supervisor and Agent — that several features use to decide which experience a user gets. Persona mapping is the page where you tell the product which security roles count as which persona.

Key facts

Three personas exist: Admin, Supervisor, Agent. You can't create a fourth.
Default mapping for Customer Service Enterprise: CSR Manager maps to both Admin and Supervisor, Customer Service Representative maps to Agent. Dynamics 365 Contact Center brings its own mapping (Omnichannel Administrator, Omnichannel supervisor, Omnichannel agent). If both services are enabled you get both sets.
A custom role is only mappable if it carries one of the privileges prvAgent, prvSupervisor or prvAdmin. Without one of those it won't appear as a candidate.
Roles used for persona mapping must be assigned directly to the user. Assignment via team membership does not register for persona purposes.
Custom roles are created at organisation or business unit level; Microsoft's recommended starting point is Copy Role from one of the shipped roles rather than building from an empty role.
Mapping is done in the Copilot Service admin center under User management > Role persona mapping, persona by persona, ticking roles in the Edit roles pane.
Once you've customised a mapping, it isn't reset if another service (Contact Center, for example) is added to the environment later.
Mapping a custom role to a persona does not by itself grant access to the apps, dashboards or forms that persona normally sees. Those are separate app role assignments and form/dashboard security settings.
Everyone needs Basic User in addition to whatever service role they hold.
Omnichannel API access is a service-to-service role. Don't put it on supervisors or agents.
Settings that write to secure columns — authentication settings, SMS settings, payment profiles — need column security profiles on top of the security role.

When to use / skip

You cannot skip the persona layer if you're using anything that keys off it, which in practice means agent experience profiles, supervisor tooling and a growing list of Copilot features. What you can skip is inventing a custom role estate on day one. Most service deployments run perfectly well on Customer Service Representative and CSR Manager plus one or two copies with tightened record access.

Build custom roles when the client genuinely has more than three service populations — say, a triage tier that can create cases but not resolve them, or a back-office team that reads cases but never owns them. Building custom roles because a client has an existing role naming convention is a bad trade: you inherit the maintenance of every privilege Microsoft adds in each wave.

Configuration decisions

Whether to copy a shipped role or extend it, and which one — the copy is a point-in-time snapshot and will not pick up privileges Microsoft adds to the original later.
Which persona each custom role maps to, and whether a single role can reasonably be both Supervisor and Admin as CSR Manager is out of the box.
Whether roles are assigned to users directly, to owner teams, or to Entra group teams — and how you reconcile that with the direct-assignment requirement for persona mapping.
Which business unit each custom role is created in, and whether you need the same role in several units.
Which privileges you actually tighten: case delete, queue management, knowledge publish and bulk delete are the usual four.
Whether admins get System Administrator or a narrower combination such as Omnichannel administrator plus Basic User.

Gotchas

The direct-assignment rule catches nearly everyone. A client with a mature Entra group team model assigns all roles through groups, personas resolve to nothing, and agents get the wrong workspace with no error message anywhere.
A custom role copied from Customer Service Representative and then mapped to the Agent persona still won't show the agent dashboards unless you separately grant the app and the dashboard. People spend hours on the role editor for a problem that isn't in the role editor.
Copy Role duplicates privileges but not future updates. After two or three waves, a copied role and its parent have drifted, and the symptom is a feature that works for one user population only.
Privilege names in the role editor don't match the friendly feature names in the admin centre. Searching for the feature name will not find the privilege.
Omnichannel administrator without Basic User looks like it should work and mostly doesn't.
Roles are solution-aware but role assignments are not. Moving a solution between environments moves the role and leaves every user unassigned.

Consultant notes

Ask for the client's target role list before you configure anything, then argue it down. Three to five service roles is healthy; fifteen is a support burden nobody costed.
Demonstrate the persona mapping page to the client's admin team explicitly. It is not a page anyone finds by accident, and it is the first thing to check when an agent reports the wrong app experience.
Before go-live, log in as a real member of each role in the target environment. Testing as a System Administrator with role impersonation is not the same test.
Document which shipped role each custom role was copied from and when. The next consultant needs it to work out what has drifted.
Push back on requests to grant System Administrator to supervisors "temporarily". It never comes back off, and it invalidates all your record access design.

Worth revisiting if Microsoft adds a persona, or if the client moves to group-team role assignment.