Applications → Managing Workflows → About Application Workflows → Application Workflow Overview
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.
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 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.
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.
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 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.
Copyright © 2007–2015 Serena Software, Inc. All rights reserved.