Components for Break-Fix

Release version: Australia

Updated August 11, 2026

2 minutes to read

Summarize

Summarized using AI

Summary of Components for Break-Fix

This document provides a detailed reference for managing Break-Fix cases within ServiceNow. Break-Fix cases represent reports of equipment failure and involve coordinated handling by requestors, HQ agents, and field technicians. The process integrates with IT Incident and Field Service Management (FSM) Work Order modules to address hardware and IT-related service issues effectively.

Show full answer Show less

Case States and Actions

New: Case just created by the requestor, awaiting HQ triage. Requestors can close (cancel) the case.
In Progress: HQ agent reviews and works on resolution. Requestors have read-only access; HQ agents can update the case.
Resolution Proposed: HQ agent proposes a resolution. Requestors can accept or reject the proposal; HQ agents can modify it.
Closed: Case is resolved or rejected and considered complete. Only history can be viewed.

Key Tables and Relationships

Break-Fix Case: Extends the Customer Service Management (CSM) Case table and tracks equipment failure with fields for requestor, equipment, store, priority, state, and resolution.
Service Incident: Linked one-to-one for IT issues; requires the snincidentwrite role for creating incidents. State changes and comments sync as case work notes.
Work Order: Linked one-to-one for hardware issues, assigned to field technicians. State changes and comments also sync as work notes.
Install Base: Critical registry of installed equipment, filtered by Buyer Organization (Service Organization) to control equipment selection per store.
Service Organization: Represents the store/location and filters the equipment available to users based on their organization.

Critical Fields and Filtering

Buyer Organization (Install Base): Filters equipment dropdown to only show devices purchased by the user's service organization.
Service Organization: Auto-populated based on the user’s store; cannot be changed by store-level users.
Service Issue Type: Mandatory field to specify whether the issue is Hardware or IT. Determines whether a Work Order or Incident will be created.
Case State: Controls available actions and workflow progress.

Role-Based Permissions

BREAKFIXAGENT: Base role for HQ support agents, granting access to case queues, triage, resolution proposals, and Work Order creation if FSM plugin is enabled.
snincidentwrite: Required for Break-Fix agents to create linked incidents.
snincidentread: Allows store associates, managers, or regional managers to view linked incidents.
WMINITIATOR (Conditional): Enables the creation of Work Orders; visible only if FSM integration is installed.

Typical Case Data Flow

Requestor creates a new Break-Fix case with store auto-populated and equipment filtered by their service organization.
Case routes to the HQ queue.
HQ agent picks up the case, selects the Service Issue Type (Hardware or IT).
HQ agent creates a linked Incident (for IT issues) or Work Order (for hardware) or documents troubleshooting.
HQ agent clicks "Propose Solution," changing the case state to "Resolution Proposed."
State changes and comments from the Incident or Work Order are added as work notes on the Break-Fix case.
Requestor is notified, reviews the proposed resolution, and either accepts (closes case), rejects (reopens case to HQ), or self-closes.
Case state changes to "Closed" if accepted or self-closed, or reverts to "New" if rejected.

Practical Implications for ServiceNow Customers

This configuration enables ServiceNow customers to efficiently manage equipment failure cases by leveraging integrated IT and FSM workflows. It enforces role-based access, filters equipment selection based on organizational context, and provides a clear case lifecycle with defined states and actions for both requestors and HQ agents. Customers can expect streamlined communication, transparent case resolution steps, and proper tracking of hardware and IT issues within a unified Break-Fix case management framework.

Technical reference for Break-Fix case states, available actions, critical fields, tables, and data relationships.

Case States and Available Actions


State	Description	Available Actions
New	Case just created by requestor. Awaiting HQ triage.	Requestor: Close (cancel case)
In Progress	HQ agent reviewing and working on resolution.	Requestor: None (read-only). HQ Agent: Resolve
Resolution Proposed	HQ agent has proposed resolution.	Requestor: Accept or Reject. HQ Agent: Modify resolution
Closed	Case resolved or rejected. Complete.	View history only

Key Tables and Relationships


Table	Description
Break-Fix Case	Extends CSM Case. Represents equipment failure report. Contains: requestor, equipment, store, priority, state, resolution info.
Service Incident	Linked for IT issues. Pre-populated with case details. Requires the sn_incident_write role assigned to the Break-fix agent. State changes and comments are added as work notes on the case.
Work Order	Linked for hardware issues. Assigned to field technicians. Pre-populated with case details. State changes and comments are added as work notes on the case.
Install Base	CRITICAL: Registry of installed equipment. Key field: Buyer Organization (Service Organization). Equipment filtered by this relationship.
Service Organization	Represents store/location. Equipment registered with organization as buyer.

Key Relationships:

Install Base → Buyer Organization: FILTERS equipment dropdown to user's store. Only equipment where buyer org = user's service org appears selectable.
Break-Fix Case → Incident: One-to-One link for IT issues. State changes and comments are added as work notes on the case.
Break-Fix Case → Work Order: One-to-One link for hardware issues. State changes and comments are added as work notes on the case.
Break-Fix Case → Install Base: Reference to track which equipment failed.

Critical Fields

Install Base Buyer Organization: KEY FILTERING MECHANISM. Field on Install Base table. Determines which equipment users can select. Only equipment where buyer organization matches user's current service organization appears in the case form's Affected device (Install base) dropdown.
Service Organization: Represents the store. Auto-populated in case form from user's service organization. Cannot be changed by store-level users.
Service Issue Type: Hardware or IT. Mandatory before HQ proposes resolution. Hardware enables work order creation. IT enables incident creation.
Case State: New | In Progress | Resolution Proposed | Closed. Determines available actions for requestors and HQ agents.

Role-Based Permissions

BREAKFIX_AGENT: Base role for HQ Support Agents. Grants queue access, case triage capabilities, and resolution proposal actions, including creating work orders when the FSM integration plugin is installed.
sn_incident_write: Required by the Break-fix agent to create a linked incident.
sn_incident_read: Required by the store associate, manager, or regional manager to view a linked incident.
WM_INITIATOR (Conditional): Enables work order creation. The Create Work Order button appears only if the FSM integration plugin is installed.

Typical Case Data Flow

Requestor creates case in "New" state with auto-populated store and filtered equipment
Case routed to HQ queue
HQ agent picks up case and selects Service Issue Type
HQ agent creates Incident (IT) or Work Order (hardware) or documents troubleshooting steps
HQ agent clicks Propose Solution → case state = "Resolution Proposed"
State changes and comments from the Incident/Work Order are added as work notes on the case
Requestor receives notification and reviews proposed resolution
Requestor accepts (closes case), rejects (reopens to HQ), or self-closes
Case state = "Closed" (accepted/self-closed) or "New" (rejected, reopens to HQ)