State flow customization
Summarize
Summary of State Flow Customization
State flow customization in ServiceNow's Service Management applications enables administrators to control how records transition between states. This feature allows you to define the sequence of state changes for requests and tasks, automate transitions, and customize field behavior during these changes. It replaces the standard process for state management by creating necessary business rules, client scripts, and UI actions to enforce the defined flows.
Show less
Key Features
- State Management: Add or delete states, and limit state choices to valid transitions from a given start state.
- Transition Control: Enable manual transitions through UI actions or automatic transitions triggered by data changes via business rules.
- Custom State Flows: Create tailored state flows requiring scripting knowledge to manage complex workflows.
- Field Controls: Control visibility and behavior of specific fields based on state changes or reaching an end state.
- Event Triggering: Trigger registered system events during state transitions or when records reach specific end states, supporting notifications and script actions.
- Dictionary Overrides: Define starting states for new records in extended tables, ensuring customizations apply appropriately.
- Role-Based Access: Ensure only users with appropriate roles (wmadmin or facilitiesadmin) can modify relevant state flows and records.
How State Flows Work
State flows replace standard request and task state processes by generating and managing the underlying scripts and UI elements that enforce transitions and field controls. When state flows are deleted, the system cleans up any associated programming elements no longer needed. State flows support:
- Manual Transitions: Initiated by UI actions when conditions or scripts are met.
- Automatic Transitions: Initiated by business rules based on data changes.
Start and End States
Custom state flows require defining starting and ending states to specify when processing occurs during state transitions. Some flows may only define an end state or a start state depending on processing needs, including cases where processing applies across multiple transitions.
Additional Operational Details
- Work Notes: Used to communicate information during state transitions.
- Rebuild State Flows: Available for resolving mismatches between existing and new sysids.
- State Flow Cleanup: Automatically removes related business rules, client scripts, and UI actions when state flow records are deleted.
Practical Benefits for ServiceNow Customers
By customizing state flows, you gain precise control over request and task lifecycle management, improve automation and consistency in state transitions, enhance user experience with dynamic field behavior, and integrate event-driven actions such as notifications. This flexibility helps align ServiceNow workflows with your organization's unique processes and governance requirements, ensuring accurate state tracking and efficient task execution.
State flows control the sequence in which records transition between states in Service Management applications.
- Add or delete states.
- Trigger events on particular state transitions.
- Transition to another state automatically when data in a request or its task changes, or change states manually when the user clicks a button.
- Limit the choice list for the State field to those end states that are valid transitions from the given start state.
- Control the visibility and behavior of selected fields on a target table when records in that table change states.
- Create custom state flows. Turn off the State flows are enabled option on the configuration screen. Creating custom state flows requires scripting knowledge.
How SM request and task state flows work
State flows replace the standard process that controls how requests and their associated tasks move between states. The ServiceNow system creates business rules, client scripts, and UI actions that perform the transitions and field controls you specify. These programming elements remain in use while the state flow records that use them are present. When state flows on an SM application table are deleted, the system attempts to delete any unnecessary programming elements that were created on that table. You can limit the selections for the State field to valid states for the transition, based on the starting state.
- Manual transitions:A UI action, created automatically by the system when you provide a condition or a script, initiates a transition.
- Automatic transitions:A business rule, created automatically by the system when you provide a condition and a script, initiates a transition when changes are made to a request or task.
Features available with state flows
- Custom transitions: Customize the order in which states can change for requests and task records.
- Field controls: Control the behavior and visibility of specific fields when a task changes states or reaches a specified end state.
- State choice list:Limit the values offered in a task record State field to valid states for that transition. This is the same client script that the system creates to manage field controls for state transitions.
- Events:Trigger events when a state transition occurs or when a record reaches a specific end state.
Start and end states
You can create a custom state flow for processing that must occur when a task record makes a specific transition from one state to another. These records require a starting state and an ending state, and processing occurs during the transition between states. To perform some processing when a task record reaches a particular end state, you only need to define the end state. In some cases a state flow can have a starting state only, such as when you need to perform some type of cleanup after a task is canceled. A state flow might have no starting or ending state if the processing in the record applies to more than one state transition.
The solution is to store the business rule or client script in a state flow record and create a condition to trigger processing for any state change that requires it. An example of this in field service management is the Roll Up Changes business rule on the Work Order Task [wm_task] table. This business rule rolls up state changes that occur in tasks to the parent work order.