About step states

At a high level, each step in a workflow represents one activity within an overall business process, for example, verifying employment status in a loan processing workflow.

For most users the concept of a step as a single action is appropriate, though in actuality a step goes through a series of discrete phases, known as states. Within each state, the system software performs one or more operations on the work item. Generally, step states are transparent to users; however, workflow authors and application developers might need to understand step states to make informed decisions in workflow definition and application design.

Following is an overview of the operations that can occur within a step. The operations are listed sequentially and are grouped into their respective states (each state is numbered). The overview also shows points at which the flow of control can move to another workflow map (indicated by =>).

1. Before Step
   1. Join children with parent in Delay queue
   2. If last child, then advance parent into the step
2. Pre-Condition
   1. Clear F_Comment
   2. Clear F_Responses and F_ResponseCount
3. Pre-Assignment
   1. Execute pre-assignments
      1. [=> Exception]
4. Milestone
   1. Execute pre-milestone
5. Deadline
   1. Calculate deadline expression
      1. [=> Exception]
   2. If necessary calculate reminder expression
      1. [=> Exception]
6. Queue
   1. If necessary split into multi-participant work items
   2. If necessary queue work item. While the work item is in a queue:
      1. [=> API call]
      2. [=> API exception]
      3. [=> Timer expiration]
7. Post-Assignment
   1. Check responses
   2. Execute post-assignments
      1. [=> Exception]
8. End Step
   1. Execute post-milestones
   2. Evaluate routing
   3. Clear F_Responses and F_ResponseCount
   4. Clear F_Comments
9. Route
   1. If necessary split into children
   2. If necessary store the parent in the Delay queue
   3. Move the work item or work items into the next step

A workflow map that takes control (at a point marked with => above) could contain a Return system function. Each Return includes a retry option that tells the Instruction Sheet Interpreter (ISI) to either skip or repeat the state containing the calling entity when control returns to the original workflow map. For example, if an exception occurs in the post-assignment state during execution of post-assignments (7b above), that exception is the calling entity. If the ISI reaches a Return system function on the called workflow map, control returns to the original (calling) workflow map. Depending on how the Return is defined, the ISI either repeats or skips the post-assignment state upon return to the calling workflow map. Note that the repeat or skip setting applies to the state, not to the operation within the state that triggered the calling entity. The table below indicates the ISI behavior corresponding to both return and skip.