The modeler is divided into three main areas: 

  1. The drawing area, where the template picked will be drawn.

  2. 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.

  3. 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 to 

    • Add 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:


  • Candidate users: list of users or groups to which the task is assigned.

    If the workflow applies to files, it can be defined to be started by all users with reader and/or writer permissions on any file within the scope of the workflow.

    At least one candidate user is required to be able to deploy the workflow.


 

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:

  • Candidate users: list of users or groups to which the task is assigned.
    At least once candidate user is required to be able to deploy the workflow.
    It can be defined to be started by:

    • All users with reader and/or writer permissions on the file.

    • Specific users and groups.

 

  • Deadline: the numbers of days users have to complete the task from the moment it has been assigned to them.
    This parameter can be left empty if there is no deadline


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:

  • Candidate users: list of users or groups to which the task is assigned.
    At least once candidate user is required to be able to deploy the workflow.
    It can be defined to be started by:

    • All users with reader and/or writer permissions on the file.

    • Specific users and groups.

 

  • Deadline: the numbers of days users have to complete the task from the moment it has been assigned to them.
    This parameter can be left empty if there is no deadline

 


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: 

  • Pending approval 

  • Approved             

  • Rejected               


The following settings can be configured in the configuration panel:

  • Status: select the status to apply to the file. 



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:

  • Metadata: the list of metadata to set with the selected values. A row can be added by clicking on the “+”, and it can be removed by clicking on the “x” next to it.



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:

  • File Id: the ID of the file to add or remove tags to.
    In workflows applicable to files, this field is populated by default with the ID of the file the workflow was started on.

  • Tags to be added: the list of tags to add to the file.

  • Replace existing tags: if checked, all existing tags will be deleted before adding the new ones.

  • Tags to be deleted: the list of tags to remove from the file.

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:

  • File Id: the ID of the file to rename.
    In workflows applicable to files, this field is populated by default with the ID of the file the workflow was started on.

  • Select Type: select if the value provided should be added as a prefix, as a suffix, or replace completely the existing name.

  • Value: the value that will be prefixed to, suffixed to, or replacing the current name.


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:

  • File Id: the ID of the file to move.
    In workflows applicable to files, this field is populated by default with the ID of the file the workflow was started on.

  • Folder Id: the ID of the folder in which to move the file.

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:

  • Name: the name of the file to create

  • Parent Folder Id: the ID of the folder in which to create the file.

  • Template Id: the ID of the template file to copy in the specified folder.

  • Variable (optional): the name of the variable in which the id of the newly created file will be stored so that it can be reused later in the workflow.

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:

  • Name: the name of the folder to create

  • Parent Folder Id: the ID of the folder in which to create the new folder.

  • Variable (optional): the name of the variable in which the id of the newly created folder will be stored so that it can be reused later in the workflow.

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:

  • Recipients: the list of recipients to send the email to. If there are multiple of them, separate them with commas.

  • Subject: the email subject.

  • Body: the content of the email. It can be formatted in HTML.

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:

  • Script: the script defining the task behaviour.

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:

  • Method: HTTP Method - GET, POST, PUT or DELETE

  • Protocol: HTTP or HTTPS

  • Host: the host to which send the API request. 

  • URL: URL of the API service.

  • Request body: the body of the API request.

  • Add a header: add a header and a linked value.

  • Response variable: the variable in which the response will be stored.

  • Response code variable: the variable in which the response code will be stored.

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:

  • Condition: the condition to be filled to enter the flow. Conditions can be set on:

    • The previous user task result. In this case the previous user task has to be an approval task.

    • Any of the file metadata if the workflow is applicable to a specific File Type only.


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:

  1. In expert mode, go in the form settings of "Approval 1". 
  2. 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".
  3. Repeat this operation for "Approval 2" and "Approval 3" by renaming the result variables respectively "pt4d_result_2" and "pt4d_result_3".
  4. 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'}
  5. 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:

  • Condition: the condition to be filled to enter the flow. Conditions can be set on:

    • The previous user task result. In this case the previous user task has to be an approval task.

    • Any of the file metadata if the workflow is applicable to a specific File Type only.


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.