The main concepts that are used to design a workflow are listed below:
A workflow node is a “step” of the workflow model. The node holds a set of configurable properties that define what the workflow engine should do at this step. For instance, it can create a task for someone, send some notifications, update some document properties.
A graph is the definition of a workflow process. It tells the server what should happen first, how execution is orchestrated, which nodes are orchestrate, etc. The graph has a start node, and one or multiple end nodes and between them a set of nodes linked by transitions.
A task is a persisted object that represents what a workflow instance expects from a user or a group of users. They are expected to give some information through a form and click on a button (like Accept, Reject, Confirm, Notify, Transform, etc.). A task usually has one or several assignees, a title, a directive and an expected date of achievement. A task is either to be done or done. A task is created by a node for which the property of task creation has been activated. The task assignees can be specified directly in the task definition or can be dynamically computed.
As we said before, the process, defined by its graph, is the orchestrated execution of nodes. It is very often necessary to have access to some data all along the life of the process: for example an action on a node needs some information captured earlier in the process execution. For that reason, the workflow engine offers a persistence system through the "variables". There are two types of variables:
- Node variables, defined on a node and accessible on the node scope,
- Workflow variables, defined at workflow level, and accessible from any node.
A variable has a type: string, float, blob, etc. So a variable can be a date picked up in a calendar, a file, a constrained value, …
A form and submission buttons can be bound to a task generated at a given node. The form helps capturing data from the user and set it on variables (workflow or local node).
When a task is assigned to someone, you can configure the node to send a notification via email to the assignee(s), and author the content of the email yourself, including HTML formatting. Note that when a task is assigned to a group, the prefix "
group:" must be used in front of the group name in the task assignee if you need to send a notification mail to each of the group members.
The Automation module is used to express what the engine does when going through each node. Workflow engine handles several kinds of automation chain:
- Node input: executed before entering a node (and if this node is of type task, before the task is created),
- Node output: executed just after having gone through a node,
- Transition chain: executed when the workflow engine goes through a transition condition one is evaluated to true.
- Escalation rule (available since 5.7.2): executed when the system is awaiting for a user to complete an action, depending on a condition. For example when the user has not completed the task before its due date.
Depending on the implemented workflows, users may receive many tasks that they need to process. Those tasks can be grouped for presentation to the users in "queues". A queue can be functionally defined as a set of tasks assigned to a user or a group of users. Generally, a queue allows to do bulk task processing. A user can have access to several queues. Technically, we will see that queues are implemented in Nuxeo using content views.
Since 5.7.2, a workflow can call another workflow and pass hard-coded or computed variables to it.
An escalation rule is a rule that allows the execution of an automation chain depending on a condition. A scheduler checks the condition regularly and executes the chain if the condition is evaluated to true. Escalation rules only apply to nodes awaiting for a user action to be executed.