Executing a Workflow
A step-by-step guide to executing a verification workflow and interpreting the results.
Overview
Executing a workflow is the core action in the FrankieOne platform. It takes an entityId
and runs it through a pre-configured series of checks (e.g., KYC, AML, IDV) to return a final verification status. This is the central mechanism for assessing risk and making onboarding decisions.
This guide covers the primary methods for executing a workflow and provides a high-level overview of how to handle the response.
Workflow Execution Patterns
There are two primary patterns for executing a workflow, depending on whether the individual already exists in your system.
1. Execute for an Existing Entity
This is the most common pattern. If you have already created an individual
and have their entityId
, you can execute a workflow against them at any time.
Use Cases:
- Running an initial KYC check after a user has signed up.
- Re-running a workflow after a user has updated their information.
- Performing periodic or event-driven reviews.
1. You Initiate the Workflow
You send a POST
request to the /execute
endpoint for a specific entity and workflow. This tells FrankieOne to begin the verification process.
2. Create and Execute for a New Entity
For new user onboarding, you can create the individual
entity and execute a workflow in a single API call. This is a highly efficient pattern that streamlines the initial verification process.
Use Cases:
- Onboarding a new customer who has just filled out a registration form.
- Verifying a user for the first time as part of a single, atomic transaction.
Implementation Guide
Prerequisites
Before executing a workflow, ensure you have:
- The
entityId
for the individual (unless using the “Create and Execute” pattern). - The
serviceName
of the Service Profile they are being assessed against (e.g.,KYC
). - The
workflowName
of the specific workflow you want to run (e.g.,Standard-KYC-AU
).
Step 1: Execute the Workflow
Choose the endpoint that matches your execution pattern.
For an Existing Entity:
Make a POST
request to the execute
endpoint, including the entityId
, serviceName
, and workflowName
in the path.
For a New Entity:
Make a POST
request to the new
execute endpoint, providing the individual
’s data in the request body.
Step 2: Interpret the High-Level Response
The API response will contain the workflowResult
object. For automated decision-making, you should parse these key top-level fields:
workflowExecutionState
: This must beCOMPLETED
. If it showsERROR
orTIMEOUT
, the workflow did not finish, and thestatus
should not be trusted.status
: This is the most important field. The most common values arePASS
,FAIL
, orREVIEW
. This field incorporates any manual overrides and represents the final, authoritative state.result
: This represents the original, automated outcome of the workflow before any manual changes. It’s useful for auditing.
Advanced: Asynchronous Execution
For workflows that may take longer to complete, you can request asynchronous execution by including the X-Frankie-Background: 1
header.
- The API will immediately respond with a
202 Accepted
status and arequestId
. - The workflow will continue to process in the background.
- You will be notified of the final result via a configured webhook.
This pattern is useful for preventing timeouts in client-facing applications.
Advanced: Overriding a Result
In some cases, a compliance officer may need to manually override a workflow’s automated result. This is achieved by making a PATCH
request to the specific workflow execution.
Provide the new status
and an optional comment
to explain the reason for the change. This action is fully audited.
Next Steps
Once you have successfully executed a workflow, the next critical step is to parse the rich workflowResult
object to understand the outcome of every check.
For a complete breakdown of every field in the response, refer to our detailed guide: Interpreting Workflow Results.