Implementing Field Service Processes

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

---