Persona Help Center
Branching steps in the Flow Editor let you define conditional routing within an Inquiry. Instead of every user following the same path, you can send different users down different routes based on the data available at that point in the flow.
How routes work
A branching step contains one or more routes. Routes are evaluated in order — the first route whose conditions are met is the one taken. Any route with no conditions set acts as a catch-all.
Best practice: put your most specific routes first, and use an unconditioned route last as a fallback (for example, a "Fail" branch).
What data is available
The data you can condition on depends on what is in your flow before the branching step. Persona surfaces everything available to you directly in the condition picker — you can click through the options in any branching step to explore what's available in your specific flow.
Generally, you'll see things like:
- Inquiry data — status, fields your flow collects (name, date of birth, country, etc.), and metadata like timestamps
- Verification results — status, extracted attributes (name, birthdate, country of issuance, ID type), and check-level outcomes — for every verification module that appears before this step
- Account data — if an account is associated with the inquiry
The sections below walk through two of the most common patterns to give you a feel for how it works in practice.
Example: pass / retry / fail routing
The most common use of a branching step is to handle the outcome of a verification. Route users who passed, retry those who haven't used up their attempts, and fail everyone else.
| Route | Condition | Destination |
|---|---|---|
| Route 1 | verification_government_id > status is passed |
Next step (or Success screen) |
| Route 2 | verification_government_id > status is failed AND verification_government_id > attempt_count is less than 3 |
Back to the verification |
| Route 3 | (no condition — catch-all) | Fail screen |
Example: routing on Government ID type
You may want to apply different logic depending on which type of ID a user presents. There are two places ID type appears — they mean different things:
| Path | What it represents |
|---|---|
trigger > fields > selected_id_class |
The ID type the end user selected before scanning |
trigger > verification_government_id > identification_class |
The ID type detected by Persona from the document |
Use selected_id_class when you want to act on the user's stated choice (for example, to show a different screen before scanning). Use identification_class when you want to route on the verified, extracted result — this is more reliable for decisioning.
Common values for both fields:
| Value | Document |
|---|---|
dl |
Driver license |
pp |
Passport |
ppc |
Passport card |
id |
National ID card |
rp |
Residence permit |
pr |
Permanent residence card |
wp |
Work permit |
Note:
ppc(Passport card) is a separate value frompp(Passport). If you're routing on passports, check for both values if you want to include US passport cardholders.
Other things you can condition on
Once you're comfortable with the above patterns, here are other commonly useful paths to know about. What's available for each will depend on your flow and what’s in it.
| What you want to check | Path |
|---|---|
| An inquiry field (e.g., email, DOB, country) | trigger > fields > [field_key] |
| Country the ID was issued in | trigger > verification_government_id > country_code |
| Applicant's date of birth (from the ID) | trigger > verification_government_id > birthdate |
| Type of supplemental document uploaded | trigger > verification_document > document > document_type |
| Inquiry status | trigger > status |
Note: Some paths are viewable when configuring the step, but please ensure they are available in your flow before the step before using that path. As an example,
document_typeis only available when your flow contains a Document Verification (used for supplemental docs like bank statements, utility bills, and proof-of-address documents). It is separate from Government ID Verification. Common values includebank_statement,utility_bill,credit_card_statement, andpaystub. So if Document Verification is not in your flow your logic that may be looking for something likepaystublikely won’t execute when an end user flows through your Inquiry.