State models and the state transition matrix
Each state-based record type has a state transition matrix that lists its valid states and the actions that move the record between states.
You can use the state transition matrix to create, modify, and delete states.
Creating a state
To add a state to the schema, add the state to the state transition matrix, and then create a state transition.
The Designer adds the new state as a source state and as a destination state in the row and column headers of the state transition matrix. Next, you must create a state transition that defines how this new state is used in your state model. See Creating a state transition. Then, you must connect the new state to at least one other state with an action. Defining a state that cannot be reached by any actions generates a validation error.
If your schema contains packages that use state types, when you add a state you must map it to a state type in your schema.
Mapping state types
Some schema packages add to schemas hooks (scripts) that run when a change request moves to a specific state, for example, the UnifiedChangeManagement (UCM) package and the Resolution package.
To ensure that the hook runs at the correct time, you must map each state of that record type to a state type of the package. Each state type of the package must have at least one state from the record type mapped to it (which ensures that the hooks in the package have at least one state in which they run). You can map more than one state to a state type of the package.
If you add a state to a schema that uses state types, you must map that state to the appropriate package state type.
If you are using the UCM schema or package, you must also assign default actions for the states; see Adding an UCM integration .
Changing the name of a state
You can change the name of a state at any time. When you do, the state name is updated in any actions that refer to it.
If a hook refers to the name of a state explicitly, you must change the name of the state in the hook code.
Deleting a state
Delete any states that you do not plan to use. Defining a state that cannot be reached by one or more actions generates a validation error.
Do not delete a state if you plan to upgrade a database that currently uses it. You cannot upgrade the database if any records in it use the deleted state.
Before you delete a state, you must edit any actions that refer to it. The source or destination states of an action are not reassigned. Also, if you explicitly refer to a state in a script, you must modify the script to remove those references.