Within the template editor you can define every part of the flow that a request will follow: how it starts, what information is requested, who approves each stage, what dependencies must be met, what notifications are sent and what final action the platform will execute.
Below you will find a description of all configurable options:
1. Request start type
The start configuration is locatedonly in the first stageand determines how a request will begin. There are currently 2 start types:
1.1 Manual Start (Form)
This is the default mode for most templates. The request starts when a user selects the template and completes the initial form.
In this mode you can configure:
Who can start the request(see Permissions section).
Stage 1 form(visible, editable or required fields).
Initial notificationsassociated with this stage.
Considerations:
If you change the start from "Form" to "Platform event", all form configurations of the initial stage will be disabled.
If you go back from "Event" to "Form", you will need to reconfigure the fields, since they are not recovered.
1.2 Automatic Start (Platform event)
Available only for templates of typeFlexible.
When you select "Platform event", the request will start automatically when the selected event occurs.
Available events include:
When a job is created for a Collaborator.It is triggered when a job is created and assigned to a collaborator.
- When a Collaborator's job is completed:It is triggered when a job is completed. If it has an end date, it is triggered when the process starts, not on the end date.
- When a Collaborator's job is modified.It is triggered when a field of the Collaborator's job is modified. You can filter so that it only runs if any combination of these fields changes:
2. Form
In each stage (except the initial stage if the template starts by event), you can define the information fields that must be completed.
2.1 Available field types
Text
Number
Date
File
Dropdown list
Multiple selection
-
Fields specific to the workflow type
Onboarding: legal name, position, document type, etc.
Movement: salary, area, position, supervisor, etc.
Offboarding: end date, offboarding type, reason, etc.
2.2 Field states
Each field can be configured as:
Read-only→ it is displayed but cannot be edited.
Editable - optional→ the user can modify it if needed.
Editable - required→ the user must complete it to proceed.
2.3 Required fields by workflow type
Some workflow types require minimum fields. Examples:
Onboarding → Document type, Country, Basic collaborator data.
Offboarding → End date and reason.
Movement → The fields that will be modified.
You can use the option"Add required fields"to automatically include all minimum fields.
2.4 Important considerations:
If you delete a required field without adding it back, the template will be in stateIncomplete.
If the template already has requests in progress, changing or deleting fields can alter the behavior of those requests.
→ In these cases it is recommendedduplicate the templateand then deactivate the original.Comments entered in forms will be visible from theView Detailsview of the request.
3. Permissions and approvers
Each stage can have different permission rules about who can start it, approve it, return it, or reject it.
3.1 Who can start or approve requests?
Depending on the template type, you will have these options available:
Area and Position
List of specific users
Request administrators
All collaborators
User profile
Onboarding coordinator (Pre-entry only)
New collaborator via personal email (Pre-entry only)
3.2 Substitutes (Alternate approver)
If the main approver is absent (vacation or leave):
The substituteautomatically assumesthe requests.
They can only manage requests of the original approver.
They cannot see other requests in the process.
3.3 Other Stage configurations
Allow viewing and operating requests started by other users:Everyone will be able to see others' requests, but will only be able to operate the first stage if they meet the area/position requirements defined in the initial stage.
Useful for flows in rotating areas or collaborative teams.Limit areas according to the profile of the approver of this stage:We recommend keeping it active, as it enforces the area limits of the user completing the stage. When deactivated, the user will see users from areas to which they are limited.
3.4 Other template settings
Allow request report download for users who respond to this stage:You can decide whether only those who respond to a stage can download its PDF report.
Automatic Notifications:The requester will receive a notification when their request is approved or rejected. Additionally, we will notify all stage owners who must respond. If there are multiple approvers in the permissions, each will receive the notification.
4. Dependencies between stages
Dependencies determine when each stage starts.
They appear only from thesecond stageonwards.
Available states that can trigger the start:
Approved
Rejected
Returned
Error
Important behaviors:
If you delete a stage, dependencies are reorganized automatically to maintain consistency.
If you duplicate a stage, the new stage will be inserted immediately after with correct dependencies according to its position.
5. Notifications
You can use automatic notifications, manual notifications per stage, or combinations according to your needs.
5.1 Automatic Notifications
When enabled:
The requester receives notifications when their request advances, is rejected or is returned.
Approvers receive notifications when they must act on a stage.
Automatic notifications include:
Email
Push notifications on mobile devices
Limitations:
Notifications will be sentto all approversdefined in the Permissions tab.
→ If you want to send notifications only to certain users, you must disable automatic ones and use only manual notifications.
5.2 Custom Manual Notifications
In each stage you can add your own notifications, with full control over:
-
State that triggers the notification:
Requested
Waiting
Rejected
Returned
Error
-
Recipients:
Manual email
Requester
Stage owner
Supervisor of the affected collaborator
Email subject and message
Dynamic variables
Considerations:
If you configure a notification with non-existent recipients or without a subject, the template will be in stateError.
Manual notifications are sent even if automatic ones are disabled.
6. Duplicate stages
You can duplicate any stage to speed up flow creation.
Behaviors:
If you duplicate the first stage, the new one will become stage 2.
If you duplicate the last stage, the new one will be placed at the end.
-
The duplicated stage inherits:
Name
Form
Approvers
Dependencies
Notifications
Considerations:
Always review dependencies and permissions after duplicating.
Duplicating stagesdoes not duplicate trigger actions.
7. Trigger (final stage)
The final stage executes the flow's final operation.
The available action depends on the template type.
7.1 Onboarding templates
You can enable the optionCreate user automatically, which will generate Buk access for the new collaborator.
7.2 Flexible templates
For an automation, you can selectoneof the following actions:
Generate document
Create pending task
Add participant to free survey
Request assets (only in onboarding flows)
Enroll in course
Send HTTP Request
for a manual request, you will also find other actions:
Assign an earning
Assign an informational item
Assign a deduction
Assign a contribution
Important considerations:
Currently the platform only allowsone action per Flexible template.
If you need multiple actions:
→ Duplicate the template and configure additional actions in each one.-
Each action requires:
Corresponding contracted module
Specific permission enabled for the administrator
Action fields can be edited later in the request (in the case of pending tasks).
7.3 Offboarding templates
In offboarding templates, the final stage allows executing actions associated with closing the collaborator's cycle.
These actions are usually used to manage exit administrative processes, internal coordination, or integrations with external systems, depending on contracted modules and enabled permissions.
7.4 Movement templates
In movement templates, the final stage executes actions associated with changes in the collaborator's employment information, such as changes to position, area, or other contractual conditions.
Allows accompanying these changes with necessary administrative processes or integrations.
7.5 Pre-entry templates
In pre-entry templates, the final stage is used to prepare the collaborator's onboarding before their start date.
It is intended to advance internal procedures, coordination between areas, and pre-onboarding configurations.
7.6 Search templates
In search templates, the final stage allows executing actions once the process associated with the search is completed.
It is mainly used for the operational closure of the process and its internal or external follow-up.
7.7 General trigger limitations
You cannot configure dependencies in the final stage.
The final stage always executes when the entire request is fully approved.
If the template starts by event, the final stage will still exist but without an initial form.
🤖 This article was translated using artificial intelligence. View original article.