Introduction

ServiceNow AWA (Advanced Work Assignment) is used to automate the routing of work items to agents instead of relying on manual assignment or static assignment groups alone. In a typical ServiceNow implementation, customers may receive incidents, cases, chats, interactions, or other requests through different channels. AWA evaluates these work items and routes them through queues and assignment rules before pushing eligible work to an appropriate agent.

This becomes particularly important in environments where the service desk handles a high volume of simultaneous requests. A simple assignment group such as “Service Desk” may identify the team responsible for the work, but it does not necessarily determine which individual agent should receive the next item.

AWA adds another layer of intelligence to this process.

For example, suppose a customer-support organization has 20 agents handling technical cases. Five agents are currently available, three are already working at their configured capacity, one has a required product skill, and another has just completed a previous interaction. Instead of assigning the next case manually, AWA can evaluate availability, capacity, skills, presence, queue priority, and assignment strategy before routing the work.

This article explains AWA from an implementation perspective, including its architecture, prerequisites, configuration approach, routing logic, testing strategy, troubleshooting techniques, and practical consultant considerations.

Version note: AWA configuration details can vary by ServiceNow release and enabled applications. The current ServiceNow documentation referenced here includes the Australia release documentation updated in March 2026. Oracle Fusion 26A documentation is not directly applicable to ServiceNow AWA because AWA is a ServiceNow platform capability.

What Is ServiceNow AWA?

Advanced Work Assignment is a framework for automatically distributing work items to qualified agents.

At a high level, the process looks like this:

Customer request → Work item → Service channel → Queue → Routing rules → Assignment rule → Eligible agent → Agent inbox

ServiceNow documentation describes AWA as routing work items to queues and then assigning them to agents based on availability, capacity, and optionally skills.

Consider a customer-service implementation where customers submit cases for:

• Billing issues

• Product support

• Technical problems

• Account requests

• Priority escalations

Rather than allowing all cases to remain in one general queue, an implementation team can create specialized queues and routing conditions.

For example:

Once a work item reaches the appropriate queue, AWA evaluates the agents who are eligible to receive it.

Core Components of ServiceNow AWA

Understanding the components is important before beginning configuration.

Service Channels

A service channel represents the type of work being routed.

Depending on the applications installed and configured, service channels can support different types of work such as:

• Chats

• Cases

• Incidents

• Walk-up interactions

• Other supported work items

ServiceNow also allows channel-level settings such as agent capacity and utilization conditions.

For example, a chat agent may be allowed to handle three concurrent conversations, while a case-management agent may have a different capacity model.

Work Items

A work item is the actual piece of work being handled.

Examples include:

• A customer chat

• A service case

• An incident

• A case task

AWA operates on these work items and determines how they should move through the routing process.

Work Item Queues

Queues provide an intermediate routing layer.

A queue can represent a business function, priority, customer segment, or support capability.

For example:

Technical Support Queue
        |
        +-- Product A cases
        +-- Product B cases
        +-- API issues

The queue is important because assignment logic is generally applied after the work item has been routed into an appropriate queue.

Assignment Rules

Assignment rules determine how AWA selects an eligible agent.

ServiceNow currently documents strategies including Most Capacity and Last Assigned.

Most Capacity attempts to route the work to an agent with the greatest available capacity.

Last Assigned considers which eligible agent has gone the longest without receiving a new assignment.

The correct strategy depends on the operational requirement.

Agent Availability and Presence

An agent may belong to the correct assignment group but still be unavailable.

For example:

• Agent is offline

• Agent is unavailable

• Agent has reached capacity

• Agent is already handling multiple work items

AWA considers agent availability and capacity when determining the eligible pool.

Skills

Skill-based routing becomes useful when simply belonging to an assignment group is not enough.

For example, a technical support team may contain:

• 10 general support agents

• 3 Oracle specialists

• 2 database specialists

• 1 networking specialist

If a case requires database expertise, skill-based assignment can help narrow the eligible pool.

ServiceNow supports skill consideration during assignment and can be configured to evaluate skill levels or require specific skills.

Real-World ServiceNow AWA Use Cases

Use Case 1 – Customer Service Case Routing

A global organization receives thousands of customer cases every day.

Cases are categorized as:

• Billing

• Technical

• Account

• Product

• Warranty

The implementation team creates separate AWA queues and routing conditions.

For example:

Case Category = Technical
        ↓
Technical Queue
        ↓
Technical Assignment Rule
        ↓
Eligible Technical Agents
        ↓
Agent with available capacity

This eliminates the need for a dispatcher to manually distribute cases.

Use Case 2 – Skill-Based Technical Support

A software company supports multiple products.

A case may require:

• Product A expertise

• Product B expertise

• API knowledge

• Database knowledge

The organization maintains appropriate agent skills.

When a work item requires a specific capability, AWA can consider skills in addition to availability and capacity.

This is particularly useful when an assignment group contains agents with very different technical specialties.

Use Case 3 – High-Volume Contact Center

A contact center handles several concurrent customer interactions.

Agents have different channel capacities.

For example:

With a Most Capacity strategy, the available capacity becomes an important input into assignment.

The objective is not simply to distribute records equally; it is to use the configured routing logic to distribute active work according to the organization’s operational model.

ServiceNow AWA Architecture and Technical Flow

A practical architecture can be represented as:

Customer / User
      |
      v
Service Channel
      |
      v
Work Item Created
      |
      v
Routing Conditions
      |
      v
Work Item Queue
      |
      v
Queue Priority / Routing Logic
      |
      v
Eligible Agent Pool
      |
      +---- Availability
      +---- Capacity
      +---- Skills
      +---- Presence
      |
      v
Assignment Rule
      |
      v
Selected Agent
      |
      v
Agent Inbox

ServiceNow’s AWA process checks queue priorities, identifies an eligible assignment pool, evaluates available agents, and pushes the work item to the selected agent.

One important implementation point is that routing and assignment are different activities.

Routing answers:

“Which queue should handle this work?”

Assignment answers:

“Which eligible agent should receive it?”

Keeping these two decisions separate makes AWA implementations easier to troubleshoot.

Prerequisites for ServiceNow AWA

Before configuration begins, confirm the following.

1. AWA Capability Is Available

The required AWA functionality and relevant application/plugin dependencies must be installed and updated appropriately.

ServiceNow’s current configuration documentation indicates that administrators should first ensure the Omni-Experience Standard Feature Set is updated appropriately and then install the required AWA capability.

Plugin installation normally requires appropriate administrative privileges.

2. Assignment Groups Exist

Create the assignment groups that will own the work.

Example:

L1 Support
L2 Technical Support
Billing Support
VIP Support
Major Incident Support

3. Users Belong to the Correct Groups

An agent cannot be expected to receive work from a queue if the underlying group and access configuration are incorrect.

Validate:

• User is active

• User belongs to required group

• User has required roles

• User can access the underlying work item

• User is configured for the applicable channel

4. Agent Capacity Is Defined

Determine how much work an agent can handle simultaneously.

Do not copy production capacity values into development simply because they look reasonable.

Capacity should be based on operational analysis.

5. Skills Are Defined Where Required

If skill-based assignment is part of the requirement, identify:

• Skill names

• Skill levels

• Which agents have each skill

• Whether a skill is mandatory

• Whether skill evaluation should influence assignment

Step-by-Step ServiceNow AWA Configuration

The exact menus can vary by release and installed applications, but the following is a practical implementation sequence based on the current ServiceNow AWA documentation.

Step 1 – Open Advanced Work Assignment

Navigate to:

All → Advanced Work Assignment → Home

ServiceNow’s AWA application provides configuration areas for channels, queues, assignment rules, work items, and related settings.

Before configuration, document the business routing matrix.

For example:

This simple matrix prevents configuration from becoming a collection of disconnected rules.

Step 2 – Configure the Service Channel

Navigate to:

Advanced Work Assignment → Service Channels

Select New.

Provide values appropriate for your business process.

Example:

Name: Customer Case
Application: Customer Service
Inbox Order: 10

The service channel establishes the type of work that AWA should handle.

For case-task scenarios, ServiceNow’s current documentation similarly instructs administrators to create the service channel and associate the appropriate application before defining queue and assignment logic.

Step 3 – Create the Work Item Queue

Navigate to:

Advanced Work Assignment → Work Item Queues

Create a queue.

Example:

Name: Technical Support Queue
Short Description: Routes technical customer cases
Assignment Group: Technical Support

The queue should represent a meaningful operational unit.

Avoid creating a separate queue for every minor category.

For example, creating 50 queues for 50 products may make administration unnecessarily complex if the same group and routing strategy handle all products.

Step 4 – Define Routing Conditions

Define conditions that determine which work items enter the queue.

Example:

Category = Technical
AND
Active = true

For a priority queue:

Priority = 1
AND
Active = true

For a VIP queue:

Customer Tier = VIP

Test these conditions independently before testing agent assignment.

This is a common implementation mistake: consultants sometimes troubleshoot agent assignment when the actual problem is that the work item never entered the expected queue.

Step 5 – Configure Queue Priority

When several queues could potentially process work, queue priority becomes important.

A practical example:

Priority 1 → Critical Support
Priority 2 → VIP Support
Priority 3 → Technical Support
Priority 4 → General Support

The exact design depends on the organization’s SLA and operating model.

Do not automatically make every urgent category the highest priority.

Document why a queue has its assigned priority.

Step 6 – Create the Assignment Rule

Navigate to:

Advanced Work Assignment → Assignment Rules

Select New.

Example:

Name: Technical Support Capacity Rule
Assignment Type: Most Capacity
Allow Agent Rejection: Yes

ServiceNow documents both Most Capacity and Last Assigned strategies.

Select the strategy according to the business requirement.

Most Capacity

Use this when the objective is to consider available agent capacity.

Example:

Agent A → 1 available slot
Agent B → 3 available slots
Agent C → 2 available slots

The assignment logic can favor the agent with greater available capacity.

Last Assigned

This approach considers the time since agents last received an assignment.

It can be useful when the organization wants a more rotational distribution model among eligible agents.

Step 7 – Configure Agent Acceptance

Depending on the channel and business requirement, configure whether agents can:

• Accept work

• Reject work

• Automatically accept certain interactions

• Receive a timeout for acceptance

ServiceNow documents configurable rejection and acceptance behavior as part of AWA assignment configuration.

Do not configure aggressive timeout values without testing them.

For example, if an agent has only a few seconds to respond to an assignment, a legitimate assignment may repeatedly time out and circulate through the system.

Step 8 – Configure Skills

If the implementation requires skill-based routing, enable skill consideration for the applicable assignment process.

Example:

Work Item:
Product = Database Platform

Required Skill:
Database Support

Minimum Skill Level:
Intermediate

Then validate that the intended agents actually have the skill and required level.

A technically correct AWA rule can still appear broken if the skill data is incomplete.

Step 9 – Configure Agent Inbox Behavior

AWA pushes work into the agent experience.

Review:

• Inbox layout

• Work item information displayed

• Presence states

• Channel-specific behavior

• Capacity visibility

The objective is to ensure that the agent receives enough information to understand the work without creating unnecessary navigation steps.

Testing ServiceNow AWA

Never validate an AWA implementation with only one test case.

Use controlled test scenarios.

Test Case 1 – Basic Routing

Create:

Category: Technical
Priority: 3
Assignment Group: Technical Support

Expected result:

1. Work item is created.

2. Routing conditions evaluate successfully.

3. Work item enters Technical Support Queue.

4. Eligible agent is identified.

5. Work item is pushed to the agent.

Test Case 2 – Capacity-Based Assignment

Create two available agents.

Example:

Agent A: 1 active work item
Agent B: 3 active work items

Create another work item.

Validate whether the configured capacity-based strategy produces the expected assignment according to the configured channel capacities.

Test Case 3 – Skill-Based Routing

Configure:

Required Skill: API Support

Ensure only selected agents possess that skill.

Create the relevant work item.

Expected result:

The work item should not simply go to any member of the assignment group if the configured skill requirement restricts eligibility.

Test Case 4 – Agent Unavailability

Set the intended agent to an unavailable presence state.

Create another work item.

Expected result:

AWA should evaluate the remaining eligible agents according to the configured routing and assignment logic.

Test Case 5 – Rejected Work

If rejection is enabled:

1. Assign work.

2. Reject it from the agent inbox.

3. Observe the resulting work-item state.

4. Verify that the item becomes eligible for further assignment according to configuration.

ServiceNow documentation notes that AWA can review timed-out or rejected items during the assignment process.

Monitoring Work Items and AWA Events

One of the most useful troubleshooting techniques is to inspect the actual AWA work item rather than relying only on the agent’s inbox.

Navigate to:

Advanced Work Assignment → Work Item → All

ServiceNow provides work-item information such as:

• Queue

• Assigned to

• State

• Active status

• Queue wait-time indicators

• Cancellation information

These records can help determine where routing stopped.

For example:

Work Item Created
        ↓
Queue = Technical Support
        ↓
Assigned To = Empty

This tells the consultant something very different from:

Queue = Empty
Assigned To = Empty

The first case suggests the routing stage worked but assignment did not.

The second case suggests the problem may be earlier in the routing process.

Common ServiceNow AWA Errors and Troubleshooting

Problem 1 – Work Item Never Reaches the Queue

Check:

• Service channel

• Routing conditions

• Work item eligibility

• Application configuration

• Required fields

• Assignment group

Do not start by changing assignment rules.

Problem 2 – Queue Is Correct but No Agent Receives Work

Check:

• Agent presence

• Agent capacity

• Assignment group membership

• Required roles

• Skill requirements

• Assignment rule

• Channel capacity

This is one of the most common implementation troubleshooting paths.

Problem 3 – Skill-Based Routing Does Not Work

Check whether:

• The skill exists

• The agent has the skill

• The skill level is correct

• The work item contains the expected skill requirement

• Skill evaluation is enabled

• The skill is configured as mandatory where required

Skill routing depends heavily on accurate master data.

Problem 4 – Work Items Remain Pending

Review:

• Agent availability

• Queue priority

• Assignment rule

• Capacity

• Timeout configuration

• Presence state

• Routing conditions

Avoid immediately increasing capacity to make pending items disappear. First identify why agents are considered ineligible.

Problem 5 – AWA Does Not Pick Up an Older Work Item

ServiceNow documents an AWA routing look-back property that controls how far back AWA considers eligible work items. The documented default behavior is based on a 10-minute look-back, with the com.glide.awa.routinglookback property available for extending the period when required.

If this behavior matters to the implementation, evaluate the property carefully because it affects routing behavior across service channels.

Practical Consultant Best Practices

Keep Routing and Assignment Logic Separate

Think in two questions:

Routing:

Where should this work go?

Assignment:

Who should handle it?

This makes troubleshooting much easier.

Start With the Simplest Working Rule

Do not immediately build a complicated combination of:

• 20 queues

• 30 routing conditions

• 15 skills

• Multiple assignment strategies

Start with:

One channel
One queue
One assignment group
Two agents
One assignment rule

Prove the flow.

Then introduce complexity incrementally.

Build a Routing Matrix Before Configuration

Maintain a spreadsheet or design document showing:

This becomes an excellent reference during SIT and UAT.

Avoid Excessive Skills

Skill-based assignment is powerful, but overengineering the skill model can make routing difficult to maintain.

Create a skill only when it materially changes eligibility or assignment.

Validate Master Data

Many AWA problems are not caused by AWA configuration.

They are caused by:

• Incorrect assignment group membership

• Missing skill

• Incorrect skill level

• Inactive user

• Incorrect presence

• Incorrect capacity

Always validate the agent data before modifying routing logic.

Test Failure Scenarios

A production-ready AWA design should test more than successful assignment.

Test:

• No available agents

• Agent rejection

• Agent timeout

• Agent becomes unavailable

• Required skill unavailable

• Queue backlog

• Multiple eligible agents

• Multiple competing queues

• High-priority work

This is where many implementation issues appear.

AWA Implementation Checklist

Before moving the configuration to production, verify:

• AWA capability is installed and available.

• Required service channels are configured.

• Assignment groups are created.

• Agents are correctly assigned to groups.

• Agent access is validated.

• Capacity is defined.

• Presence states are tested.

• Queues are created.

• Routing conditions are tested.

• Queue priorities are documented.

• Assignment rules are configured.

• Skill-based routing is tested if applicable.

• Rejection behavior is tested.

• Timeout behavior is tested.

• Work-item records can be monitored.

• Failure scenarios are included in SIT/UAT.

• Production support teams understand the routing design.

Frequently Asked Questions

What does AWA mean in ServiceNow?

AWA stands for Advanced Work Assignment. It automatically routes work items through configured service channels and queues and assigns them to eligible agents using criteria such as availability, capacity, assignment strategy, and optionally skills.

What is the difference between an AWA queue and an assignment group?

An assignment group represents the group of users responsible for a type of work. An AWA queue is part of the routing mechanism that organizes eligible work and applies routing and assignment logic. AWA can then use the configured assignment strategy to select an individual agent.

Can ServiceNow AWA assign work based on skills?

Yes. AWA supports skill-based assignment. Skills can be considered during assignment, and the configuration can support skill evaluation and mandatory skill requirements depending on the implementation.

Summary

ServiceNow AWA is best understood as a work-routing and workload-distribution framework, rather than simply an automated assignment rule.

A successful implementation normally follows this sequence:

Define Business Requirement
        ↓
Define Service Channel
        ↓
Create Routing Conditions
        ↓
Create Work Item Queue
        ↓
Configure Assignment Group
        ↓
Configure Assignment Rule
        ↓
Configure Capacity / Presence
        ↓
Configure Skills if Required
        ↓
Test Work Item
        ↓
Monitor AWA Work Item
        ↓
Validate Agent Assignment

The most important implementation lesson is to design the routing model before configuring the platform. Start by understanding the work types, queues, assignment groups, agent capacities, skills, and operational priorities. Then translate that design into AWA configuration.

For additional technical details, use the official ServiceNow Advanced Work Assignment documentation and the ServiceNow AWA configuration documentation. For Oracle Fusion topics covered elsewhere in your project, refer to the Oracle Cloud SaaS documentation and always use the documentation corresponding to the specific Fusion application release. Because this article is about ServiceNow AWA, Oracle Time and Labor documentation is not directly applicable to the configuration described here.