The Transitions tab is used for creating a Transition Matrix for every message type, and setting email processing and notification rules for the users of each level of task hierarchy. 

The matrix is a table that has all states available. The left column represent initial (From) states, the first column - destination (To) states. If you check an item, it means that transitions for given message types are permitted from initial state to destination state. 

For example, the following matrix for message type resolve means "Resolve is transition from new or processing state to resolved state". 

You can select possible actions for users of available status for each message type. You can use the dropdown list in the header of the table columns to change the values of all elements in the column. The dropdown list at the beginning of a row allows you to change the values of all elements in that row. The dropdown list in the upper left-hand corner allows you to change the values of all elements in the table. 

Click the Save button to save the modified transition matrix.

If you don't have access rights to the parent task of the workflow, you can't change transitions for higher level user groups. But you can create your own (lower-level)user statuses and expand the workflow for it. This is done so you can add a new user status to the tracking process. 

You can define a mixed behaviors scheme: 

You can have one workflow status where the All items are selected because you prefer that every one can attend a task and solve it (this is a free attention mode). Maybe your testing team work jointly, where one is the handler but every one can work on a task and move it to another state (for example send it to the development team because a bug has been detected). 

You can have another workflow status where the Handler items are selected because you prefer that only one (the handler) can attend a task and solve it (this is a restricted attention mode). Maybe in your development team the members work individually, and the handler of a task is the only one that can work on it, and the only one that can move it to another state (for example send it to the testing team when a bug was implemented and now the project has to be tested).