Workflow Builder
Introduction
The creation of the Workflow Builder tool aims to save time and money by avoiding queries that would be rejected early in the process. It also empowers users to design their desired conditional validation flow in their preferred sequence. The Workflow replaces the well-known Query Template, serving as the template/set of necessary rules and services that define what will be validated in our treadmill.
Note: this tool is only available for global client accounts.
Create a workflow
Taking into consideration that the Trust Platform account is a global account, meaning the workflow flag is enabled in the client, to initiate the workflow creation process, the user will click on the "Tools" menu and then select the "Workflow Builder" submenu.
Upon accessing the workflow screen, a list of all previously created workflows will be visible. If there are no workflows yet or if a new one needs to be created, start by clicking on "Create Workflow" to define the segmentation type (currently available only for People validation) and assign a name.
Important: when a global account is created, a default KYB workflow will automatically be generated, specifically for company validation. At this initial stage, editing the default workflow isn't possible, and due to its default nature, execution will consistently require manual client review.
Unlike the Query Template used in the Brazil flow, the Workflow Builder is interconnected with rules and services. This means that to utilize a specific service, it's necessary to select a rule associated with it and then drag it to a validation step within the Workflow Builder. By doing so, the rule will dictate the service to be used, eliminating the need for separate steps for making these choices.
As previously mentioned, the Workflow creates a flow based on validation rules and steps, which can be either singular or conditional, depending on the client's business requirements.
Rules in a Single Step
If the client wishes to design a workflow with all rules and validations in a single step, they can do so. To achieve this, they need to drag all necessary rules into the initial step and define their validations. In other words, if the rule matches, the status to be displayed should be specified, and the same applies if the rule doesn't match.
Approved: if this status is selected and all rules within the same step are approved, the execution will have a final status of Approved.
Rejected: when this status is chosen, if any of the existing rules in the step are rejected, the execution will have a final status of Rejected.
Pending: if a rule with this status is selected and it results in a pending status, a manual action of either Approve or Reject is required for the rule. Only then can the execution attain its final status.
Note: that all rules within the same step will be validated, pending status doesn't halt validation, it merely affects the final execution status.
Warning: if this status is selected, an event/alert will be triggered through the Trust Platform, informing the client to pay attention to this execution. Unlike the Pending status, this won't halt the flow, the execution will continue performing queries and validations on services. If all other rules approve, the final status will be Approved. If any rule rejects, the final status will be Rejected, irrespective of the Alert rule.
Note: changing the status of this rule won't be possible.
Rules in Conditional Steps
To use the conditional flow, where a new service will only be queried if the previous step's validation is completed with a final status of Approved or Rejected, you need to add a new step and follow the same logic of drag-and-drop for necessary rules. To do this, click on the "New Step" option and create a conditional step for Rejected or Approved.
Depending on the outcome of the previous step, the workflow will follow the predetermined conditional flow. It's crucial to define Match statuses, as the Workflow relies on them to proceed. In the case of conditional steps:
Approved: if this status is selected within the rules, when the step has a final status of Approved, the next steps configured for this conditional can begin processing. The final execution status will only be determined after all steps are validated. If all steps are approved, the execution's final status will be Approved.
Rejected: when this status is selected within the rules, if any of the rules within a step are rejected, the workflow can only proceed with validations in the next steps if there's a Rejected conditional. Otherwise, the execution's final status would already be Rejected. However, with the conditional in place, the execution's final status will depend on the validations in the other steps.
Pending: in cases where a rule is set to Pending status and becomes pending, that specific step will wait for manual action to determine its final status and continue the defined flow. This manual action is to Approve or Reject the rule, not the entire execution. After this action, the subsequent steps will be carried out if there's a sequence in the flow. The execution's final status will only be determined after all steps are validated.
Warning: if this status is selected, an event/alert will be triggered through the Trust Platform, indicating that attention is required for this execution. Unlike the Pending status, this won't halt the flow, it will continue performing queries and validations on services. The next steps could be validated based on their configured conditionals, either Approved or Rejected. If all steps approve, the final execution status will be Approved. If any step rejects, the final status will be Rejected, regardless of the Alert rule.
Note: changing the status of this rule won't be possible.
Workflow settings
While still on the Workflow Builder screen, some configurations can be performed. You have the option to associate an Onboarding Template with this specific workflow, if it aligns with the client's need. By doing so, when creating onboarding links to be sent to end users, the steps and layout of the onboarding will match the client's needs and visual identity.
Important: if no Onboarding Template is associated with the Workflow, the created onboarding links will use the default CAF template. This means an initial basic flow with Caf. visual identity will be applied.
Another configuration that can be set on the same screen is the webhook. Under the settings tab, you can edit the Webhook field if you wish to receive notifications whenever a transaction is completed or enters a pending status.
Remember that any changes made require the user to click the save button in the Workflow Builder for the edits to take effect. After this action, all queries linked to this workflow will be affected.
On the initial Workflow Builder listing screen, besides having a list of all created workflows, you can also delete any of them from there or click to edit. Click the three dots on a workflow to perform this action.
Last updated
