Workflow Configuration
The configuration page includes the basic configuration of workflows, manual nodes and workflow parameters.
I. Basic Configuration
1. Notofication
When there is an exception in the workflow, notifications can be sent to the added users here and also to the owner of the workflow. If needed, you can also set to not receive the same error notification for X hours.
Workflow Owner
It defaults to the creator of the workflow and can be changed, with only one owner allowed.
Also notify other users
Apart from notifying the workflow owner, notifications can also be sent to other specified users.
Notificattion:
2. Operation Mode
For a workflow, it may be triggered by multiple records at the same time. For example, there is a workflow (triggered only when new records are added), and when 100 new pieces of data are added by importing an Excel file, the workflow will be triggered 100 times instantly. At this time, you can set the operation mode, parallel, sequential or serial.
Workflows that can be configured for operation mode
For workflows that are triggered when adding or deleting records
When you add data by importing an Excel file, the workflow is instantly triggered N times.
For workflows that are triggered by custom buttons
If you check multiple records and click the button, the workflow is triggered N times.
Only the three types of workflows mentioned above can be configured for operation mode, and other types of workflows are executed in a parallel mode and cannot be modified.
As for the operation mode of subflows and PBPs, it depends on the way it is configured in the [Subflow] node and the [Call PBP] node.
Parallel
Workflows in this mode are executed fast. This mode is suitable for workflows where the execution instances do not affect each other.
For example, in the Bug Management application, there are 19 bugs that have been fixed and users who submitted the bugs need to be notified for validation. You can check 19 bugs in bulk and click the “Validate” button to trigger the workflow to notify the users. These 19 records or workflows are not sequential. They do not affect each other and can be executed simultaneously. In this case, you can choose the [Parallel] mode.
In parallel mode: the records or workflows are not executed in order.
Sequential
Workflows in this mode are executed slowly. This mode is suitable for workflows where the execution instances affect each other and the workflows need to be executed sequentially.
For example, in the Apply For Items worksheet, after a new request is submitted, the workflow needs to check the free device from the inventory. If multiple members request to use the same device at the same time, it is necessary to consider the inventory. For example, there are 10 notebooks in stock, and 3 members request 5 copies each. If they submit the request at the same time, the inventory they get is 10, obviously there is a problem. These three request records cannot be executed at the same time. In this case you need to select the sequential mode, to execute the workflows in order.
In sequential mode:
If you check records one by one and click the button to trigger the workflow, the workflow is executed in the order of the checkboxes.
If you check all the records and click the button to trigger the workflow, the workflow is executed in the order of the record pages from top to bottom.
If the workflow is triggered by new records, it is executed in the order in which the new records are created.
When to start executing the next workflow
After the execution of the previous workflow is completed, the next workflow is started.
When the previous workflow stops abnormally, the next workflow is started.
When the previous workflow enters the [Delay] node, the next workflow is started.
When the previous workflow enters the [Approval] or [Fill in] node, the next workflow is started. Since the [Approval] or [Fill in] node may take time, the next workflow is started directly when the previous workflow reaches such a node.
When the previous workflow enters a subflow or a PBP, the time required is uncertain. You can choose from the following two ways:
If [Only when the subflow is executed will next node get started.] is checked, the batch workflows queued for execution will not wait for the subflow of a workflow to finish processing, and the next workflow will start directly once it enters the subflow.
If it is not checked, it will execute the subsequent nodes directly. After the current workflow is executed normally, the next workflow is started.
Serial
This mode ensures that the next workflow is executed only after the previous one is completed.
When to start executing the next workflow
The next workflow begins after the previous workflow has completed successfully, including the subwflows and PBPs.
The next workflow begins if the previous workflow is stopped due to an exception.
3. Data Format
On the workflow configuration page, you can set the display format for time fields in the workflow, which defaults to down to the minute.
System time fields include:
- Worksheet - Creation Time
- Worksheet - Approval - Start Time
- Worksheet - Approval - Node Start (valid within the approval block)
- Worksheet - Approval - Remaining Time (valid within the approval block)
- Workflow - Trigger Time
- Workflow Parameters - Date/Time Parameters
- [Operation] Node - Add or Subtract Time for Date - Output: Date + Time
The system's current time is always down to the second.
Mainly for:
- [Code Block] node
- [Operation] node
- Other nodes using time fields
4. Node Logs
You can enable node logs to view execution details of each node in the execution history if enabled. These logs are retained for 90 days.
If node logs are enabled, for a dynamic field, it will display the values at that time in the node's execution details.
If node logs are disabled, only the configuration information is displayed when viewing a node's execution details.
4. Initiator View
If the initiator of the workflow does not want the workflow to be displayed in [Submit] on the to-do page, he/she can disable [Initiator View] here.
When the initiator views the workflow on the to-do page, the workflow does not appear in [Submit].
5. Trigger other workflows
If there are nodes such as [Update Record], [Add Record], and [Delete Record] in the current workflow, the execution of these nodes may trigger other workflows.
Example: In workflow A, a new record is added to worksheet 1 through the [Add Record] node. The trigger node of workflow B is to trigger the workflow when there is a new record in worksheet 1. If a record is added to worksheet 1 through workflow A, which meets the trigger conditions of workflow B, in such case, you can decide whether to trigger workflow B through configuration.
Trigger allowed
It is allowed to trigger other workflows, however, if the current workflow and other workflows select the same worksheet in the trigger node, the trigger field must be specified in the trigger node of other workflows for the workflow to be triggered.
As shown below, you need to specify the trigger field for the triggered workflow. In the above example, workflow B must be triggered by the specified field.
If workflow A is button-triggered, you do not need to set the specified fields for workflow B. Only if workflow A is automatically triggered, workflow B is the only one that needs the specified fields.
Trigger specified workflow only
In the current workflow, if you modify a record in another worksheet, it will trigger X workflows related to it. Among these X workflows, you can choose to trigger a few of them in particular.
These workflows do not have to be in this application, but can also be in other applications.
Trigger not allowed
Any data processed automatically by this workflow does not trigger other workflows, even if changes to the data meet the trigger conditions of other workflows.
II. Set manual nodes
It is only valid for approval flows configured with the [Approval] node, and not for approval nodes in [Initiate Approval Flow].
1. Allow trigger to withdraw
If a workflow is triggered, the person who triggered the workflow can withdraw or urge it.
Withdraw
You can set that a workflow cannot be withdrawn by the trigger when some approval node passes.
If withdrawn, the workflow is stopped.
Urge
When the approver does not process for a long time, the triggers can click the button to remind and notify the approver to speed up the process.
How to withdraw/urge the workflow
Go to [To-do] > [Submit], click the target workflow to the details page, you will see the withdraw or urge button.
Application Admin can check in [History] to see if the workflow has been withdrawn.
If the workflow is withdrawn, the nodes that have been executed are still valid. For example, workflow A has a trigger node, an update record node and an approval node. When the workflow is triggered, the update record node is automatically executed, changing the value of the field from a to b, and then the approval node is executed. At this point, if the workflow is withdrawn, the approval does not continue, and b is not changed back to a.
2. Auto-approval Configuration
It is only valid for approval flows configured with the [Approval] node, and not for approval nodes in [Initiate Approval Flow].
1) Check the trigger and approver
If the trigger person of the workflow and the approver of the current approval node are the same person, if it is checked, the approval is automatically passed. If it is unchecked, the trigger person needs to approve again.
2) Auto-approve if the approver has already approved it
There are multiple approval nodes in the workflow, for example, Approval Node 1, Approval Node 2, Approval Node 3, and Approval Node 4.
If in Approval Node 1 and Approval Node 4, the same record is being approved, and the approver is the same person, then after Approval Node 3 passes, in Approval Node 4 , it can be automatically approved.
3) Auto-approve when the approver is empty
If in the approval node, it does not set the approver or the approver is invalid, it is automatically approved if checked.
4) Verify required fields
This is mainly for auto-approval of 1 and 2 above. If the current approval node is configured with required fields, whether it can still be auto-approved. If checked, it cannot auto-approve and must be approved again once. If unchecked, it can be auto-approved. It will always auto-approve when the approver is empty.
3. Notification nodes
You can set whether to send notifications to the initiators of the workflow. The configuration here applies to all [CC] and [Send Internal Notification] nodes in the workflow.
If a member triggers a workflow, there is a [CC] or [Send Internal Notification] node in the workflow:
If there is only the operator himself in the notification node, the node is skipped.
If there are other members added to the notification node, the node is executed normally, but no notification is sent to the operator.
III. Workflow Parameters
You can define a parameter object in a workflow, like a temporary field in the workflow. It can hold a field value, or the result of a calculation, or receive values passed from other workflows that are then referenced by other nodes. When the workflow ends, the parameter value is cleared and reset.
Parameter type
Text, Number, Date/Time, Members, and Department
Parameter name
The name must start with a letter and can contain numbers and underscores.
How to assign a value to a parameter
You can assign values to parameters in the workflow with the [Update Parameters] node.
Assign values to parameters in the subflow in the [Subflow] node.
You need to enter the subflow and set the parameters for the subflow before you can assign values to the parameters. The parameters automatically have initial values when the subflow is executed.
Have questions about this article？ Send us feedback