Initial and Final States in a Workflow

A workflow can have as many states as it needs in order to correctly depict the action or actions taking place. These states all must have at least one transition coming into the state and at least one outgoing transition from the state. However, the two states that every workflow needs, the Initial State and a Final State, do not necessarily have to abide by these transition rules depending on the workflow layer they reside in.

Initial

Initial can be a single entry point and can also be multiple entry points that work in parallel.

Initial State

The Initial State, represented by a slightly darker colored state, signals to an object entering the workflow where to start. This could be in a simple workflow, such as the one pictured below, or it could be in regards to telling an object which state to start with when entering a cluster. There can only be one outer Initial State for the general workflow, and there can only be one Initial State inside each cluster. An outer layer Initial State does not have an incoming transition, only an outgoing transition. This outer Initial State signals to the object / task entering the workflow where to start. Once an object knows what state to start with, the workflow can progress.

For more on Clusters, refer to Clusters in Workflows in the Workflows documentation here.

Initial as a Parallel

It is often necessary for more than one incident to take place at a time in a workflow. In this case, a Parallel structure should be used as the Initial State, which auto-initiates the object into the Initial States within each cluster simultaneously. The object only leaves the Parallel once the object has reached the Final State in each cluster.

For more on Parallels, refer to Parallels in Workflows in the Workflows documentation here.

Final

States with the Final characteristic are used to denote the ending of either an entire Workflow or a Cluster. Only Final States within Parallels and Clusters can have an incoming and outgoing transition.

All workflows should have a reachable outer layer Final State. Never-ending workflows can lead to performance impacts. However, there cannot be transitions out of a outer layer Final State characteristic, only incoming transitions. For this reason the outer layer Final State rarely represents a human task. When an object reaches a Final State on the outer level of a workflow (not in a Parallel or Cluster), it will remain there until the object is taken out of the workflow.

For performance reasons, and because the workflow cannot be started again on an object already in the workflow, it often makes sense to automatically remove objects from the workflow as they reach a Final State on the outer level.

For more on how to automatically remove an object from a workflow refer to Remove Objects from Workflows in the Workflows documentation here.