Permission assignment for executing transitions

If permissions have been defined on a node for a workflow, the individual steps of this workflow are displayed in the bottom part of the “Workflow permissions” tab. The permissions for executing the workflow can be defined in detail in this area for each step of the process.

Permissions for switching the workflow to another workflow state defined at this point overwrite the permissions defined for this workflow by the template developer.

To assign these permissions a workflow is first selected in the upper table. All steps belonging to this workflow are now shown in the bottom table:

Permissions for forwarding workflows

Special permissions for the execution of a workflow

All transitions of a workflow are displayed in the table, in the order of their creation. The required workflow must be marked in the top part of the tab first.

The “Transition” column contains the respective name of the transition, the “Authorized” column shows the users who may currently perform the transition. These are those configured using the permissions definition on this transition under Fixed permissions.

Special permissions: If the checkbox is selected, the permissions assigned in the workflow for this transition are ignored on this node. Only the users and groups defined in the respective special permission are “authorized” to execute the transition.           
If the checkbox is deactivated, the permissions for executing the transition defined by the template developer for this workflow are evaluated.

The persons authorized to execute special permissions do not have to be identical to the users or groups who are authorized to start the workflow.

The figure shows the assignment of special permissions with the help of the standard “Request release” workflow. The following steps must be run through to execute the whole workflow (see Releasing objects (standard sequence)):

1. The workflow must be started if an object has been changed, for example, a page of the Page Store. No special permissions have been defined for this. Therefore, the persons for whom starting the workflow was “authorized” (top table) are authorized on the current object.
2. In the next step the release is requested. Permissions were not defined (on this object) for this transition either. Therefore, the permissions specified by the template developer for this workflow transition are evaluated.
3. In the next step the changes to the object must be checked. This transition (on the current object) should only be allowed to be executed by the “Chief Editor” group. The permissions defined in the workflow are therefore switched off (for the current object).
4. After the changes have been checked the release can be “approved” or there can be “no release”. This decision (on the current object) should also only be allowed to be taken by the “Chief Editor” group.
5. If there was “no release”, the change to the object must be re-“edited”. As special permissions have not been defined for this transition the permissions from the workflow are again evaluated.
6. A release can then be requested again.