Currently, when a record (such as a Case or Email) is routed through a record-based workstream and automatically assigned to an agent, the agent’s presence is updated to Busy, even if the Capacity Profile for that workstream is unit-based with a capacity value of 0.
This behavior prevents Voice workstreams from routing calls to that agent, since Voice routing only targets agents in the Available state.
In practice, this makes it impossible to automatically route Cases\Emails or other records without blocking voice capacity.
Expected Behavior:
There should be a supported configuration that allows record-based routing (e.g., Cases, Emails) to occur without consuming capacity or changing the agent’s presence.
Business Impact:
- Voice routing stops whenever an agent receives a Case or Email assignment, even if their workload is otherwise free.
- Prevents efficient blended operations across channels (Voice + Cases).
- Forces teams to rely on manual assignments or unsupported workarounds, reducing automation and productivity.
Suggested Enhancement:
- If the capacity model is unit-based and set to 0, record assignment should not impact agent presence.
- OR
- Introduce an explicit option (e.g., “Do not affect agent presence on record assignment”) in record-based workstreams or capacity profiles, allowing records to be routed while maintaining the agent’s current presence.
Comments
As a customer running a production contact centre, I strongly support this idea and want to emphasize that email handling should be configurable by the client, particularly in how it impacts agent presence and capacity.In most contact centre platforms, email is treated as an asynchronous interaction, while voice is a real‑time, exclusive interaction. Agents can typically work on multiple emails concurrently but can only handle one voice call at a time. As a result, many contact centres intentionally operate so that:Email work does not automatically set agents to BusyEmail work does not block inbound voice callsVoice interactions always have priorityThe number of concurrent emails per agent is configurableToday, Dynamics Contact Center can treat email more like a live interaction than many customers expect, particularly when email assignment affects presence and blocks voice calls. While this can sometimes be mitigated through capacity and routing configuration, this behavior should be explicitly configurable, not an implicit side effect.Customers should be able to decide:Whether email assignment changes agent presenceWhether email consumes blocking or non‑blocking capacityHow many emails an agent can work at onceWhether voice always pre‑empts email workThese are business decisions, not technical ones, and vary by organization and role. Making asynchronous vs real‑time behavior configurable would better align Dynamics Contact Center with established contact‑centre operating models and customer expectations.
Category: Unified Routing- Assignment
I agree—this doesn’t seem to make sense. Contact center agents statuses shouldn’t automatically change to Busy each time an email is assigned. Agents should continue to receive calls while tickets are being assigned. The current behavior is slowing them down, as they have to manually set themselves back to Available after each email assignment or else they don't get calls.
Category: Unified Routing- Assignment
It is very difficult to manage the agents and have full visibility on whether they are on a call or have been presented with an email. We need them to be available to take a call while they work in emails. The system putting them on busy when being presented with an email does not work with our work flow.
Category: Unified Routing- Assignment
100% agreed, this is a massive requirement for a call center using any ARC rules to monitor mailboxes as well. We can't have our contact center agents' status change to busy every time they get an email assigned.
Category: Unified Routing- Assignment
Additional clarification: Although voice workstreams can technically be configured to route calls to agents in the Busy state, in our environment we intentionally use Busy to indicate that an agent is already engaged in a live chat, so voice should not route to them in that case.When record-based assignments (like Case or Email) also push agents to Busy, this logic is disrupted, because it falsely marks the agent as busy even when they aren’t handling a live interaction.This makes it difficult to maintain clear presence logic across channels (e.g., Voice should only avoid agents who are busy with chats, not those assigned to backend records).
Category: Unified Routing- Assignment