Overview

This article provides a high-level overview of State Management in ServiceNow, explaining how State Models and State Transitions define and control the lifecycle of task-based records such as Epics. It describes how organizations can structure record progression through predefined states, ensuring consistency and governance across processes. This article also outlines how multiple models can apply to the same table and how evaluation logic determines which model governs a record.

 

State Models

The first thing we must do it go to “State Management > State Models” as shown below:

 

 

Then we will see the State Models that come out of the box. Bear in mind these may change depending on the plugins/applications you have installed on your instance. In this case, this is what we can see:

 

 

For our example, we will show how to create a State Model for Epics. This can be replicated for any table inheriting from “Task”.

 

If you click on “New” you will see the form that will allows us to create the State Model we need. Then we enter a name (i.e: “Epic: Default Flow”), ensure it’s active and select the “Epic” table. Remember that if you have different State Models that apply to the same table you will need to enter an order value so that they are evaluated in the right order.

 

You can see how OOB there are three different State Models for Changes and they are processed in this order: Normal, Emergency and Standard. A lower number, as usual, means it will be evaluated first. Evaluated doesn’t mean triggered, it means its “Condition” field will be tested. If the condition evaluates to “true” the State Model will be triggered, otherwise, ServiceNow will move on to the next State Model paying attention to the order field.

 

The “Condition” field contains all fields present at the Task table we show

 

 

It’s recommended entering a description in the “Description” field, especially if there are several State Models for the same table, given developers, consultants or admins will have to understand it at some point due to fixes or enhancements.

 

The last field we see is the “Common Exit Field”, but we will talk about this once we have covered the Transitions, which will make use of it.

 

State Transitions

The model itself only defines when the set of transitions will apply, but we haven’t yet explained which transitions are allowed between states. The “State Transition” records referenced under the related list on “State Models” allows us to define which ones we accept and under which conditions.

 

Let’s see how we can create one and what are the different fields used for.

 

 

In the example above, we select the “Ready” state out of the ones being offered. The states shown on the dropdown come from the table selected at the “State Model”.

 

We should enter a description explaining the transition (although in our example we won’t for simplicity) and an order in which the State Transitions will be evaluated. Similarly to the State models, the “Enter Condition” field is the one that defines when the “State Transition” has to be applied.

 

In this case, we are allowing transitions from “Draft” to “Ready” and only this transition if allow to get to “Ready”. This means if the Epic moves to “Work in progress” it cannot go back to “Ready” at any point in time.

Bear in mind if you leave the condition empty, it means you can move to the state defined in the “State” field from any other state.

 

This can be clearly seen if we have a look at the complete list of transitions:

 

 

“Cancelled” is a great example of this. Since we are allowing Epics to be cancelled at any time, the “Enter” condition of the “Cancelled” State Transition must be left empty.

 

You may have already realised there’s a “Terminal State” field. This field, as its name describes, allows us to determine that a state is final and that once a task arrives to it, it cannot get out of it. “Complete” and “Cancelled” in this case, are the “Terminal States” of our State Model.

 

The last field we see, and it ties to the previously mentioned “Common Exit Condition” on “State Models” is “Exit Condition”.

 

This condition at the State Transition level defines when we will be able to get out of such state. This can be easily seen with the picture below.  

 

States Transitions are independent build blocks within your “State Model” which may or may not have “Exit Conditions”. Most of the times there will not be an “Exit Condition” but the option is there to tackle certain scenarios. For instance, imagine you want all epics to be approved before being moved to “Ready”. In this case, we would need to create a new state called “Awaiting Approval” and the “Exit Condition” of such State Transition should be as follows:

 

After concatenating several State Transitions those would be seen this way:

 

 

However, you have to remember we hadn’t talked about the “Common Exit Condition” mentioned on the State Model section, which is yet another barrier we can set in between the states.

 

Instead of defining the same condition all over again in each state transition, you can move the common Exit conditions to the State model. Unfortunately, there’s no “Common Enter condition” so if you have a common enter condition (quite unlikely but still probable) you will have to enter it in each State Transition.

 

This is how “Common Exit Conditions” have to be understood, operating as an “AND” with Exit conditions of each State Transition.

So, before you move from State 1 to State 2 you will need to satisfy the following:

• The “Exit Condition” of the “State 1”
• The “Common Exit Condition” defined on the State Model containing the “State 1”
• The “Enter Condition” of the “State 2”

If any of these is not satisfied, you will not be able to move to State 2, however, you might be able to move to other state, for instance “Cancelled” which doesn’t have “Enter Conditions”. Nonetheless, remember that if you had an “Exit condition” or “Common Exit Condition” those will have to be satisfied before moving to “Cancelled” even if this doesn’t have enter conditions.

 

Last but not least, remember that the State Model only evaluates after saving the record , therefore on creation you will have to limit the states that can be chosen with a different mechanism.

 

Please like 👍 and share 🌍 this article to your colleagues if you found it useful.