This information is for planning purposes only. The information herein is subject to change or removal without notice before the products described may become available.
The CE/CLM products were renamed in version 7.0. As the help is updated to reflect the changes, the topics might contain inconsistencies. For details on the name change, see Renaming the IBM Continuous Engineering Portfolio.

Defining custom workflows for test artifacts

Starting in version 4, you can customize the workflow for several test artifact types, including test plans, test cases, test scripts, test suites, test case results, and test suite results. All workflows are defined at the project level. Typically, you modify an existing workflow, although you can also create new workflows.

About this task

A workflow is a state transition model that defines the states for test artifacts and the actions that users take to move the test artifact from one state to another. Typically, a workflow starts with a Draft state and ends with a state that reflects the final disposition of the artifact, such as Approved or Closed.

You define a state transition model by binding the workflow to a test artifact type. For example, in the default workflow, when a reviewer rejects a test plan that is under review. the test plan returns to the Draft state. One possible customization would be to create a new test plan state called Rejected, which would serve as the state for test plans that failed the review.

Ideally, you define workflows when you create a project area.

  • Avoid making changes to workflows in large projects. The only exceptions are name changes and additions.
  • If you open an artifact in an invalid state, the state is reset to the initial state.
  • If you remove states or workflows, states are likely to become invalid.

For additional details about defining custom workflows, see


  1. In the upper-right portion of the banner click the Administration (Administration) icon and click Manage This Project Area.
  2. In the Project Area editor, click Test Artifacts > Workflows.

    The Workflow editor opens, showing first the Workflows Bindings section, which determines the workflow to be used for an artifact.

    Workflow Bindings

  3. In the Workflow Definitions section, select a workflow to edit, such as the Test Plan Workflow.

    Workflow Definitions

    In the Workflow Definitions section, you can edit a workflow, add a new workflow, or remove a workflow. The Start Action determines the initial state of the artifact, such as Draft. To add a new workflow:

    1. Click Add.
    2. In the ID field, enter a name for the new workflow. By default, the Name field is populated with the same value that you enter into the ID field. Optionally, you can edit the Name field value. Click OK.
  4. In the States section, configure the states for the workflow. For each state, set the actions, which define the order in which actions are displayed throughout the user interface.
    Workflow States

    To define states in the workflow, repeat this process:

    1. In the States section, click Add.
    2. Enter a name and brief description for the state.
    3. Select a group that is appropriate for the State, such as Draft, Under Review, Reviewed, Approved, or Closed. For example, if you create a state called Reopened, you might assign it to the Draft state.
      Note: State groups are used for business logic and are needed for consistent reporting. For examples of how business logic is configured in the Quality Management application, see Preconditions for quality management.
    4. Select one of the icons that are included in the process templates. If you want an icon that is not in the list, click Browse and navigate to a graphics file to use as the icon.
    5. Click OK.
    Repeat this process to define all states in the workflow.
  5. Optional: To enable cross-project linking between workflow states, in the States area, in the External Value field, specify a unique value to identify the state across QM projects.

    Within a project, you must use a unique value for each state. If another project has an equivalent state, use the equivalent state's value to ensure consistency across projects and to enable a shared vocabulary for reporting.

    For example, Project_A has a state named Retired and Project_B has a state named Closed. Your organization considers these states equivalent even though their names and enumeration values differ. If you assign the same value to these equivalent states, you can ensure that they have a consistent meaning and you can report on them across projects.

  6. In the Actions section, define the actions for the workflow. Actions link states together and can have permissions assigned to them. Multiple actions can point to the same target state.

    Workflow Actions

    To add an action:

    1. In the Actions section click Add.
    2. Enter a name for the action, optionally select a target state and an icon, and then click OK.

    Continue to add actions as necessary to support your state transition model. At a minimum, provide actions that users can use to move the artifact from its original state to its final state.

  7. In the Transitions section, connect the From states to the To states by using actions, such as Reject, Approve, and Reopen. A matrix illustrates the state transition model. The row headings contain the From state, and the column headings contain the To state. The intersecting cells contain the actions that users take to move the artifact from one state to another.
    Note: Define the states and actions before you define the transitions.

    For example, in the From column, find the row containing the Draft state and select Ready for review in the Under Review column. This indicates that a test plan in the Draft state will transition to the Under Review state when a user selects the Ready for review workflow action.

    In addition, you can define preconditions and follow-up actions for workflow transitions. These are defined for a particular role, such as a Test Team Member, and an operation, such as, Save Test Plan. For details, see Preconditions for quality management.

  8. When you are finished defining the workflow, click Save.
  9. Optional: Add a permission to a workflow action. The following image shows permissions for workflow actions.

    Workflow Trigger

    To add a permission to an action:

    1. In the project area, click Permissions.
    2. Select Project Configuration or Team Configuration.
    3. Select a role, such as Test Team Member.
    4. Under Quality Management, expand a permitted action, such as Save Test Plan.
    5. Expand Trigger a workflow action, and select the actions, such as Approve and Reject, to allow for the selected role.
    6. Click Save.

video icon Video channel
Software Education channel

learn icon Courses

IoT Academy
Skills Gateway

ask icon Community forums library

support icon Support

IBM Support Community
Deployment wiki