Almanac
Microsoft/d365csDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Service: implementation notes, gotchas, and configuration decisions beyond the official docs — across case management, queues and routing, knowledge base, SLAs, omnichannel, agent experience, Copilot, analytics, and administration.

feature-routing-capacity-profiles.mdv1 · history
CurrentApplies to EnterpriseUpdated 6 days agoSource Microsoft Learn

What it does

Capacity is how unified routing decides whether someone has room for another work item. You either give each person a pool of abstract units that work items draw against, or you define named profiles — "open cases", "escalations" — each with its own limit, and attach the relevant profile to the work.

Key facts

  • Two models: unit-based and profile-based. Microsoft's guidance is to pick one per environment rather than run both, and that is sound advice — mixing them makes capacity impossible to reason about.
  • Profiles are created under User management > Manage capacity profile. The fields that matter are Profile name, Work item limit and Reset frequency.
  • Reset frequency is Immediate or End of day, and it cannot be changed after creation. Getting it wrong means building a new profile and reassigning everyone. This is the one-way door in this feature.
  • Assignment blocking set to Yes stops automatic assignment once the limit is reached and puts the person into Busy-DND. It blocks both profile-based and unit-based work.
  • Individual limits can override the profile default via Enhanced user management > Update capacity profiles > Custom limit, or by setting msdyn_maxunits on msdyn_bookableresourcecapacityprofile. Setting it to null restores the profile default.
  • A workstream has a default capacity setting, and classification rulesets can attach further profiles. Assignment then needs headroom in all attached profiles, and consumes from all of them at once.
  • Capacity release differs sharply by work item type. Conversations release when the session closes. Cases release on resolve or cancel, or when Worked By is cleared. Other records and activities release nothing automatically — you have to deactivate or delete the queue item.
  • Users must be bookable resources to hold capacity profiles at all.
  • Negative available capacity is a real and expected state: it happens when someone picks work manually or is assigned past their limit.
  • Monitoring a conversation doesn't consume capacity; working it does.
  • An escalation profile is applied automatically when a chat escalates to voice or video, and follows the call on transfer. That one is Contact Center territory rather than Customer Service proper.
  • Configuration changes take up to 15 minutes to reach the routing service.

When to use / skip

If you're using unified routing for records, you're using capacity whether you think about it or not — highest-capacity assignment is meaningless without it. The real decision is units versus profiles.

Units are simpler and fine for a single-work-type desk: one number per person, cases cost one unit each, done. Profiles earn their place when the client wants different ceilings for different kinds of work — say twenty open cases but only three live escalations — or when the same person handles records alongside conversations and you need those budgets kept apart. That is the common shape in a Customer Service build that also touches Contact Center, and it's worth the extra configuration.

Skip elaborate profile modelling on a first release. Two profiles is usually plenty. I've never seen a client benefit from six, and every extra profile multiplies the ways an assignment can silently fail because someone is full on a dimension nobody's looking at.

Configuration decisions

  • Units or profiles, environment-wide. Decide once and write it down; a half-migrated environment is genuinely hard to debug.
  • The reset frequency for each profile, before you create it. Immediate suits case work where the limit means concurrent load; End of day suits shift-based work where the limit means a daily allocation.
  • Work item limits per profile, and which roles get custom limits. New starters at a lower limit is the usual first request.
  • Whether assignment blocking is on. Blocking protects people and creates backlog; not blocking keeps work flowing and lets individuals drown.
  • Which profiles are workstream defaults and which are attached conditionally by classification rules.
  • How capacity gets released for non-case records — this needs a deliberate mechanism, not an assumption.

Gotchas

  • Reset frequency cannot be edited. Every project that gets this wrong discovers it after the profile is assigned to two hundred people.
  • Activities and non-case records never release capacity on their own. Without a deactivate-the-queue-item step, agents fill up permanently and routing quietly stops. This is the classic month-two incident.
  • Cases release capacity on resolve, so a team with a habit of leaving cases open at "pending customer" will run at full capacity all week. Either change the process or reconsider the limit.
  • Multiple attached profiles mean an assignment fails if any one is full. The diagnostics will tell you which; the agent will just say the queue is stuck.
  • Custom limits set through msdyn_maxunits are invisible in most reporting. Undocumented per-user limits are a nasty thing to inherit at handover.
  • Assignment blocking flips presence to Busy-DND, which supervisors read as "they've gone to lunch". Explain the state before go-live or you'll get workforce management complaints.
  • Bulk-assigning capacity profiles above roughly 500 change requests per 15 minutes produces inconsistent data. Batch it and verify.

Consultant notes

  • Get the client to state a target concurrent caseload per person before you configure anything. If they can't, use their current average open cases per agent as a starting point and revisit in month two.
  • Demo assignment blocking hitting its limit, including the presence change. It's the behaviour supervisors care about most and the one they're least prepared for.
  • Push back on capacity as a performance management tool. It's a routing control; using it to police productivity produces gaming and bad data.
  • Before go-live, prove capacity release end to end for every routed record type — not just cases. Route it, assign it, complete it, check the number goes back up.
  • Put the profile definitions, limits and any per-user custom limits into the handover document. Nobody will find them later otherwise.

Worth another look if the client adds conversation channels alongside records, or if capacity release for activities changes in a future wave.

Was this accurate?