App Generator: Status and transitions

The design of the workflow is the second central component of an individual application. The workflow defines which steps a form or an application element has to go through. In addition to the pure process, the workflow restricts editing rights and configures at which transition Q.wiki should send a notification.

Important for the successful maintenance of the workflow is an understanding of statuses and transitions and how they are related:

• A status is the state that an element is in. Examples include New, Under Review, For Review by Staff, or Released. It is recommended to use an adjective or state description to denote the status.
• Transitions, on the other hand, are the actions that a user can perform to move an item from its current state to another state. Transitions should be active, i.e., formulated as a verb, whenever possible. Examples are submit request, confirm request or approve costs.

For a status, in addition to the name, it is relevant which users are allowed to edit the page in this status.

• In the form definition, rights can be further detailed for each form item - see Rights and Visibilities.
• Without the right defined in the status to edit the page, the user is only able to read the page. 
• For each status, the editability can be defined differently. 
  • For example, in the status New, every user should be allowed to edit a request, but in the status Release by manager, only the manager and the management should be allowed to edit the request.

When defining the workflow, it is recommended to first create the statuses and then link them to transitions. Two lists are displayed for each status:

• The incoming transitions - Inputs - are automatically determined and displayed based on the configuration.
• The outgoing transitions - Outputs - are displayed after they have been added.

A transition has various settings - see Create and configure transitions. The two most relevant from the process point of view are:

• The right to execute the transition. Only authorized users will see this transition.
  • The right to execute a transition is detached from the editing right in the target state. These rights are maintained in two different places and have no binding to each other. So in many workflows, a user will have the right to transition an item from the current state to the next state, but will not subsequently have the right to continue editing the page.
• The configuration of users to be notified.

A workflow does not have to be linear. By freely defining transitions between the statuses, complex workflows and jumps back are possible.

Translated with www.DeepL.com/Translator (free version)