What it does

Getting a person from "hired" to "taking work" in Customer Service is a chain: create them in Microsoft 365, licence them, land them in Dataverse, give them roles, then set the service-specific attributes — skills, queues, capacity and presence — that routing and the agent experience depend on.

Key facts

• Users are created and licensed in the Microsoft 365 admin center first. They sync into Dataverse; you don't create them in Customer Service.
• The admin centre offers an enhanced user management experience alongside the classic Omnichannel tab on the user form. The enhanced one is where bulk work happens.
• Bulk operations handle up to 200 users at a time and up to 5 attributes per operation. More than five attributes means saving and repeating.
• Attributes you can set in bulk: skills with proficiency (activate, deactivate, remove), queue membership, capacity profiles, and the active conversation limit, which accepts 1 to 100.
• Classic capacity is a plain number that has to be a multiple of the workstream's capacity unit — capacity unit 5 and three concurrent conversations means a user capacity of 15, not 3.
• Default presence on the user record sets the status a user signs in with.
• Skill-based routing requires users to exist as bookable resources, with bookable resource characteristics carrying rating values. Work hours on the bookable resource depend on Universal Resource Scheduling.
• Microsoft's recommended assignment pattern is an Entra security group, a group team in the Power Platform admin center with team type Microsoft Entra ID Security Group, and roles on the team — but persona mapping needs roles assigned directly to the user.
• Everyone needs Basic User. Agents need Customer Service Representative to work cases, and Omnichannel agent if conversation channels are in play.
• Admins configuring workstreams, channels or authentication settings need column security profiles for the secure columns on those tables.

When to use / skip

Every project does this, so the question is only how much of it you automate. Under about fifty agents with a stable roster, manual provisioning through the admin centre is fine and the enhanced bulk editor covers reorganisations. Above that, or where the client has seasonal hiring, you want the Entra group team route with joiner-mover-leaver driven by the identity team, and you accept that anything persona-dependent still needs a direct role assignment step.

Skip capacity profiles entirely if there are no conversation channels — a case-only deployment doesn't need them and setting them up "for later" just creates configuration nobody maintains.

Configuration decisions

• Group teams versus direct assignment, and how you cover the persona-mapping requirement if you choose groups.
• Whether capacity is modelled with capacity profiles or the older numeric capacity — profiles per channel are the current approach, and mixing the two is where the confusion starts.
• The starting active conversation limit. Matching it to the capacity value reproduces existing behaviour with no surprises, which is the safe opening position.
• Which skills exist, what the rating model is, and who owns adding a new skill when the business invents one — that's a live operational process, not a one-off setup task.
• Whether queue membership is managed on the user, on the queue, or through team membership. Pick one and hold the line.
• What happens at leaver time: disable the user, reassign their open work, and decide whether the licence is released immediately.

Gotchas

• Disabling a user in Microsoft 365 does not reassign their open cases or their queue items. Work sits in a dead queue member's name until someone notices.
• Capacity that isn't a multiple of the workstream capacity unit doesn't error — it just routes a number of conversations nobody expected.
• The bulk editor's five-attribute cap is per operation, not per session. A large reorganisation is several passes, and partial completion looks identical to success.
• A user with the right roles but no bookable resource record is invisible to skill-based routing. Nothing warns you.
• Group teams give privileges but not persona identity. Agents end up in the wrong experience profile and the roles look correct on inspection.
• Licence assignment and security role assignment are independent. A user can hold a Customer Service licence and no roles, or roles and no licence, and both fail in different confusing ways.

Consultant notes

• Build the leaver process during implementation, not after. Reassigning work from departed agents is the most common first-year support ticket on a service deployment.
• Show the client's ops lead the bulk user editor and let them run a change themselves in UAT. If they can reorganise teams without you, the deployment has landed.
• Get the identity team into a design session early if you're going the Entra group route. Dynamics role assignment usually sits outside their existing process and they will not enjoy discovering it at UAT.
• Check before go-live that every agent in the pilot group has: licence, Basic User, the service role, queue membership, capacity profile and a bookable resource. Missing any one of the six produces a different failure.
• Don't let the client define forty skills at design stage. Start with the handful that actually change routing and add more once they can see the effect.

---

Worth another look if the client's identity model changes, or when capacity profiles fully replace numeric capacity.