The modeler is divided into three main areas:
The drawing area, where the template picked will be drawn.
The palette, which contains the different workflow components as well as shortcuts to undo/redo, fit the whole diagram in the drawing area, and export the diagram as a SVG file.
The configuration panel, which adapts depending on the element selected in the diagram and allows to configure those elements.
On top of those three areas, three additional elements complete the modeler:
-
The context pad which appears when selecting an item in the drawing area.
It allows toAdd new elements directly after the selected items
Add comments
Delete the selected item
Change the type of the task or flow
The “DEPLOY” button at the top right which allows to deploy a new workflow version.
The “Expert mode” switch at the bottom of the screen which allows to access more settings and create even more advanced workflows, but at the cost of an increased complexity.
Note : the elements and capabilities described above are the ones in the Business plan. If you are using the foundation plan, the modeler will be restricted to fewer elements and capabilities.
In simple mode, elements that can be added in the diagram are the following:
Start event
End event
User task - Approve / Reject
User task - Review
Service task - Set status
Service task - Set metadata
Service task - Set tag
Service task - Send email
Service task - Create version
Exclusive gateways
Start event
Workflows should have a single start event. In the configuration panel, when selecting the start event, managers can define the list of candidate users - user who can start this workflow. The following settings can be configured in the configuration panel:
|
|
End event
Signals the end of the workflow. No configuration is available or required on the end events. |
User task - Approve / Reject
The Approve / Reject task is a user task, meaning that it requires an action from a user to be accomplished.
It has two possible actions: Approve or Reject. The following settings can be configured in the configuration panel:
|
|
User task - Review
The Review task is a user task, meaning that it requires an action from a user to be accomplished. It has a single possible action: Review The following settings can be configured in the configuration panel:
|
|
Service task - Set status
The “Set Status” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. It is usable only in workflows that are applicable to files. “Set status” tasks set a file status to one of the three existing statuses and impact the color marker next to the workflow icon of the file in Drive:
The following settings can be configured in the configuration panel:
|
|
Service task - Set metadata
The “Set metadata” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. It is usable only in workflows that are applicable to a single specific File Type. “Set metadata” tasks set one or multiple metadata of the file to the provided value(s). The following settings can be configured in the configuration panel:
|
|
Service task - Set tag
The “Set tag” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Set tag” tasks add and remove one or multiple tags to the file. The following settings can be configured in the configuration panel:
|
|
Service task - Create version
The “Create version” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required.
It is usable only in workflows that are applicable to files. “Create version” tasks saves the current version of the file and create a new one. No configuration is available or required on the "Create version" tasks. |
Service task - Rename file
The “Rename File” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Rename File” tasks rename the selected file by adding a prefix, adding a suffix, or replacing the name of the file. The following settings can be configured in the configuration panel:
|
|
Service task - Move file
The “Move File” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Move File” tasks move a file or folder toward a specified folder. The following settings can be configured in the configuration panel:
|
|
Service task - Create file
The “Create File” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Create File” tasks create a new file based on an existing file template and in the specified folder. The following settings can be configured in the configuration panel:
|
|
Service task - Create folder
The “Create Folder” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Create Folder” tasks create a new folder in the specified folder. The following settings can be configured in the configuration panel:
|
|
Service task - Send email
The “Send email” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Send email” tasks send a specific email to a defined list of recipients. The following settings can be configured in the configuration panel:
|
|
Service task - Script task
The “Script task” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “Script task” tasks behaviour is defined by the script entered in the "script" field. This script is developped in Javascript. The following settings can be configured in the configuration panel:
|
Service task - REST Call
The “REST Call” task is a service task, meaning that it is automatically executed in the background when reached, with no user action required. “REST Call” tasks send an API request using the REST . The following settings can be configured in the configuration panel:
|
Exclusive gateways
Exclusive gateways are used to offer multiple possible paths depending on specific conditions. The Gateway is exclusive, meaning that only a single path can be taken out of the Gateway. Conditions settings have to be defined in each of the flows leaving the Gateway, and not in the Gateway itself. The following settings can be configured in the configuration panel:
The default flow to take if none of the conditions are met can be defined by selecting the flow, clicking on the setting icon, and selecting “Default Flow”. |
|
Parallel gateways (Expert mode only)
Parallel gateways are used to execute multiple paths simultaneously. Parallel gateways do not allow to set conditions on the paths. No configuration is available or required on the "Create version" tasks. Note: the multiple paths leaving a parallel gateway have to be reunited through a second gateway for the workflow to work as expected. |
Warning: when using approval tasks, the result of the approval action is by default stored in the variable "pt4d_result". This results in a risk when using parallel gateways of erasing the result of approval tasks happening in parallel branches, and thus in breaking the expected behavior of the workflow. That is the reason why parallel gateways are available only in expert mode. To better understand this issue and how to avoid it, see the example below.
Example: let's take the example where we have three approval tasks in parallel, and then need to go in one branch if all are approved and in another if at least one of them is rejected.
If left with the default settings, this workflow will result in all three approval tasks storing their approval result in the variable "pt4d_result". That means that only the last action to be taken in chronological order will actually remain in memory and be tested when reaching the exclusive gateway.
For this to work properly, the following actions need to be taken:
- In expert mode, go in the form settings of "Approval 1".
- In the settings of the buttons field "btn_submit" rename the variable in which to store the result from "pt4d_result" to "pt4d_result_1".
- Repeat this operation for "Approval 2" and "Approval 3" by renaming the result variables respectively "pt4d_result_2" and "pt4d_result_3".
- Still in expert mode, in the conditioned flow "If all approved", edit the condition expression to: ${pt4d_result_1=='ok' && pt4d_result_2=='ok' && pt4d_result_3=='ok'}
- Set the other flow as the default path.
Inclusive gateways (Expert mode only)
Inclusive gateways are the middle ground between exclusive and parallel gateways. They allow to execute multiple paths at once like parallel gateways, but also to set a condition on each of those paths like exclusive gateways. This results in all the paths with their condition tested true to be executed in parallel. Conditions settings have to be defined in each of the flows leaving the Gateway, and not in the Gateway itself. The following settings can be configured in the configuration panel:
Note: just like a parallel gateway, the multiple paths leaving an inclusive gateway have to be reunited through a second gateway for the workflow to work as expected. Warning: the risk described previously when using approval tasks in parallel gateways is also applicable when using inclusive gateways. The solution to avoid it is also the same as with parallel gateways. |
|