ServiceNow Work Order Task Assignment: States, the wm_task Table, and Work Order Management Routing
A work order task is where field service stops being a plan and becomes somebody driving to a site. Getting the right technician onto that task runs through four layers, territory, dispatch group, assignment group, and agent, and the layer that stops most rollouts is not the one teams expect. The assignment group picker comes up empty, the fix is not a permission, and the workaround people reach for next quietly widens dispatch instead of narrowing it. Here is the routing chain as it actually behaves.
In short
A ServiceNow work order task, stored on the wm_task table, is the unit of field work a technician performs, and it reaches that technician through a chain most teams only map out after it breaks: territory, then dispatch group, then assignment group, then the individual agent. The constraint that stops nearly every first rollout is that the Assignment group field on a work order task does not list ordinary ITIL groups. A ServiceNow employee stated it plainly in the community: only groups which are created of type work groups (wm_work) will be shown in assignment group. A group typed itil returns no group matches the configured criteria no matter how many members it holds. The second surprise is quieter and more expensive. Selection is filtered to groups that cover the location of the task, and when no dispatch group covers that location the platform falls back to listing every dispatch group rather than raising an error, so routing looks healthy while work leaks to teams hundreds of miles away. Assigner runs round robin, weighted rotation, load-balanced, skill-based, and availability rules as one engine beside the ServiceNow you already run, at $12/user/mo billed yearly ($15/mo billed monthly), and names the rule behind every assignment. The AI assists your triage, the rules stay yours.
Why it fits
Field service operations leads, dispatchers, and FSM administrators running work order management in ServiceNow who need work order tasks to reach a qualified technician without a human triaging every one, and who want rotation, workload, and skill matching applied to the agents inside a dispatch group rather than leaving it to whoever the dispatcher happens to recognize.
The picker filters on wm_work, not itil
Every group that works fine on Incident is typed itil, so the first instinct when the work order task Assignment group field is empty is to check roles or ACLs. Neither is the cause. Field Service Management filters that reference field to groups of type work groups, table value wm_work, and the group also has to sit under a dispatch group. Adding the type takes seconds once you know it. Finding it costs teams days.
Territory gating fails open, not closed
By default a dispatcher can only pick groups belonging to the location of the task, which is the behavior you want. What is not obvious is the fallback: if no dispatch group covers that location, the platform lists all dispatch groups instead. Nothing errors, nothing logs a warning, and the task is assignable to a team on the other side of the country. Coverage gaps do not announce themselves, they just widen the pool.
Auto Assign works in your PDI because of demo data
The Auto Assign action behaves perfectly on a personal developer instance and does nothing on a fresh production instance. A ServiceNow MVP put the reason directly in the community thread: the provided demo data already has all the required configurations. Territories, dispatch groups, skills, and agent schedules all have to exist before automated assignment has anything to decide with.
Side by side
How a work order task reaches a technician, and what breaks each route
| Mechanism | Where it is configured | What it sets | Common failure | Best for |
|---|---|---|---|---|
| Manual assignment | Dispatch Queue, Task Map, or Dispatcher Workspace | Assignment group and Assigned to on the task | Depends entirely on one dispatcher knowing who is free | Low volume, high judgment work |
| Auto Assign action | Dispatcher Workspace | Assignment group and agent from dispatch group, location, and skills | Silently does nothing until territories, skills, and schedules exist | Straightforward tasks in well modeled territories |
| Dynamic Scheduling task filters | Dynamic Scheduling configuration | Optimized agent and time slot across the whole queue | A separate capability to license and model, not a checkbox | High volume dispatch with SLA and travel constraints |
| Territory Planning | Territory and dispatch group records | Which dispatch groups and agents are eligible at all | No coverage for a location falls back to every dispatch group | Geographically distributed field teams |
| Assignment group reference qualifier | Dictionary and dictionary overrides on wm_task | Which groups are selectable in the picker | An override you did not write replaces the qualifier you expect | Restricting choice without custom code |
| Rules engine beside the platform | Assigner, reading and writing the task | The individual agent, by rotation, load, skill, or availability | Needs an integration user and clear ownership of the write | Fair rotation and workload balance inside a group |
The first four are ServiceNow capabilities and are described here as documented and as reported by practitioners in the ServiceNow Community. Availability and packaging of Field Service Management and Dynamic Scheduling depend on your subscription, and ServiceNow repackaged its tiers in April 2026, so confirm entitlements with your account team rather than with any tier name published before that change.
In detail
ServiceNow work order task assignment, in practice
What is a work order task in ServiceNow?
A work order in ServiceNow Field Service Management describes a job at a customer or a site. A work order task is one piece of that job, and it is the record a technician is actually assigned to and works from. The parent work order holds the commercial and customer context; the child tasks hold the labor. That split is why the assignment conversation always lands on the task and not the work order: the work order says a chiller needs servicing at a site, and the task says who is driving there, when, and with which skills.
Work order tasks live on the wm_task table. That matters more than a table name usually does, because wm_task is tightly coupled to the work order table and carries the out-of-box behavior the rest of FSM depends on. When teams need extra fields, the reflex is to extend wm_task into a custom table. Practitioner guidance in the ServiceNow Community is consistently against it. The advice from a long-standing community contributor is to create custom fields on the out-of-box table instead, because a separate task table means configuring Work Type mappings before auto-creation and auto-dispatch will touch your records at all. You can spend a week building a table and then discover the automation you bought the module for does not reach it.
Why the assignment group field on a work order task is empty
This is the single most common wall in an FSM rollout, and it looks like a permissions bug. The Assigned to field lists every user normally. The Assignment group field, on the same form, returns nothing. Groups exist. Members exist. Roles look right.
The cause is group type. A ServiceNow employee answered it in the community in one sentence: only groups which are created of type work groups (wm_work) will be shown in assignment group. Your existing groups are typed itil because that is what Incident and Request need, and FSM filters on a different type entirely. The same thread carries the reporter confirming their own resolution afterwards, which adds the second half of the fix: the group needed the specific group type and had to be made an assignment group covered under a dispatch group.
A second thread shows the same wall from the other side. There the reference qualifier on the field was filtering on type itil, and the form returned no group matches the configured criteria. The advice given was to check dictionary overrides before assuming the qualifier you are reading is the one running. Because wm_task extends task, an override on the assignment_group field can be replacing the qualifier defined further up, and the dictionary entry you opened is not the one deciding anything. Check the override first. It is a thirty second check that saves you from adding a group type to two hundred records for no reason.
Territory, dispatch group, assignment group: the order the fields have to be filled
FSM does not treat the assignment group as a free choice. It narrows the list to what makes operational sense for the location of the work, and the documented behavior is that you can only select groups that belong to the location of the task. The field is described as showing recommended assignment groups based on the location, the asset, and the skills required for the task, which is genuinely useful when the underlying data is complete.
When Territory Planning is enabled the order becomes mandatory: the dispatcher selects a Territory and a Dispatch group first, and only then an Assignment group. Teams that enable Territory Planning midway through a rollout often report that assignment suddenly takes more clicks and blame the upgrade. It is not a regression, it is the gating working.
The part worth putting in your runbook is the fallback. If no dispatch group covers the location on the task, the system does not stop and it does not warn. All dispatch groups become available for assignment. A gap in territory coverage therefore presents as a wider list rather than an empty one, which is the opposite of the signal a dispatcher needs. A task for a site nobody covers looks exactly like a task anyone can take. The report worth building on day one is simple: work order tasks whose location maps to no dispatch group. Run it weekly, because every new customer site is a chance to reopen the gap.
The nine work order task states, and the one routing depends on
Work order task states are sequential and several of them move on their own once configuration is in place. The documented progression is:
| State | What it means |
|---|---|
| Draft | The qualifier is not done describing the work and the dispatch group is empty |
| Pending Dispatch | The qualifier has added the dispatch group and marked the task Qualified |
| Scheduled | The task is soft booked but not confirmed. This state only appears if it is enabled |
| Assigned | The dispatcher confirmed the assignment and the task waits for the agent to accept |
| Accepted | The field service agent accepted the task and is ready to work on it |
| Work in Progress | The agent started work and selected Start work |
| Closed Complete | The task was completed to specification |
| Closed Incomplete | The task could not be completed as specified |
| Cancelled | The task was terminated |
Read the first two rows together and the routing model gives itself away. The dispatch group is what moves a task out of Draft. Draft is defined by the dispatch group being empty; Pending Dispatch is defined by the qualifier having supplied it. So a pile of work order tasks stuck in Draft is almost never a workflow problem and almost always a qualification problem, and the fix is upstream of anything you would configure on assignment.
Two more details save time later. If the Quality Management plugin is active, a Pending review substate can sit before final completion, so a task that reads as finished to the technician is not finished to the business until a reviewer approves or asks for more information. And custom state values are a known source of tasks that never appear in Dispatcher Workspace, because the workspace views are built around the states that shipped. Add a state, check the workspace.
Auto Assign, and why it works in your PDI and not in production
A dispatcher sees an Auto Assign action in Dispatcher Workspace on a personal developer instance, it fills in the assignment group and the agent instantly, and the obvious conclusion is that automated assignment is a switch. It is not. When this exact question was raised in the community, a ServiceNow MVP answered that the behavior appears on a PDI because the provided demo data already has all the required configurations, and that production needs that groundwork built first.
The groundwork is the real project. Automatic matching evaluates an agent by dispatch group, assignment group, location, and skills, with distance handled through a distance from task with radius exclusion filter. Every one of those inputs is data somebody has to maintain: territories drawn, dispatch groups populated, skills defined and attached to both tasks and agents, and agent schedules kept current. Auto Assign is a decision layer over that data, and with the data missing it has nothing to decide and correctly does nothing.
The same MVP pointed past Auto Assign toward Dynamic Scheduling as the better approach in an FSM context, describing it as more complex but essential. That is a fair summary of the tradeoff. Auto Assign answers who should take this task now. Dynamic Scheduling optimizes across the whole queue, filters by territory first and then by skills, location, and distance, lets you require an agent to match all skills, some, or none, and can run each task filter immediately, on an interval, or manually. It also reschedules lower priority work to make room for higher priority work, which is the behavior no rules engine gives you for free.
Be clear-eyed about what that means commercially. Dynamic Scheduling is a distinct capability with its own modeling effort and its own entitlement question. If the problem you actually have is that six technicians in one group get work unevenly, optimization across the entire queue is a large answer to a small question.
Where a beside-the-platform rules engine fits
Nothing here argues against FSM. Territory, dispatch group, and skill matching are the right way to decide which team owns a job, and no external tool should try to replace that. The gap opens one level down, inside the group, where the platform hands a dispatcher a list of eligible agents and the choice becomes human. That is where the same three names get picked, where the technician who is easiest to reach absorbs the overflow, and where nobody can answer why a specific task went to a specific person three weeks later.
Assigner sits beside ServiceNow and answers exactly that question. It reads the task, applies round robin, weighted rotation, load balancing, skill matching, or live availability, writes the assignment back, and records the rule that produced it. Rotation stays fair when somebody is on leave, capacity is respected instead of assumed, and the audit trail is a sentence rather than an archaeology project. It does not decide territory and it does not replace Dynamic Scheduling for route optimization. It decides the person, consistently, in the space FSM deliberately leaves to a human.
Pricing is $12/user/mo billed yearly, or $15/mo billed monthly.
A checklist before you turn any of it on
Run these in order. Each one is cheap and each one has stopped a rollout somewhere.
- Confirm group type. Every group meant to receive field work carries the work groups type, wm_work, and sits under a dispatch group. Your itil groups will not appear.
- Read the dictionary override on assignment_group for wm_task before editing the qualifier you found on the parent table.
- Map territory coverage and list the locations no dispatch group covers, because those tasks silently open to every group.
- Check for custom states and confirm they render in Dispatcher Workspace.
- Leave wm_task unextended. Add fields to the out-of-box table so Work Type mappings, auto-creation, and auto-dispatch keep working.
- Populate the matching inputs before expecting Auto Assign to do anything: skills on tasks and agents, agent schedules, and locations.
- Decide who writes the assignment. One system should own the write on assigned_to, or two automations will take turns overwriting each other.
Questions buyers ask
Frequently asked questions
What is a work order task in ServiceNow?
A work order task is one unit of field work under a parent work order, and it is the record a technician is assigned to and works from. The work order describes the job at the site; the tasks describe the labor. Work order tasks are stored on the wm_task table and carry their own state, assignment group, assigned agent, skills, and schedule.
What is the work order task table in ServiceNow?
The table is wm_task. It is tightly coupled to the work order table and carries the out-of-box FSM features for task management, reporting, and automation. Community guidance is to add custom fields to wm_task rather than extend it, because a separate task table requires Work Type mappings before auto-creation and auto-dispatch will work.
What are the work order task states in ServiceNow?
The documented states are Draft, Pending Dispatch, Scheduled, Assigned, Accepted, Work in Progress, Closed Complete, Closed Incomplete, and Cancelled. Draft means the dispatch group is still empty. Pending Dispatch means the qualifier added the dispatch group and marked the task Qualified. Scheduled only appears when it is enabled.
Why is the assignment group empty on a ServiceNow work order task?
Because Field Service Management filters that field to groups of type work groups, table value wm_work. A ServiceNow employee stated in the community that only groups created of type work groups will be shown in assignment group. Groups typed itil will not appear no matter how many members they hold, and the group also has to sit under a dispatch group.
Why does the work order say no group matches the configured criteria?
That message comes from the reference qualifier on the assignment group field rejecting every candidate. Two causes dominate: the groups carry the wrong type, or a dictionary override on wm_task is replacing the qualifier you are reading. Because wm_task extends task, check the override before editing the qualifier defined on the parent table.
How does ServiceNow decide which agent to recommend for a work order task?
Automatic matching evaluates the dispatch group, assignment group, location, and skills of an agent, and uses a distance from task with radius exclusion filter to weigh travel. Recommended agents are those close to the task location who hold the necessary skills and have availability in their schedule. With Territory Planning enabled, territory filters the pool first.
How do I auto assign work order tasks in ServiceNow?
Auto Assign runs from Dispatcher Workspace, but it only produces a result once the underlying data exists: territories, dispatch groups, skills on both tasks and agents, and agent schedules. It works instantly on a personal developer instance because the demo data ships with that configuration already in place, which is why the same action appears to do nothing on a fresh production instance.
What is Dynamic Scheduling in ServiceNow FSM?
Dynamic Scheduling is the optimization layer above simple auto assignment. It filters by territory first, then by skills, location, and distance, and lets you require an agent to match all skills, some, or none. Each task filter can run immediately, on an interval, or manually, and it can reschedule lower priority work to fit higher priority work in.
Is a work order task the same as a work order?
No. The work order is the parent record for the job at a site and holds the customer and commercial context. The work order task is the child record a technician is assigned to and performs. A single work order can carry several tasks, each with its own state, skills, schedule, and assigned agent, which is why assignment is configured at the task level.
What roles are needed to assign work order tasks in ServiceNow?
Manual assignment of work order tasks is performed by users holding wm_dispatcher, wm_initiator_qualifier_dispatcher, or wm_admin. Those roles cover selecting the assignment group and setting the assigned agent, including assignment to crews where the task has the needs crew option selected.
Why are my work order tasks stuck in Draft?
Draft is defined by the dispatch group being empty. A task leaves Draft for Pending Dispatch when the qualifier supplies the dispatch group and marks the task Qualified. A queue of Draft tasks is therefore a qualification gap rather than a workflow failure, and the fix sits upstream of anything configured on assignment.
Can ServiceNow do round robin for work order tasks?
Not as a native setting on wm_task. FSM decides which team and which qualified agent should take a task using territory, skills, and distance, and leaves fair rotation inside a group to the dispatcher. Assigner adds round robin, weighted rotation, and load balancing inside the group beside ServiceNow, and names the rule behind each assignment.
Keep reading
The ServiceNow group and routing mechanics a field service rollout depends on.
- ServiceNow group types - What the Type field on a group actually gates, which is exactly the wm_work problem above.
- ServiceNow assignment group - How assignment groups are populated, and why a correctly grouped ticket still reaches nobody.
- ServiceNow catalog task assignment - The sc_task equivalent, where the Fulfillment group field routes nothing at all.
- ServiceNow Advanced Work Assignment - Pushing work to a person instead of a queue, and what it costs to turn on.
- ServiceNow round robin assignment - Where rotation exists natively, where it does not, and what the legacy engine cannot do.
- Dispatch assignment - Routing field and dispatch work when the crew, not the queue, is the constraint.
Stop hand-sorting your incoming work
Let Assigner route it to the right available person by skill, workload, and availability, using rules you control. Nothing sits unassigned and no one gets cherry-picked. Every assignment shows why.