Building a verification workflow

A workflow is the set of checks a person completes and what happens with each result. Build one, publish it, and avoid mistakes that make it misbehave.

A workflow is where you define which checks a person goes through - ID document, liveness, face match, AML, and so on - and what happens with each result. Every verification session runs against a workflow.

#Where to build one

In the Business Console, open the application you want to work in, then go to Identity verification → Workflows in the sidebar and click New workflow. Choose the category (KYC for people, KYB for companies), how to build it (Simple or Advanced), and a template, then review and Create draft.

Each application, and each environment (Live or Sandbox), has its own set of workflows; a workflow can be copied to another application from its row menu. Make sure you're in the right application and environment first - building a workflow in the wrong one is the most common reason a change appears to have had no effect.

#Two ways to build

1. Simple mode

   Pick a template - such as KYC, Age verification, Re-authentication, or address verification - and toggle the checks you want on or off (liveness, face match, AML, NFC, phone, email, and more). This is the fastest way to get a standard flow running. Hover a workflow's row to copy its reusable verification link.

2. Advanced mode

   Use the visual graph builder to add conditional branches: route people by country, document type, age, or a check's result, and send different outcomes down different paths. Use this when you need logic beyond "run these checks in order." Where available, the By country templates start an Advanced workflow from the rules a country requires; see compliance by country.

3. Publish

   Publishing turns your draft into a live version. A published version is read-only: to change it, press Edit workflow to start a new draft, then publish that. Version history lists earlier versions and can restore one. Sessions already in progress keep using the version they started with, so publishing changes never disrupts someone mid-flow.

#Bank and location checks

Where enabled for your application, add Bank verification or Location verification as workflow steps. Bank settings cover the connection, identity match, risk signals, outcomes and collected data; available countries and financial data depend on the provider and enabled capabilities. Location settings control accuracy, freshness, permitted areas and the actions for missing permission, unavailable location or a rule mismatch. Review the returned evidence in the session’s Bank or Location section. A visible configuration does not guarantee that every provider or client supports the check.

#Order matters more than it looks

Because a step configured to decline stops the workflow, the order of your steps decides both what a user experiences and what you pay. A cheap risk check in front of an expensive bundle filters traffic before you pay for the expensive part.

The full picture is in decision rules and thresholds - it's the article to read after this one, because a workflow's steps are only half of its behaviour.

#Every module you can add

Each one you enable adds to the price of a completed session, and your monthly plan credit pays for them (on the Free plan it does not pay for phone verification). See what counts as a billable check before you switch several on.

#Finding your workflow ID

Each workflow has a unique ID, shown on the Workflows page in the console. You'll need it if you're creating sessions through the API - see ways to integrate.

#Controlling what happens when a check fails

By default, a failed check declines the session and the person is told at the end that verification didn't succeed - you can see exactly which check failed and why in the session's details. In Advanced mode you route each outcome yourself: send it to Declined, or to In review so a teammate makes the final call.

See what each session status means for what each outcome looks like, and letting someone try a verification again if you want to let a person redo just the step that failed.

#Things that make a workflow behave unexpectedly

In the order they actually happen:

1. You edited a different workflow, or a different application's copy of it. Check the workflow ID against the one your sessions use.
2. The draft was never published. A saved draft is not a live version.
3. You're testing with an old session. Sessions keep their creation-time configuration. Create a new one.
4. A document type is allowed but no subtype is selected - which matches nothing rather than everything. See supported documents and countries.
5. An earlier step declined and stopped the flow, so the step you're testing never ran.
6. A copied workflow didn't carry everything over. After duplicating a workflow, check the steps and rules you care about rather than assuming a clean copy.

#Test it before real users see it

Switch the console to Sandbox with the pill under your application's name, create a sandbox API key there, and use it. Every check is mocked, nothing is billed, and you can force any outcome you want. Sandbox keeps its own data, keys, webhooks and lists, apart from Live.

testing in sandbox

#Next steps

• Set what each result does: decision rules and thresholds
• Match the flow to your brand: customizing branding and the verification experience
• Launch sessions with no code, or automate them via the API: ways to integrate
• Full technical reference: Workflows