Editing logic within a Conditional Step

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.

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:

Use identification_class for decisioning in workflows — it reflects what was actually verified rather than what the user stated.

Common values for both fields:

Note: ppc (Passport card) is a separate value from pp (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.

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_type is 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 include bank_statement, utility_bill, credit_card_statement, and paystub. So if Document Verification is not in your flow your logic that may be looking for something like paystub likely won’t execute when the Workflow runs.