Script Procedure Names
This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
Although you can set an action name to anything, the script procedures do not reflect this user-defined naming. The script procedure names are based on the state ID or the associated state and the action name.
For example, if you add a Create action to a state called Resolved and you named it New, then the validation script procedure for that action is named State2_Validate_OnCreate.
State2 refers to the state ID of the state with which the action is associated.
Validate means this is a validation script procedure.
OnCreate means this is an OnCreate event triggered when a new record is created and set to this state.
Behind the scenes, each state in a workflow diagram is assigned a state ID. The state IDs are integers, starting at one and increasing by one. The first state, in this example Active, is one, the second state, Resolved, is two, and so on. When you assign actions for this Active state, such as Create, you have events called:
Function State1_Validate_OnCreate
Sub State1_OnCreate
If you add a Change action, the associated events appear as:
Function State1_Validate_OnUpdate
Sub State1_OnUpdate
The same Change action when created for Resolved, the second state, is called:
Function State2_Validate_OnUpdate
Sub State2_OnUpdate
For transitions, the same format applies, with the addition of the next state ID at the end of the name. For example, when transitioning from State1 to State2:
Function State1_Validate_OnTransition2
Sub State1_ OnTransition2
The 2 at the end of the name refers to the state that is the result of the transition. In this example, it is the second state in the workflow process.
The following table shows a matrix detailing the event procedure naming convention for a single state. In this example, the state ID is State1, and the state name is Active.
Action | Script procedure | Event procedure name |
Transition | Validate | State1_Validate_OnTransition2* |
Transition | Action | State1_OnTransition2 |
Create | Validate | State1_Validate_OnCreate |
Create | Action | State1_OnCreate |
Delete | Validate | State1_Validate_OnDelete |
Delete | Action | State1_OnDelete |
Change | Validate | State1_Validate_OnUpdate |
Change | Action | State1_OnUpdate |
Enter | Validate | State1_Validate_OnEnter |
Enter | Action | State1_OnEnter |
Exit | Validate | State1_Validate_OnExit |
Exit | Action | State1_OnExit |
First Timeout | Validate | State1_Validate_OnTimeout |
First Timeout | Action | State1_OnTimeout |
Second Timeout | Validate | State1_Validate_OnTimeout1 |
Second Timeout | Action | State1_OnTimeout1 |
Third Timeout | Validate | State1_Validate_OnTimeout2 |
Third Timeout | Action | State1_OnTimeout2 |
*Transition events start with the name of the current state (in this example State1) and end with the state ID of the state being transitioned to (in this example 2 for State2).
You can have multiple transition actions and time-out actions. Time-out event procedures remain unique by adding a counter to the end of the event procedure name. The first state has no number, and each subsequent OnTimeout event is named OnTimeout1, OnTimeout2, and so on.
Transition event procedures remain unique by starting with the current state and ending with the next state: State1_Validate_OnTransition2, State1_Validate_OnTransition3, and so on. Because there can be only one transition between any two states, this helps keep the names unique.