Use state flows

  • Release version: Yokohama
  • Updated January 30, 2025
  • 4 minutes to read
    • Summarize
    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 Use state flows

    State flows in ServiceNow enable administrators to create custom workflows for tables that use state fields, allowing state transitions in any order or skipping specific states to match business practices. They also control field behavior and visibility on task forms, and can trigger system events like email or SMS notifications when tasks change states. This capability helps tailor the user experience and automate processes based on state changes.

    Show full answer Show less

    Key Features

    • Custom State Transitions: Define allowable state changes and skip states as needed.
    • Field Behavior Control: Configure visibility, mandatory status, and read-only states for fields during specific state transitions or when an end state is active.
    • Event Triggering: Automatically trigger registered system events and associated business rules when tasks move between defined states, supporting notifications and scripted actions.
    • Dictionary Overrides: Set starting states for new records in extended tables via dictionary overrides to ensure consistent initial states per table.
    • Automated Enforcement: The system generates business rules and client scripts to enforce field controls and state transitions, maintaining consistency without manual scripting for each case.
    • Rebuild and Cleanup: Tools are available to rebuild state flows after importing records and to clean up related system objects when state flows are deleted.

    Practical Application for ServiceNow Customers

    By implementing state flows, administrators can precisely manage task lifecycles and user interface behavior, ensuring that users only see valid state options and relevant fields for a given state. This reduces errors and improves process compliance. Additionally, automated event triggering streamlines communications and integrations based on state changes.

    Users with admin roles can create and customize state flows, but scripting knowledge is required for advanced customization. Field controls rely on client scripts and may interact with UI policies, so testing is recommended to confirm desired behavior.

    When importing state flow configurations, use the Rebuild State Flows function to resolve state mismatches caused by differing sysids, ensuring smooth deployment across instances.

    You can create custom state flows for any table that uses states.

    Make state transitions occur in any order or skip specific states according to your business practices. State flows can manage the behavior of fields and field visibility on a task form. State flows can also trigger system events that perform work such as sending Email and SMS notifications.

    Administrators can configure state flows to:

    The State Flow plugin installs records used by work management to control state transitions for work orders and work order tasks. For detailed information about using work management state flows, see State flow customization.

    Creating and customizing state flows requires scripting knowledge. Users with the admin role can create state flow records.

    Dictionary overrides for state flows

    A dictionary override in a state flow defines the starting state for all new records in a specific table.

    You set an override in tables that extend a base table only, so that your customizations are applied only to the extended table.
    1. In a state flow record, select an Ending state.

      This is the override value which becomes the starting state for all new records in the table named.

    2. Click Create Default Value.

      The system populates the Dictionary override field with a value of state, which is the field in the task table affected by the override. The Dictionary override field is read-only. After the override is created, the system hides the Create Default Value button on all subsequent state flow forms for that table.

    Events triggered on state changes

    You can configure a state flow to trigger a registered system event when a task transitions from a starting state to a specified end state.

    For example, you can use events to trigger email notifications and create script actions. When you attach an event to a state flow, the system creates a business rule called State Flow Events for <table name> for the table specified in the state flow. If you specify a start and end state, the business rule executes when the record transitions from the start state to the end state. If the state flow only specifies an end state, the business rule executes whenever that end state is reached. The system creates one business rule for all state flows containing events on a single table. When all events or all state flows on a table are deleted, the system deletes the business rule.

    Field controls

    You can define controls for individual fields that are enforced when a record transitions between states.

    Settings in the Field Controls section of the State Flow form enable you to apply field controls when the system detects a specified state transition or when the end state is the current state when the form is opened. The control is applied only to existing fields on the form. State flows cannot add fields to the form.

    For example, you might want the Problem field to be visible when an incident moves to the Awaiting Problem state. If the incident state changes to Awaiting User Info, you hide the Problem field and make the Caller field mandatory.

    When creating field controls, configure state flow records with an ending state only and to create the correct behavior for every ending state you want to control. This configuration ensures that the field controls are set properly when the user selects a new state, and also when the user returns a record's State field to the original state. Only specify a full state transition, with both a starting and ending state, when you want a particular behavior for that precise state transition.
    Note:
    State flows use client scripts to enforce field controls. It is possible that your settings can be changed by existing UI policies, which execute after client scripts.
    The system creates the following objects, as needed, to enforce field properties in state flows:
    Table 1. Field Controls
    Type Name Description
    Business rule State Flow Notes for <table name> Enforces mandatory fields for the table on which that field behavior is defined.
    Client script (onLoad) <table name> state flow Sets possible states and initial mandatory, read-only, and visible properties when a record is loaded.
    Client script (onChange) <table name> change state flow Sets updated mandatory, read-only, and visible properties when a record is changed.

    Rebuild state flows

    You can rebuild state flows when a mismatch between existing and new sys_ids occurs.

    When you use an XML file to import a state flow record into an instance, the system attempts to match the incoming states with existing states by comparing sys_ids. Because the sys_ids of items in a choice list can vary between instances, the system can fail to match the states, even though they are otherwise identical.

    When matching fails, the start and end states of affected records are left blank or contain numeric values. To repair these records navigate to State Flows > Admin > Rebuild State Flows. This module runs a script that compares the numerical value of each item in the State field choice list until it finds a match in the imported state flow record.

    State flow cleanup

    Work notes