This allows control of the tracker item lifecycle (or business processes) and associated workflow.

A customer or test engineer can enter issues into a tracker, and one developer or all developers that belong to a role are automatically notified. A developer can fix the issue, associate source code changes with the issue, and set the issue status to fixed. Generally, to associate a source code change with an issue, a commit is associated with the issue. The project roles of team members determine which notifications they receive in this process.

A state comprises all field or attribute values of a tracker item.

The current state of a tracker item is defined by the value of the Status field.

The default status options for trackers of the type Task are the following:

The order of the status options shown above reflect the position of the statuses in the lifecycle of the tracker items.

If a workflow is enabled for a tracker, the status changes are allowed when a state transition (from old to new status) is defined and the current user has permission to execute that state transition.

If a workflow is not enabled for a tracker, the tracker items still have a status but there is no control over which status changes are allowed and who can make them.

The state transitions that are allowed for items of a tracker are defined on the State Transitions tab of the tracker's configuration screen. For example:

You can select the Show obsolete states to see all states.

If a state is obsolete, the name contains the suffix Obsolete.

To define a new state transition, you can select the State Transition option from the More list at the bottom of the State Transition table. Or you can create a new state transition by clicking the transition lines in the workflow diagram. A screen appears in which you can enter the transition specification::

You must specify the From and To status for the transition:

There are two special From status values:

There should be exactly one state transition from Undefined/-- to a defined/initial status!

This is the initial state transition, that controls the process of creating new tracker items:

If there is no initial state transition at all, creating tracker items will not be allowed!

Newly created items will end up in no defined status ("Undefined/--").

State transitions also have the following :

State transitions can be hidden so they will not occur in theNext Steps or Transitions menu but are valid status changes.

The names of hidden transitions are shown as gray instead of blue .

To edit an existing state transition, click the transition name or choose Edit from the Context menu.

To delete a defined state transition, choose Delete from the Context menu.

You can set a transition condition to define to which tracker items the transition applies.

A default condition is Expression.

It allows you to define an expression (see Computed Fields that will be evaluated against a tracker item and must yield true or false, whether or not the transition applies to the item.

For example, to only allow this transition if the Story Pointsfield of the item has a value less than 7:

Another default condition is Leads back to previous subject item status which will only allow this transition if it returns the status to the previous status of the item. You may want to use this condition for transitions from special parking statuses where multiple transitions lead to this status, there are multiple transitions out of this status. and you want to restrict an outgoing transition to apply only if the status was entered by a transition in the opposite direction.

If you need conditions that exceed the expression language capabilities or need to consider other context information, such as the HttpServletRequest to check region, locale or user agent.

Each transition can be associated with a guard, which will only let the transition pass if the subject tracker item matches specific criteria.

A transition guard is a tracker view, whose condition will be evaluated against the tracker item which is the subject of the state transition.

The Guard selector shows all available tracker views in the current context.

If no suitable guard exists yet, you can create a new one by -clicking the Addlink on the right hand side of the Guardlist.

For example, a guard is named All approvals are finished and accepted from Forking sub-processes from processes (work items):

The new guard will be stored as a tracker view of the type Table with the configured Condition and Default Columns and Sorting.

You can edit the currently selected guard by clicking the Edit link.

From Codebeamer 9.4.0, you can use also suspected reference guards:

Since CB-7.8, multiple Workflow Actions can be associated with a state transition.

The Fields to Update from older Codebeamer releases are now also actions:

If you had developed custom actions, you should first check, whether one of the new parameterized Workflow Actions can be used for this task:

Only if no such action exists, you should try to migrate your custom action. See instructions here.