Cheat Sheet: State Flows

[Chuck Tomasi]

Table of Contents

Description

State flows are a no-code or low-code activity. They create UI actions and Business Rules as a result of the state flow definition. The scripts created call script includes that reference the definition records. All additional maintenance is done on the state flow records, not the resulting business rules/UI actions.

Plugins

State flows require the plugin "State Flows (com.snc.state_flows)" to be activated.

Details

State flows can be used to control the following:

• Manual transitions: Initiate manual transitions by a UI action that the system creates when you provide a condition or a script.
• Automatic transitions: Initiate automatic transitions from a business rule that the system creates when you provide a condition and a script.
• Custom transitions: Customize the order in which states can change for records in any table that extends the Task [task] table.
• 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's 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.

State Flows are configured under State Flows> State Flows.

Starting State/Ending State Values

The key to remember about start/end state values on the form is that they define a "transition" between states (when both values are populated.) In some cases it is useful to have null values.

Starting State	Ending State	Notes
Value	Value	Processing occurs during the transition between states. Use case: Business rules and onChange client scripts.
Null	Value	To perform some processing when a task record reaches a particular end state, you only need to define the end state. Use case: UI action and onLoad client script
Value	Null	Use case: Some type of cleanup after a task is canceled.
Null	Null	A state flow might have no starting or ending state if the processing in the record applies to more than one state transition (use with conditions on UI action or BR) (Does not apply to field controls)

Example of Manual Transition. This creates a UI action called Close Complete on the form that is available in the Starting State when the conditions are met. When the button is clicked, the state changes to the value in the Ending State and the script is run to set the work_end date.

If no starting and ending state are used, the UI action is available for all states and the condition field and condition builder are still evaluated.

Example Automatic transition: This definition produces a business rule called Cancel Cleanup (same as the state flow definition name) that runs when the state changes to cancelled (7) and automated state flow is true.

Special note

You may find it helpful to add the following attribute to update the dictionary entry sf_state_flow.automatic_condition to reduce scripting I the condition string field.

extended_operators=VALCHANGES;CHANGESFROM;CHANGESTO

Reference:

http://wiki.servicenow.com/index.php?title=State_Flows#gsc.tab=0

http://wiki.servicenow.com/index.php?title=Using_State_Flows#gsc.tab=0

[Mike Allen]

Thanks, Chuck, for this.   I am wondering about this line:

extended_operators=VALCHANGES;CHANGESFROM;CHANGESTO

Can we use that throughout the system?   We have found that this would be especially helpful in UI Policies to prevent the necessity of some client scripts.

Thanks!

[Chuck Tomasi]

It would appear not. I added the attributes to the Conditions field of the UI policy, set up a simple one to make the state R/O if incident.caller_id is Fred Luddy. While the condition appears to evaluate, it returns false. This may be something for server side only (and only in certain situations where the context knows the previous and current values.)

[SwarnadeepNandy]

What is the difference with state model?

[Andrew Hutchiso]

It seems wrong to me that the Cancel Cleanup flow is defined as starting in the Cancelled state, when the rule needs to execute when reaching that state.  It should be defined as a Null to Cancelled transition.  However, if you try this, the code that builds the Business Rule creates something that runs every time.  There appears to be a logic problem in the global.StateFlow script, in createBusinessRule (on Madrid at least).

This generates a condition on the business rule using this logic:

var state = "";

if (!current.start_text.nil()) state = "current.state==" + current.start_text + " && ";

This implies the rule runs when the record reaches the starting state, it should run when the record reaches the ending state.  This affects all such business rules generated from state flows, not just Null to Something, but A to B.  The BR runs when the record flows to A, not when it flows to B.

A correction to the logic in createBusinessRule, that makes more sense to me, is:

if (!current.end_text.nil()) state = "current.state==" + current.end_text + " && ";

With this change I'm more confident in using this platform plugin, in conjunction with State Models, to control custom task records.

[Ashu_8871]

Can we add conditions on field controls?
I have a use case: Fields visibility on the form depends on the value of a choice field in the Case form.
At first I thought we can use the condition in the Manual Tab to specify when field controls should run, but I think that's not possible.