Experience profiles and app profile manager

What it does

An experience profile is the per-persona configuration layer over the workspace app: which session templates apply, which productivity pane tools appear, whether the inbox is on, which channel providers are wired up. You build profiles in the app profile manager (now surfaced as Workspaces > Experience profiles in the Copilot Service admin center) and assign users to them, so one app module can serve several very different agent experiences.

Key facts

Three out-of-the-box profiles ship and cannot be edited or deleted: Omnichannel for Customer Service - default profile, Customer Service workspace - default profile, and Customer Service workspace + channels - default profile.
Because the defaults are locked, any real project creates a custom profile. Scripts in particular are not available in the out-of-the-box workspace profile — you get smart assist and knowledge search only.
Creating and managing profiles needs the App Profile Manager Administrator role alongside Basic User.
A user can hold more than one profile. Rank decides which one wins, set through Set rank and roles on the profile's user list.
Profiles can also be assigned by security role rather than named user, which is the only version that survives a growing team.
One profile can be marked as the default, applying to everyone who isn't explicitly assigned.
Productivity pane tools toggled per profile include Copilot, Knowledge search, Agent scripts, Smart assist, Join a Teams call, Teams chats, Case handling time, Screen recording and Timeout rules, plus the pane's default mode (expanded or collapsed).
The inbox is a per-profile toggle with its own view configuration behind a Settings icon.
Session templates are linked to the profile; you either pick existing templates or create them from inside the profile.
Channel providers — including third-party voice providers registered through Channel Integration Framework — are enabled per profile.
Custom productivity tools built as custom pages or PCF controls are distributed through profiles, which is how you get a bespoke tool into the right agents' pane without touching the app module.

When to use / skip

You don't get a choice about whether profiles exist — the workspace app is driven by them. The real decision is how many. One profile per genuinely distinct persona is right; one per team, per site or per queue is a maintenance trap. On a typical delivery you'll end up with two or three: front-line agents, a supervisor variant, and perhaps a specialist back-office group with a different session template set. If you find yourself designing seven profiles, the differences are usually security roles and views, and belong there instead.

Configuration decisions

Profile granularity: how many personas actually need a different pane, inbox and session behaviour.
Assignment model: named users, security roles, or a default profile as the catch-all. Pick one and be consistent, because mixing them makes rank conflicts hard to trace.
Rank ordering, if any user will legitimately hold two profiles — supervisors who also take work are the usual case.
Which productivity tools are on for each persona, and whether the pane starts expanded or collapsed. Expanded costs screen width on 1366-wide laptops.
Whether the inbox is on, and for which record types, per persona.
Whether custom productivity tools are needed at all, and if so whether they're custom pages or PCF controls — that decision affects who can maintain them.

Gotchas

Profiles are configuration data, not solution components in the way people expect. Moving them between environments needs a deliberate data-migration approach; they don't ride along with your solution by default. Budget for it in the release process.
Users assigned individually to a profile don't move environments either, so a UAT-tested profile can land in production with nobody on it.
The locked default profiles catch people out mid-demo: an admin turns on agent scripts, nothing happens, because the users are still sitting on the out-of-the-box profile.
Rank conflicts fail quietly. An agent on two profiles gets one of them, and the one they get is rarely the one the client expected.
Removing a tool from a profile does not remove the underlying records. Agents lose the pane control while the scripts and macros sit there looking configured.
Changes to a profile generally need the agent to sign out and back in before they take effect. Testers who just refresh will report the change as broken.

Consultant notes

Build the custom profile on day one of configuration, even if it starts as a clone of the default. Everything else hangs off it, and retro-fitting it means re-testing every session behaviour.
Show the client the profile screen early. It's the clearest way to explain why "just turn that on for everyone" is not how this app works.
Write down which security roles map to which profile and keep it with the security matrix, not in a separate document. They drift apart otherwise.
Include profile assignment in your go-live checklist explicitly — it's the step most often missed on cutover weekend, and the symptom is agents opening a workspace with an empty productivity pane.
Push back on per-team profiles. Offer views, security roles and inbox views as the cheaper way to get the same difference.

Worth another look if Microsoft changes how profiles move between environments, or if the admin centre reorganises Workspaces again.