Last Modified: 13.10.2021
Creating state-driven workflow template
State-driven workflow template designing consists of 3 stages (after workflow template is configured and saved):
- Creating necessary statuses;
- Setup of actions inside each status and creating links between statuses;
- Setup of access permissions for status.
Creating statuses is performed at the main page for workflow template:
In the similar manner, all the required
For example, such statuses can be added into the template:
Setup of actions inside each status and creating links between statuses
After creating all the statuses, configure operations and actions (subprocesses), executed in each status, as well as create links between statuses.
The following is configured for each
- Command action allow user to launch subprocess manually. External control element used to launch a command depends on the workflow start location and element type. The command is used, for example, to define how a workflow must be executed; or as subprocess to be executed under specific conditions.
Action is similar to Execution pause action for a sequential workflow template.
- allows to
This action is convenient when some actions must be executed without employee participation
execution of subprocess for the handler- specified time period.
- State Entry Handler - separate sequential workflow. Always executed automatically when entering into this status.
- State Exit Handler - separate sequential workflow. Always executed automatically when
For example, sending a message notifying the process exited from current status.
the current status.
Status access permission setup
By default, workflow uses access permissions for an element. However, each status requires additional access permissions that will be added to element permissions in this status specifically. Below is the example for access permission setup for an element and specific status based on lists.
Indicate the following access permissions in the list settings: Employees = add; Author = read. After such setup, the employee can add list element and view only his own, but cannot view current workflow status at the corresponding tab upon opening list detail view.
Note: The main point is to highlight that access permissions for a list and for a workflow - are two different sets of permissions. Accordingly, list rules (iblocks) they do not "recognize" such user type as Author (this terminology is used only for workflows).
Inside the required status settings, indicate that Author has read level access permissions. In this case, workflow access permissions will be added to list access permissions and Author entity will match with enduser and its access permissions in the list. After such setup, user will be able to view corresponding workflow status.
General process overview
When reaching first status, executes State Entry Handler, if available. After executing all internal status actions, workflow transitions into standby mode. To continue executing the process, use the subprocesses Delay Execution and Command.
Note: when State Entry Handler contains added transition to another status that interrupts execution of current status, workflow executes State Exit Handler after it. In this case, subprocesses Delay Execution and Command will be skipped.
When the status is not final, transition from one status to another (creating links) via the action
Action allows moving workflow into another status.
, which must be located inside subprocess aimed at such transition. Upon exiting from such status, automatically executes subprocess State Exit Handler, if it was created.