--- sourceDocument: Australia Retail Industry sourceDocumentLink: https://www.servicenow.com/docs/r/australia/retail-industry Release : - australia ft:locale : - en-US ft:publication_title : - Australia Retail Industry ft:clusterId : - rahi bundleId : - rahi workflow : - Customer and Industry --- # Components for Break-Fix # Components for Break-Fix {#ariaid-title1} Release version: Australia Updated November 5, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Components for Break-Fix The Break-Fix component in ServiceNow Australia release provides a structured framework for managing equipment failure reports. It supports case tracking, role-based actions, and integration with IT incidents and field service work orders. This enables efficient handling of break-fix cases from initial report through resolution. Show full answer Show less ## Case States and Actions * **New:** Case just created and awaiting HQ triage. Requestor may close (cancel) the case. * **In Progress:** HQ agent reviews and works on resolution. Requestor can only view. * **Resolution Proposed:** HQ agent proposes resolution. Requestor can accept or reject; HQ agent can modify resolution. * **Closed:** Case resolved or rejected and considered complete. Only history view is available. ## Key Tables and Relationships * **Break-Fix Case:** Extends CSM Case; includes requestor, equipment, store, priority, state, and resolution. * **Service Incident:** Used for IT issues; linked one-to-one with break-fix case; requires *snincidentwrite* role for creation. * **Work Order:** Used for hardware issues; linked one-to-one; assigned to field technicians. * **Install Base:** Critical registry of installed equipment; filters equipment selection based on buyer organization (service organization). * **Service Organization:** Represents the store/location; equipment selection is filtered by this organizational relationship. ## Critical Fields and Filtering * **Buyer Organization (Install Base):** Filters equipment dropdown to show only equipment tied to the user's service organization, ensuring relevant equipment selection. * **Service Organization:** Auto-populated based on user's store; locked for store-level users to maintain data integrity. * **Service Issue Type:** Mandatory field to specify Hardware or IT issue; determines if a Work Order or Incident will be created. * **Case State:** Controls available user actions and workflow progression. ## Role-Based Permissions * **BREAKFIXAGENT:** Base role for HQ Support Agents; allows case triage, queue access, resolution proposals, and work order creation when FSM plugin is enabled. * **snincidentwrite:** Required for Break-Fix agents to create linked IT incidents. * **snincidentread:** Allows store associates and managers to view linked incidents. * **WMINITIATOR (Conditional):** Enables work order creation; Create Work Order button appears only if FSM integration plugin is installed. ## Typical Case Data Flow 1. Requestor creates a new Break-Fix case; store and equipment fields auto-populated and filtered. 2. Case routes to HQ queue for agent triage. 3. HQ agent selects Service Issue Type (Hardware or IT). 4. Agent creates Incident (for IT) or Work Order (for Hardware), or documents troubleshooting. 5. Agent proposes resolution, changing case state to "Resolution Proposed". 6. State changes and comments from Incident/Work Order sync as work notes on the case. 7. Requestor reviews resolution and either accepts (closing case), rejects (reopening case to HQ), or self-closes. ## Practical Benefits for ServiceNow Customers This structured approach ensures clear case lifecycle management, role-appropriate actions, and integration between break-fix reports, IT incidents, and field service tasks. It streamlines communication between store users and HQ agents, enforces data consistency through organization-based filtering, and supports prompt resolution with actionable notifications and status updates. Technical reference for Break-Fix case states, available actions, critical fields, tables, and data relationships. ## Case States and Available Actions {#breakfix-reference__case_states_reference} {#breakfix-reference__states_table__entry__3} | **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 | [ ] {#breakfix-reference__states_table} ## Key Tables and Relationships {#breakfix-reference__key_tables} {#breakfix-reference__tables_table__entry__2} | **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. | [ ] {#breakfix-reference__tables_table} **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 {#breakfix-reference__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-reference__role_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 {#breakfix-reference__data_flow} 1. Requestor creates case in "New" state with auto-populated store and filtered equipment 2. Case routed to HQ queue 3. HQ agent picks up case and selects Service Issue Type 4. HQ agent creates Incident (IT) or Work Order (hardware) or documents troubleshooting steps 5. HQ agent clicks Propose Solution → case state = "Resolution Proposed" 6. State changes and comments from the Incident/Work Order are added as work notes on the case 7. Requestor receives notification and reviews proposed resolution 8. Requestor accepts (closes case), rejects (reopens to HQ), or self-closes 9. Case state = "Closed" (accepted/self-closed) or "New" (rejected, reopens to HQ) **Related concepts** * [Break-Fix Case Management](https://www.servicenow.com/docs/4F9z7lyjj4P7vL1S~ZNDtw "Break-Fix Case Management enables store staff to report and resolve hardware and IT failures through a structured workflow involving requestors, HQ support agents, and field service technicians.") **Related tasks** * [Resolve Cases in Workspace through HQ Agents](https://www.servicenow.com/docs/8lqsL83On8_9i5Zc2X7swA "Review assigned break-fix cases in the CSM/FSM workspace, select a service issue type, and propose resolutions using troubleshooting steps, service incidents, or work orders.") * [Submit Break-Fix Cases through Portal or Mobile](https://www.servicenow.com/docs/6XXUwP79NHD5F1dGgwGdLQ "Report equipment failures using the Retail Operations portal or mobile app. Your requesting store and available equipment are automatically determined based on your user account and service organization.") * [Respond to resolutions through Portal or Mobile](https://www.servicenow.com/docs/P5CZCm9IZF21QMEaCmr8Ag "Review proposed resolutions and respond by accepting, rejecting with a reason, or self-closing your case. Available only when case is in \"Resolution Proposed\" state.")