Restricting Transitions

Restricting Transitions for All Items

Privileges enable you to restrict transitions for all items in a project. You can grant or remove transition privileges for roles in SBM Composer or for individual users and groups in Application Administrator.

The following privileges are available for controlling transitions for all items in a project, depending on a user's product-access type:

Transition All Items
Transition Item if Owner
Transition Item if Secondary Owner
Transition Item if Submitter

Restricting Individual Transitions

In some cases, you may need to limit individual transitions that are available to users. For example, you may want to restrict an "Approved" transition to users with a Manager role. In this case, users with the "Transition All Items" privilege would not see the "Approved" transition unless they are assigned to the Manager role.

The following restriction types are defined in SBM Composer and are the best method for restricting individual transitions:

Role Restrictions
Transitions are not available to users assigned to restricted roles. Refer to Restrict By Role Tab of the Transition Property Editor.
Rule Restrictions
Transitions are not available based on business rules, such as removing an "Escalate to Management" transition for low-priority items. Refer to Restrict By Rule Tab of the Transition Property Editor.
Item Type Restrictions
Transitions are not available based on item types. For example, you can restrict a "Send to Software Team" transition for items with a "Hardware Requests" item type. Refer to Restrict By Type Tab of the Transition Property Editor.

In SBM Application Administrator, on-premise customers can restrict transitions so they are unavailable for members of specific groups. For guidance, refer to the SBM Application Administrator Guide located on the Documentation Center.

Role Privileges and Restrictions for Transitions

The transition privileges associated with roles and the restrictions specified for transitions are processed separately, in the following three steps:

Check privileges to make sure the user has permission to perform any transitions on the item. This is based on the item itself (for example, whether the user is the owner of the item); and the role, group, and user privileges granted to the user.
CAUTION:
Privileges are additive and can be indifferent to role-based transition restrictions. For more information, see Associating Multiple Roles with a User.
If the user has permission to transition the item, determine which transitions are available. This is primarily based on the state the item is in.
Determine whether each available transition has any restrictions on it. The restrictions can be based on role, item type, rule, and group (set in SBM Application Administrator).

This means that both step 1 and step 3 must pass before a user can see the transition. For example, consider the following scenario:

An application workflow has five states: New, Assigned, In Progress, Tested, and Closed; and five transitions: Submit, Assign, Start Work, Test, and Close.
All roles have privileges to view, update, and transition the Assigned, In Progress, and Closed states.
The Assign, Start Work, and Test transitions have no restrictions on them.
Only the "Tester" role can execute the Close transition, which moves the workflow from the Tested state to the Closed state. To implement this, the Closed state has "Tester" has the owner. This is specified on the Restrict by Role tab of the transition Property Editor.
The "Manager" role can only see the states it owns. This is specified in the roles editor, where "Transition Item if Owner" is the only transition privilege selected in the Items category. The "Developer" and "Tester" roles have the "Transition All Items" privilege.
Amy is associated with the "Manager" role. Emily is associated with the "Developer" role. John is associated with the "Tester" role. Eric is associated with all three roles.

The following use cases describe how access to transitions is granted:

Amy submits an item. No owner is specified for the New state. Because she is not the explicit owner of the state, instead of seeing the New state form with the Assign transition button, she sees a message saying "The item was successfully submitted."
Emily submits an item. Because the "Developer" role can transition all items, and because there is no New state owner, she sees the New state form with the Assign transition button. The same is true for the Assigned, In Progress, and Tested states and their associated transition buttons. However, the Closed state has "Tester" as the owner, so Emily does not see the Closed state form with the Close transition button. Instead, she sees a message saying "The item was successfully transitioned, or, if she has "update" privileges, she sees the state form with only an Update button on it.
John submits an item. Because the "Tester" role can transition all items, and because this role is the owner of the Closed state, he can see all state forms and execute all transitions.
Eric submits an item. Because he is associated with all roles and has the "Transition All Items" privilege, he can see all state forms and execute all transitions. The "Tester" role and its associated privileges and transition restrictions takes precedence over the more limited "Manager" and "Developer" roles.