Consult the correct documentation:
This documentation refers to the new process editor of the platform. If you are using the current process editor, access Configure activities and flows.
LANGUAGE
Speaking of flows... 
Flows are the mechanisms that define to which activity the request should go. They determine the path that the request will take as the stages or activities are completed.
Flows are represented by arrows that indicate the direction of movement, which can be either a one-way path – from the source activity to the target activity – or a return – from the target activity back to the source activity.
The types of flows available for use are detailed below.
Common flow
The common flow is the standard flow for moving the request between activities. It is the flow used most often, allowing the request to move from one activity to another without the possibility of returning to the previous activity.
The common flow is represented by an arrow that indicates the direction in which the request will move.
Automatic flow
The automatic flow moves the request automatically to the target activity after reaching the deadline of the source activity, and it is not yet fulfilled; that is, the request has not yet moved to the next step.
A clock in the middle of the arrow pointing the direction to which the request will move represents the automatic flow.
For the automatic flow to work correctly, it is required that:
- the source activity have a defined deadline;
- a scheduling of the type Automatic flow exist in the Task scheduler, determining a time interval from which requests that are stalled in activities with automatic flow are checked and moved.
Notes:
→ Since the automatic flow only moves the request after the deadline of the source activity is reached, you must also configure a common flow in the source activity to allow conventional movement; that is, to allow the request to move before reaching the deadline for completion of the source activity.
→ While running an automatic flow, no authenticated user is performing the movement. Therefore, events that use the authenticated user through APIs must consider this fact to avoid inconsistencies in execution.
EXAMPLE
In a process of Opening a support ticket, the requester has a defined deadline to evaluate the proposed solution and respond positively or negatively; that is, to notify whether the solution met their needs or not. If they do not respond within this deadline, the ticket automatically closes. In this case, we recommended using an automatic flow between the Evaluate solution step – which is the responsibility of the requester – and the Close ticket step, which is the end of the process. Thus, it prevents many pending tickets from remaining open due to lack of response from requesters.
Return flow
The return flow allows the request to go back to the source activity.
When the request moves from the source activity to the target activity through a flow that allows return, upon completing the target activity, you can return the request to the previous activity; that is, the originating one.
The person responsible for receiving the request is the same person who previously completed the source activity; that is, who moved it to the target activity last.
The return flow is represented by an arrow starting from the target activity and pointing to the source activity.
You can also configure automatic flows to allow returns. In this case, its representation will also have a clock in the middle of the arrow, as follows: 
.
Note:
You can only use the return flow in the version of the process in which the request is located during the movement. Therefore, if you convert the request to another version of the process, in its first movement after the conversion, it cannot return to the previous activity, since there will be a movement that represents the conversion and, therefore, it will lose the possibility of immediate return.
EXAMPLE
In a vacation request process, when sending the request for the manager's approval, they may request some adjustment to the start date or the number of days requested. In this case, we recommend using the return flow to allow the manager to return the request to the employee to adjust the data and send the request for approval again. This way, it avoids the manager having to reject the request and the employee having to open a new one with the requested adjustments.
Flow messages
Flows have predefined messages displayed when you move the request from the source activity to the target activity. However, you can customize these messages in accordance with the process or stage.
EXAMPLE
In a technical support ticket opening process, the movement message from Start to Second stage can be defined as "Your ticket has been successfully opened!" instead of keeping the default message "Request 999 successfully initiated.".
Configure flow
01. In the process diagram, click on the Flow component 
you want to configure.
The available settings are displayed on the right side.
02. In the Flow type tab, define the general information of the flow.
Flow type
Type of flow to be used between the two activities or stages of the process. The available options are:
- Common flow: when selected, it determines that the flow is common, meaning that you need to move the request from the source activity to the target activity.
Automatic flow: when selected, it determines that the flow is automatic, meaning the request automatically moves from the source activity to the target activity when the deadline for completing the source activity expires.
Important!
For the automatic flow to work correctly, you need to create a schedule of the type Automatic flow in the Task scheduler.
Common flow title
Name for identifying the flow. This name is displayed above the flow in the process diagram.
EXAMPLE OF USE
In a Payment Request process, you could call the flow between the Request payment stage and the Manager Approval stage Send for approval.
Return flow
When activated, it determines that it is allowed to return the request from the target activity to the source activity.
Return flow title
Name for identifying the return flow. This name is displayed below the flow in the process diagram.
EXAMPLE
In a Vacation Request process, you could call the return flow between the Manager Approval stage and the Request vacation stage Adjust dates.
03. Click on the Flow Message tab to customize the message displayed when the request goes through this flow.
The flow message is displayed upon completing the movement of the request from the source activity to the target activity. These messages already exist by default; however, you can customize them if desired.
Tip!
You can insert the request number anywhere in the message, whether in the title, description, or link text. To do this:
01. Insert the character @.
02. Click request number.
03. Upon clicking, the request number is replaced by [request:id].
→ When the message is displayed, instead of @[request:id], the actual request number is shown.
CLICK HERE TO SEE AN EXAMPLE OF A CUSTOMIZED MESSAGE
Title
Title of the request movement message. The title can have up to 70 characters. If no title is entered, the default will be displayed.
CLICK HERE TO SEE THE DEFAULT TITLE
Description
Message of request movement. The message can have up to 255 characters. If you do not enter a message, the default is displayed.
CLICK HERE TO SEE THE DEFAULT DESCRIPTION
Request link text
Text displayed in the link that allows access to the request. The text can have up to 70 characters. If you do not enter any text, the default is displayed.
CLICK HERE TO SEE THE DEFAULT LINK
04. Click Save draft – located on the right side of the top bar – to save the settings made in the Flow component.
05. In the displayed message, click Ok, I understand.
Attention!
This documentation is valid from the Voyager (2.0) update onwards. If you are using a previous update, it may contain information different from what you see on your platform.
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas