Conditional steps in a Workflow let you branch your workflow’s path based on data from the trigger and its related objects. Instead of every workflow run taking the same path, you can route runs down different branches depending on the data.
How routes work
A conditional 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.
What data is available
In a workflow, the trigger is the object that started the workflow run — most often an Inquiry, but it can also be an Account, Case, Transaction, Report, or other object depending on how the workflow is configured.
Whatever the trigger is, you can condition on its data and on any related data you can reach from it. Persona surfaces everything available in the condition picker — you can click through the options in any conditional step to explore what’s available in your workflow.
For an inquiry-triggered workflow, you’ll typically see:
- Inquiry data — status, fields (name, date of birth, country, etc.), tags, timestamps, and the inquiry template that was used
- Verification results — status, extracted attributes, and check-level outcomes for every verification run during the inquiry
- Account data — the account the inquiry is associated with, plus its history (other inquiries, cases, verifications, etc.)
- Reports — any reports run on the account
For workflows triggered by other objects (e.g., an Account or Case), the trigger and the related data available will be different. The picker still shows you what’s there.
The sections below walk through two of the most common patterns to give you a feel for how it works in practice.
Example: routing on inquiry outcome
A common pattern is a post-inquiry workflow that takes different actions depending on whether the inquiry was approved, declined, or sent for manual review.
| Route | Condition | Branch leads to |
|---|---|---|
| Route 1 | trigger > status is approved | Send welcome email action |
| Route 2 | trigger > status is declined | Send rejection notification action |
| Route 3 | trigger > status is needs_review | Create case action |
| Route 4 | (no condition — catch-all) | End workflow |
Example: routing on Government ID type
When you want different downstream actions for different ID types (for example, sending US driver license holders through one report and passport holders through another), you can condition on ID type. As with branching steps in inquiries, there are two paths that 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 identification_class for decisioning in workflows — it reflects what was actually verified rather than what the user stated.
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.
Examples of other things you can condition on
Once you’re comfortable with the above patterns, here are other commonly useful paths to know about for inquiry-triggered workflows. What’s available will depend on the trigger type and what ran during the inquiry.
| What you want to check | Path |
|---|---|
| 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 |
| Whether a specific check failed | trigger > verification_government_id > failed_checks |
| An inquiry field (e.g., email, DOB, address) | trigger > fields > [field_key] |
| Type of supplemental document uploaded | trigger > verification_document > document > document_type |
| The inquiry template used | trigger > inquiry_template > id |
| Account status | trigger > account > account_status |
| Number of past inquiries on the account | trigger > account > inquiries.count |
| Tags applied to the inquiry | trigger > tags |
Note: Some paths are viewable when configuring the step, but please ensure they are available in your workflow 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 the Workflow runs.