Field Service Management Fundamentals

This is the heaviest domain. It covers the core data model, the work order lifecycle, the building blocks of assignment, and the workspaces that field service runs in. If you understand work orders, work order tasks, templates, qualification, and dispatching cold, you have most of the exam.

The core data model: work orders and work order tasks

A work order is the central record describing a complete field service request or job. The work order outlines the entire request; the detailed steps that fulfill it live in one or more work order tasks. A work order is always made up of at least one work order task: the order is the parent, the tasks are the children that field agents actually execute.

• Work order table: wm_order (Zurich docs: Work Order [wm_order])
• Work order task table: wm_task (Zurich docs: Work Order Task [wm_task])

Both records carry a State field and move through a defined lifecycle. Work order states and work order task states are sequential: a task progresses from one state to the next in order. Out-of-box work order states (Zurich) are Draft, Awaiting Qualification and Qualified (shown only when qualification is enabled) or Ready for Dispatch (when it is disabled), Assigned, Accepted, Work in Progress, Closed Complete, Closed Incomplete, and Canceled. Work order task states are Draft, Pending Dispatch, Scheduled (only when the Scheduled state is enabled), Assigned, Accepted, Work in Progress, Closed Complete, Closed Incomplete, and Cancelled. A task can be closed as complete or as incomplete; an incomplete close is used when the work could not be finished.

State behavior is fully configurable through state flows, a framework that lets you define which states exist, which transitions are allowed, what field controls (mandatory fields, read-only) apply in each state, whether work notes are required, and what trigger events fire on a state change. Work orders and work order tasks share this configurable state-flow framework, but each is configured independently.

Work order models and work order templates

When the same kind of job recurs, you do not rebuild it by hand each time. You use work order templates (also called work order models) to create comprehensive, repeatable work orders that bundle in skills, parts, and scheduling, and that break the order down into its composite tasks describing exactly what must be done.

Key rule to memorize: a task template cannot exist on its own: it is always created as part of a work order template. The order template owns the task templates.

• Work order (product) model / template table: cmdb_workorder_product_model, which includes a qualification_group field
• Work order task model / template table: cmdb_worktask_product_model

Because the model carries the qualification group, skills, and part requirements, applying a template auto-populates those requirements onto the generated work order and its tasks. This is the mechanism that drives consistent, dispatch-ready work.

Qualification: making a work order dispatchable

Qualifying a work order is the gating step that confirms its tasks contain enough information for the groups dispatched to work on them. When Qualification is required for new requests is enabled, qualification is manual: a qualifier (wm_qualifier) selects the dispatch group, adds work order tasks, and defines part requirements (and can edit the affected CI, short description, and description), then the order moves from Awaiting Qualification to Qualified. When the option is disabled, qualification is automatic. Qualification does not select agents: matching agents by skills, location, and availability happens later, at assignment.

There is a configurable qualification state for work orders. You can also create tasks without first qualifying the parent order (a Draft-state path), but qualification is the normal route to a clean dispatch.

Skills and groups: who can do the work

Assignment in FSM rests on skills and groups:

• Skills describe agent competencies. Agents are assigned skills; tasks require skills. In current releases skills are stored on a Task Skill many-to-many table (skills were migrated to this table). Field Service and Customer Service managers can create or edit skills, assign skills to agents, and find agents with a given skill.
• Agent (work) groups use group type wm_work.
• Dispatch groups use group type wm_dispatch.
• A dependency relationship links dispatch groups to the agent groups they cover, stored in sm_m2m_group_dependency (the "assignment group covered" relationship).

Watch item: the prompt term "qualification groups" is not a clearly distinct official object. FSM works with skills, assignment/dispatch groups (wm_work / wm_dispatch), the qualification group field on the work order model, and work order qualification states. Treat "qualification group" as the field on the work order model, not as a separate top-level module.

Dispatching: Dispatcher Workspace

The Dispatcher Workspace is the dedicated, configurable workspace where dispatchers assign work order tasks to field agents using a drag-and-drop interface. It is built on the CSM/FSM Configurable Workspace.

Its main components:

• Dispatcher Dashboard: the workspace homepage, showing real-time operational data: counts of pending dispatch items, agent location status, and performance statistics.
• Dispatch map: shows agents and tasks geographically; supports auto-zoom to a specific technician or task and route preview.
• Calendar grid: shows each agent's ServiceNow calendar so the dispatcher can see existing tasks and appointments. Dispatchers can create tasks directly from the grid (Drag End, Grid Click, Grid Double-Click). Schedules display in each agent's local timezone, so "8 AM local" lines up vertically across agents. Calendar Sync integrates external calendars (Google, Microsoft).
• Assignment assistance: surfaces a ranked list of agents for a task based on criteria such as skills, distance, and best match, letting the dispatcher assign with one click.

The layout is personalized per dispatcher (custom filters, advanced search/sort, configurable task and agent cards).

Watch item: "central dispatch" is not a verified current-release official feature name. The official concept lives in Dispatcher Workspace / the Dispatcher Dashboard and the dispatch queue (pending dispatch). Treat "central dispatch" as a conceptual/legacy phrasing.

Automated scheduling and assignment

FSM offers several layers of automation above manual dispatch:

• Auto assignment: rule-based assignment of tasks to agents.
• Dynamic Scheduling: automatically assigns tasks to agents using predefined rules and intelligent recommendations that weigh technician skills, availability, location, and capacity, reducing manual dispatcher effort.
• Schedule Optimization: uses advanced algorithms considering skills, location proximity, availability, work priority, SLAs, and travel time to make optimal real-time scheduling and routing decisions, so mobile workers spend more time working and less time driving.

Auto assignment and Dynamic Scheduling are distinct features: auto assignment is rule-based; Dynamic Scheduling is optimization-engine driven.

Territories and geolocation

Field Service Territory Planning (Territory & Capacity Planning) lets you define and manage geographic territories and technician capacity. It uses real-time location data, skills profiles, and capacity rules to route work to the nearest, most-available, qualified technician while balancing workload and reducing travel.

• With Territory Planning enabled, each Work Order Task gains a Territory field, auto-populated from the geocoordinates of the task's Location. Geocoding requires a maps/API key (e.g., Google Maps).
• The territory model holds each territory and its associated resources: dispatch groups, assignment groups, and qualification groups.

Advanced Work Assignment (AWA) and agent scheduling

Advanced Work Assignment (AWA) is a Now Platform capability (not FSM-specific) that automatically routes work items to agents based on availability, capacity, and skills, using service channels, assignment rules, and queues, configured in the AWA Admin Console. It supports skill-based routing.

For field work, FSM primarily relies on Dispatcher Workspace + Dynamic Scheduling + Territory Planning rather than AWA. AWA is most relevant in adjacent agent/CSM contexts.

Watch item: a dedicated official "AWA for FSM" page was not found. AWA is documented at the platform level; FSM's documented field-assignment mechanisms are Dynamic Scheduling, Territory Planning, and Dispatcher Workspace assignment assistance. (UNVERIFIED: official support for AWA service channels routing wm_task.)

---