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.