CIS-FSM Study Guide — Certified Implementation Specialist: Field Service Management

ServiceNow, Field Service Management, Now Platform, and related product names are trademarks of ServiceNow, Inc. This is an independent, commercial exam-preparation resource and is not affiliated with, endorsed by, or sponsored by ServiceNow, Inc. All content is original prose written for study purposes.

This guide is ordered by exam weight. Spend your time where the points are: Field Service Management Fundamentals (50%) and Implementing Field Service Processes (38%) together account for roughly 88% of the exam. The two smaller domains — Implementation Planning (5%) and Implementing Related Processes (7%) — round out the rest.

Terminology reflects current ServiceNow releases (Xanadu / Yokohama / Zurich era). Where a release renamed a feature, the current name is given with the older name noted.

Domain 1 — Field Service Management Fundamentals (50%)

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 (UNVERIFIED against current-release body text — historically correct internal name)
Work order task table: wm_task (UNVERIFIED against current-release body text)

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 states you should recognize include Draft, Qualification, Pending Dispatch, Scheduled, Work In Progress, Closed Complete, and Closed Incomplete. A task can be closed as complete or as incomplete; an incomplete close is used when the work could not be finished. (The exact full ordered out-of-box state list is UNVERIFIED.)

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 — 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 the order has everything needed before it moves toward dispatch. Qualification checks that the order has the correct assignment group, skills, and priority, any required assessments or approvals, the availability of needed parts, tools, or prerequisites, and that the work falls within an active service window and the customer's entitlements.

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.)

Domain 3 — Implementing Field Service Processes (38%)

This is the second-heaviest domain. It is about operating the field service lifecycle end to end: parts and inventory, assets and install base, time recording, planned maintenance, mobile execution, contextual search, and SLAs.

Parts and inventory management

Required parts for a work order task must be available in a stockroom to be reserved for the task. FSM recognizes:

Personal (agent) stockroom — the truck/van stock an individual technician carries.
Group stockroom — stock shared by a group.

Flow and key behaviors:

A dispatcher can add part requirements to a work order task at any time before assignment.
If a technician lacks a required part, the dispatcher can Source part to find it elsewhere.
Transfer orders move parts between stockrooms and are tracked in alm_transfer_order (a table shared with Asset Management). The system decides whether a transfer order is needed based on the sourcing stockroom — if the part is already in the technician's personal stockroom, no shipment and therefore no transfer order is created.
Stock rules drive inventory replenishment: when stock crosses a threshold, the rule can trigger a transfer from another stockroom or an order from a vendor.
Technicians can request and receive parts, and track parts via the mobile app.

(UNVERIFIED: exact stockroom table sys name — Asset Management convention is alm_stockroom; the Parts Management plugin sys name was not confirmed.)

Asset management and install base

FSM reuses the platform's CMDB / Asset Management model. In the Xanadu release the extended work order task summary pulls together affected products, install base items, assets, and linear assets, giving the technician a complete view of the asset and its history for install, maintenance, and break/fix work.

Install base items are the CSM/FSM construct representing what a customer has installed; they are created and managed via Customer Service Management and referenced by work orders.
Assets tie back to the platform Asset (alm_asset) and CI (cmdb_ci) model.
Agents can record and view asset usage on a work order task.

(UNVERIFIED: exact install base item table sys name — convention is sn_install_base_item. The extended-summary fact comes from an official ServiceNow blog; confirm against the Xanadu FSM release notes.)

Time recording

Configuring Time Recording for Field Service is optional but saves agents from logging time manually. Agents record time worked on tasks and activities; time recorded entries automatically generate time cards and time sheets for manager approval.

There is a dedicated Time Recording for Field Service plugin with its own roles.
Agents can record time manually or have it auto-recorded, and can review time recorded for a task.
Time cards integrate with the platform Time Card Management (time_card) framework feeding time sheets and approvals.
In the mobile app, an agent can add a time card to log work time.

(UNVERIFIED: exact plugin sys ID/scope and the time-recorded-entry table sys name.)

Planned maintenance / planned work

FSM uses Planned Work Management (the FSM-side capability and a Store app) to manage work orders for planned work, and Planned Maintenance (from the Service Management for the Enterprise family) to define maintenance plans and schedules.

A maintenance plan can schedule maintenance by time interval (e.g., every N months) or by meter/usage (e.g., pages printed, miles driven).
Work order templates are associated with maintenance schedules to auto-create the right work orders.
A scheduled job executes the planned-work schedule and auto-generates work orders at regular intervals.
The Lead Time field controls how far in advance work orders are generated, ensuring future-period orders always exist.
You can review maintenance cycle history for any asset or inventory item.

(UNVERIFIED: plugin sys names and maintenance plan/schedule table sys names. Many Planned Maintenance docs sit under the Service Management for the Enterprise bundle; concepts are stable across releases.)

Mobile execution

Two distinct persona apps — do not confuse them:

Now Mobile — the employee/requester app (submit and track requests, find people/info, Virtual Agent). Not the technician app.
ServiceNow Agent (the fulfiller/agent mobile app, formerly Mobile Agent / Field Service Mobile) — the app field technicians use to complete work order tasks.

Naming caveat: ServiceNow's docs have used several names for the same technician app across releases (Field Service Mobile → ServiceNow Mobile Agent → Now Mobile Agent → ServiceNow Agent). The currently marketed installable app is ServiceNow Agent.

Capabilities:

Field agents can execute work order tasks, manage assets, and close work order tasks in online or offline mode.
Scheduled offline caching lets admins pre-cache data so technicians can work offline; data syncs back on reconnect.
A configurable "recently closed work order tasks" list is available.

(UNVERIFIED: exact default offline-cached record set and sync behavior; offline availability of attached knowledge articles.)

Contextual search

FSM uses the platform Contextual Search on work order and work order task forms. Configure fields on forms (and record producers) to automatically display knowledge search results based on text entered, so agents are better prepared for the work.

The mechanism: a Search Context ties a table/field to Resource Configurations (Search Resources) and can surface knowledge articles and catalog items.
A dedicated task lets you add a knowledge article to a work order or work order task (applies to both record types).

(UNVERIFIED: exact trigger field on wm_order/wm_task; whether catalog vs knowledge-only is enabled out-of-box for FSM.)

SLAs in field service

SLAs determine when work on a work order or work order task must be complete — for example, a contractual obligation to finish break/fix work within a set time.

SLAs apply to both wm_order and wm_task.
Suspend/resume SLA is a first-class FSM feature, documented separately for work orders and work order tasks (useful when work is paused waiting on parts or the customer).
Other documented operations: manage a work order SLA, view a task with an SLA, delete an SLA, view task SLAs on the Contractor Portal.
Mechanism: FSM SLAs are built on the platform Service Level Management engine as standard Task SLAs (task_sla) driven by SLA Definitions (contract_sla) targeting the FSM tables.

(UNVERIFIED: whether FSM ships predefined out-of-box SLA definitions; service contracts/entitlements as named FSM SLA entities — "Contracts and Entitlements" are CSM constructs; task_sla/contract_sla names inferred from standard SLM architecture.)

Customer Service (CSM) integration

FSM integrates with Customer Service Management so that field work can originate from customer cases:

Customer service agents can create work orders from cases ("Create a work order for a customer service case").
Field technicians see customer account and contact info on the work order and its tasks.
Customers can view case-related work orders from the Customer/Consumer Service Portals.
Configuration includes mapping case fields to the work order table and customizing the work order state transition map.

(UNVERIFIED: exact integration plugin ID — search suggested com.snc.csm_fsm_integration, not primary-source confirmed; CSM case table is sn_customerservice_case.)

Domain 4 — Implementing Related Processes (7%)

A smaller domain covering the activation and surrounding capabilities that field service depends on.

Plugins and activation

The base plugin is Field Service Management, plugin name field_service_management, available as a separate subscription. Activating it auto-activates its dependent plugins.
After the base is active you can activate additional plugins for demo data and extra features, including: Dispatcher Workspace, Schedule Optimization, Dynamic Scheduling, Planned Work Management, Contractor Management, Field Service Marketplace, Capacity and Reservations Management, Crew Operations, Territory Planning, Workforce Optimization for Field Service, Template Management, Time Recording, Smart Assessment / Questionnaire, Playbooks, Linear Assets, and Access Hours.

Correction to a common error: the plugin is field_service_management, not com.snc.work_management (outdated/unverified).

Related capabilities to be aware of

Contractor Management — extends field work to external contractors (contractor portal, transfer of part orders to contractors).
Crew Operations — managing crews rather than individual agents.
Capacity and Reservations Management — reserving agent capacity ahead of scheduling.
Workforce Optimization for Field Service — territory and resource optimization layered on top of the base.

Domain 2 — Implementation Planning (5%)

The smallest domain. It is about the discipline around an implementation rather than the product features:

Understanding the Now Create methodology and standard implementation phases.
Gathering requirements for work order types, state flows, skills, territories, and integrations before build.
Planning data: stockrooms, assets/install base, skills-to-agent mapping, group structures.
Sequencing plugin activation (base FSM first, then feature plugins) and managing dependencies.
Planning the CSM integration, mobile rollout, and SLA definitions as part of scoping.

Watch item: official Now Create artifacts and the exact CIS-FSM implementation methodology content were not fully extractable from primary sources; treat methodology specifics as supplementary and confirm via Now Create.

Fast-recall cheat list

Work order = parent; work order task = child. A work order has at least one task. Tables: wm_order / wm_task (UNVERIFIED current name).
States are sequential and governed by state flows (configurable transitions, field controls, work-note rules, trigger events). Configure work orders and tasks independently.
Closed Complete vs Closed Incomplete — incomplete close = work not finished.
Work order template (model) bundles skills + parts + scheduling and owns task templates (a task template can't exist alone). Tables: cmdb_workorder_product_model (has qualification_group) and cmdb_worktask_product_model.
Qualification = gate confirming group, skills, priority, approvals, parts/tools, service window, entitlements before dispatch. Configurable qualification state.
Skills stored on the Task Skill (m2m) table; agents have skills, tasks need skills.
Agent group = wm_work; dispatch group = wm_dispatch; dependency in sm_m2m_group_dependency.
Dispatcher Workspace: drag-and-drop; Dispatcher Dashboard (pending dispatch, agent status), dispatch map, calendar grid (local timezone, Calendar Sync), assignment assistance (ranked by skills/distance/best match).
"Central dispatch" is not a verified official feature name — think Dispatcher Workspace + dispatch queue.
Auto assignment (rule-based) ≠ Dynamic Scheduling (optimization engine: skills, availability, location, capacity). Schedule Optimization adds priority, SLAs, travel time.
Territory Planning: each task gets a Territory field auto-populated from the Location's geocoordinates; territory model holds dispatch/assignment/qualification groups; needs a maps API key.
AWA = platform routing (service channels, assignment rules, queues, skills); FSM field work uses Dispatcher Workspace + Dynamic Scheduling + Territory Planning instead. No verified "AWA for FSM" page.
Stockrooms: personal (truck) vs group. Source part when missing. Transfer orders in alm_transfer_order (none needed if part already in personal stockroom). Stock rules = replenishment thresholds.
Install base items + assets + linear assets + affected products roll into the extended work order task summary (Xanadu).
Time recording: optional; auto-generates time cards + time sheets for approval; dedicated Time Recording for Field Service plugin; ties to platform time_card.
Planned maintenance: maintenance plans by time interval or meter; templates tied to maintenance schedules; a scheduled job auto-generates orders; Lead Time controls how far ahead.
Mobile: Now Mobile = requester app; ServiceNow Agent = technician/fulfiller app. Online or offline task completion; scheduled offline caching.
Contextual Search: Search Context + Resource Configurations surface knowledge articles (and catalog items) on WO/WOT forms.
SLAs: apply to wm_order and wm_task; suspend/resume SLA is first-class; built on platform SLM (task_sla / contract_sla).
CSM integration: create work orders from cases; map case fields to the work order table; customize state transition map.
Base plugin = field_service_management (separate subscription, auto-activates dependencies). Not com.snc.work_management.