An application workflow ensures the proper flow of primary items using a defined process that consists of fields, states, transitions, and decisions. Items must follow this application workflow from the time they are submitted to the time they are closed.
A sub-workflow is derived from an existing workflow. You could create a sub-workflow if you want to recreate the basic process defined in the existing workflow, but do things such as removing some states or changing the privileges on some transitions in the sub-workflow. Each workflow can contain multiple sub-workflows, and sub-workflows can contain their own sub-workflows. By default, when you make a change to a parent workflow, you get a warning that its sub-workflows will also be affected. You can disable this warning on the Workflow Options tab in SBM Composer SBM Composer Options.
You design workflows in SBM Composer. In SBM Application Administrator you assign the workflows to projects.
Elements of an Application Workflow
States: A state is a position in an application workflow where a primary item resides. While an item resides in a given state, it has a primary owner who is responsible for performing a specific task with the item before it can be transitioned to the next state. You can also set up an application workflow so that one or more users are secondarily responsible for items while they reside in a particular state.
Transitions: A transition activates the movement of a primary item from one state to another in the application workflow. A user who has ownership of an item transitions the item to the next state in the workflow when the corresponding task is finished. Transitions can be customized in many ways. For example, you can restrict transitions so that they apply only to certain item types, such as bugs and problem reports, or so that only members of particular groups can execute them.
Fields: Fields let users provide information about the primary items they are submitting or transitioning from state to state. The fields store the information in a primary table, located in a central database. They can be tailored to prompt users for pertinent information as a primary item moves through the application workflow.
Forms: Forms determine the information that is presented to users as they work with items. View forms are used with states, while update forms are used with transitions.
The following figure shows an application workflow that defines the states and transitions an item must go through in order to reach a "closed" (completed) state.
- Decisions are required for conditional routing. A decision has one incoming transition and two or more outgoing transitions. When an application workflow reaches a decision, the rule for each outgoing transition is evaluated, and the outgoing transition with the first rule that evaluates to "true" is executed.
-
Swimlanes are a way to visually group states in an application workflow, so others can quickly understand the workflow design. A swimlane typically represents either the activities performed by the same role or participant, or a distinct phase of the process defined by the workflow.
- Annotations are notes that you can add to a workflow or sub-workflow.
- The Relationships bar provides visibility into design elements, such as forms, that an application workflow uses. This lets you easily understand and explore the relationship between the states and transitions in the workflow and the related design elements.
Internal Names
Workflows, states, and transitions have internal names that are automatically assigned when they are created or added. Because internal names are unique, they provide the ability to unambiguously identify a state or transition in scripts and Web service calls. Because internal names cannot be changed after publication, you can safely use them to identify a state or transition without concern that a change to the name would break scripts or orchestrations.
- The internal name of the workflow in which the state or transition is defined. This part can never be changed.
- A local part that can be changed until the process app that contains the state or transition is published.
- The local part of the internal name must be unique among the other states and transitions defined in the workflow. For example, if there are two transitions in a workflow called "Assign," their internal names could be "MyWorkflow.Approve" and "MyWorkflow.Approve1."
- If the two transitions were defined in different workflows, the local part can be the same because the internal workflow names are different, making the internal name as a whole unique. For example, "MyWorkflow.Approve" and "MySubWorkflow.Approve."
Application Workflows Heading
The Application Workflows heading in App Explorer displays all the application workflows and sub-workflows that you defined for the selected application. You can click the Workflow Design filter at the bottom of App Explorer to see only the Application Workflows and Orchestration Workflows headings.