Most Customer Service Management implementations I get called into have the same shape of problem. The case model is fine. The portal is fine. What is broken is the two minutes between “a customer reached out” and “the right agent is looking at it.” That gap is where Advanced Work Assignment lives, and it is the part teams most often configure by trial and error until something sticks.
Advanced Work Assignment — AWA — is ServiceNow’s push-based routing engine. Instead of work sitting in a group queue waiting for someone to notice it, AWA evaluates incoming work items, finds an eligible agent with the right skills and free capacity, and pushes the item into that agent’s inbox with an accept timer. It is a genuinely good engine. It is also one where a handful of misunderstood objects produce most of the pain, so it is worth walking through the pieces in the order the platform actually evaluates them.
The four objects that matter
Almost everything in AWA reduces to four records working together.
| Object | Table | What it decides |
|---|---|---|
| Service channel | awa_service_channel | What kind of work this is, and what it costs an agent |
| Work item queue | awa_queue | Which pool of work an item lands in, and who can serve it |
| Assignment criteria | queue-scoped criteria | Which agent inside that pool gets it |
| Agent presence | awa_agent_presence | Whether an agent is eligible to receive anything at all |
Work flows through them in that order. A record becomes a work item on a channel, the channel’s queues are evaluated top to bottom until one matches, the queue’s assignment criteria pick an agent, and presence and capacity decide whether that agent can actually take it. When routing “doesn’t work,” it has almost always stopped at one of those four gates — and knowing which gate saves hours of guessing.
Service channels
A service channel represents a type of work: chat, case, phone, walk-up, or a custom channel you define for something like a partner escalation. Two settings on it do the heavy lifting.
The first is the document table the channel routes. Out of the box you get channels for interaction, sn_customerservice_case, and a few others. If you want to route a custom table — a warranty claim, say — you create a channel for it, and that is a legitimate thing to do rather than a hack.
The second is capacity cost. Each channel declares how much of an agent’s capacity one item consumes. This is where most teams under-think it. A live chat and an email case both being “1” means an agent juggling three chats looks identical to the engine as an agent with three emails sitting in their inbox — and those are not remotely the same workload. Weighting chat higher than asynchronous work is usually the first tuning change worth making.
Work item queues
Queues are where routing decisions get expressed, and they are evaluated in order. Each queue carries:
- a condition on the source record (priority, account, product, contact type, category)
- an assignment eligibility definition — a group, a list of groups, or a script
- a routing condition for when the queue is active at all
- an order number
The ordering is the part people miss. AWA takes the first matching queue and stops. A generous catch-all queue at order 100 will happily swallow every P1 if your P1 queue sits at order 200. When a client tells me “the VIP routing stopped working,” the fix is a reorder about half the time.
Keep the queue count low. It is tempting to model every product line, region, and tier as its own queue, and you end up with forty queues nobody can reason about. Queues should represent genuinely different pools of people. Everything else — nuance about who inside that pool is best suited — belongs in skills.
Skills
Skills (cmn_skill) are attached to users through sys_user_has_skill, and to work items through skill determination rules that read the source record and stamp the required skills onto the work item. AWA then only considers agents holding those skills.
Two properties are worth understanding before you commit to a skill model:
- Skills can be mandatory or optional. Optional skills act as a preference — the engine favours agents who have them but will not stall the item if nobody does.
- Skills have levels, and a determination rule can require a minimum level. This is how you keep a tier-1 agent from receiving a case that needs a tier-3 specialist without maintaining separate groups for every competency.
The failure mode here is over-specification. Every mandatory skill you add narrows the eligible agent pool, and a work item whose skill requirements no one satisfies simply sits in the queue, unassigned and silent. Make skills mandatory only when routing to an unskilled agent would be actively wrong; make everything else optional. Then actually run a report on average time-to-assignment per queue, because that number is where over-specification shows up first.
Presence and capacity
An agent receives work when they are in an available presence state and their consumed capacity is below their maximum. Both halves matter. Agents who forget to set themselves available at the start of a shift are the single most common cause of “the queue is backing up and nobody knows why,” which is a process problem you solve with presence automation and a supervisor view, not with more routing configuration.
Capacity is defined per agent, per channel, on the agent’s presence record. The engine’s job is to keep every available agent at or near their ceiling without going over. If your ceilings are set generously — five chats each — you will get fast assignment and slow resolution, because agents thrash. Lower ceilings feel worse on the queue dashboard and are usually better for customers.
From interaction to case
Routing an interaction is only half of the story. The other half is what the agent does with it — and this is where CSM implementations either stay clean or slowly turn to mud.
An interaction record is the conversation: a chat session, an inbound call, a walk-up. It is deliberately lightweight and deliberately transient. A case is the unit of work with an SLA, an account, a contact, entitlements, and a lifecycle. These are not the same thing, and the temptation to collapse them — one interaction, always one case — should be resisted, because real support does not work that way:
- A customer asks a question that is answered in ninety seconds. That is an interaction with no case. Forcing a case creates a record that exists only to be closed, and it poisons every metric that counts cases.
- A customer raises three unrelated problems in one chat. That is one interaction and three cases.
- A customer follows up on an existing case. That is a new interaction linked to an existing case.
The platform models this with the interaction_related_record table — a many-to-many join between interactions and whatever they touch. Agent Workspace gives agents a Create case and a Link to existing case action, and both write through that table. The right implementation guidance is short: create a case when there is work that outlives the conversation, and link rather than create when the customer is continuing something.
There is a second routing decision hidden in here that teams frequently miss. When an interaction becomes a case, the case is routed again — as a new work item on the case channel — and there is no rule that says it must land with the agent who took the interaction. Sometimes it should: the agent has context, and bouncing the customer is rude. Sometimes it should not: the interaction agent is a generalist and the case needs a specialist. Decide this deliberately per case type rather than letting whichever behaviour you configured first become the accidental standard, and encode the decision in your queue conditions so it survives the person who made it.
Debugging routing that isn’t working
When work is not reaching agents, walk the gates in order rather than changing settings hopefully.
- Is there a work item at all? Check
awa_work_itemfor the source record. No work item means the channel condition never matched — the problem is upstream of routing entirely. - Which queue did it land in? The work item stores its queue. If it is the wrong one, you have a queue ordering or condition problem.
- What skills were stamped on it? Compare against agents who actually hold those skills. An empty eligible pool is the classic silent failure.
- Who is available, and at what capacity? If the pool is real but everyone is at their ceiling or offline, this is a staffing or presence problem wearing a configuration costume.
That ordering matters because each gate is cheap to check and eliminates a whole class of causes. Most teams start at step four, adjusting capacity, when the actual fault was at step two.
Where this fits in a wider platform
AWA is a routing engine, not a strategy. It will faithfully deliver work to the wrong people if your channel model, account data, or case taxonomy is wrong underneath it — which is why routing work is nearly always foundation-data work in disguise. If you are standing up CSM from scratch, or inheriting an implementation where nobody remembers why the queues are ordered the way they are, that is the kind of engagement our ServiceNow development and architecture practice takes on: unpick the routing model, get it back to something a human can reason about, and leave the team able to change it themselves.
It also rarely stops at the platform boundary. Routing decisions usually depend on data living in a CRM, a billing system, or an entitlement service, which means integrations and automation work sits alongside the AWA configuration more often than not. And if the surrounding portal experience is the real bottleneck, the architecture trade-offs around custom UI versus native widgets are worth reading before you commit to either.
If your queues have quietly grown past the point where anyone can explain them, get in touch — that conversation is usually shorter and more productive than another round of trial and error.