Persona Help Center
Overview
A method chain is the way you tell Persona which piece of data you want to use in a condition (like Conditional Step), an action's parameter (like Update Object Step), or anywhere else that asks you to reference a value. Each chain starts from a root object and steps through its attributes and related objects until it lands on the specific value you need.
You don't have to write method chains by hand — Persona's condition and field pickers walk you through them step-by-step. But understanding how they work helps you find the data you need faster and recognize what's possible.
Anatomy of a method chain
Read a method chain left-to-right, drilling deeper with each step.
trigger > verification_government_id > country_code
This reads as: "start at the trigger, find the Government ID verification on it, then get its country code."
Every chain has three parts:
- A root — usually
trigger, the object that initiated the workflow or that the branching step is operating on. - One or more steps — each step either drills into an attribute (like
country_code) or follows a relationship to another object (likeaccountorverification_government_id). - A final value — the piece of data you actually use. This can be a string, number, date, boolean, or list.
Starting from the trigger
The trigger is your entry point. What it is depends on the context:
| Context | What trigger refers to |
|---|---|
| Workflow conditional step | The object that started the workflow run (inquiry, account, case, transaction, report, etc.) |
| Inquiry branching step | The current inquiry |
| Workflow action step | Same as the conditional step — the workflow's trigger object |
From the trigger, you can either pull one of its direct attributes (like status or created_at) or follow a relationship to another object (like account, verifications, cases).
Following relationships to related objects
This is the part that makes method chains powerful. Most Persona objects are connected to other objects, and chains let you walk those connections.
For example, an Inquiry is connected to:
- An Account (and that account has its own inquiries, cases, verifications, reports)
- One or more Verifications (Government ID, Selfie, Document, Database, etc.)
- An Inquiry Template
- Tags
Some examples of chains that follow relationships:
| Chain | What it returns |
|---|---|
trigger > account > account_status |
The status of the account associated with the trigger inquiry |
trigger > verification_government_id > country_code |
The country code from the Government ID verification |
trigger > verification_document > document > document_type |
The type of supplemental document uploaded |
trigger > inquiry_template > id |
The ID of the template used for this inquiry |
Different objects expose different data
Each type of object exposes its own set of attributes and relationships. The picker only shows you what's actually available — so a verification_government_id will offer things like country_code, identification_class, and birthdate, while a verification_document will offer document_type and a document relationship.
A few of the most common objects and the kind of data you'll find on each:
| Object | Examples of what you'll find |
|---|---|
inquiry |
status, fields, tags, created_at, plus relationships to its verifications, account, and template |
account |
account_status, address_country_code, tags, plus relationships to inquiries, cases, reports, verifications |
verification_government_id |
status, identification_class, country_code, name_first, name_last, birthdate, expiration_date, failed_checks |
verification_document |
status, country_code, plus a relationship to a document |
document |
document_type, page_count, file_count |
case |
status, tags, plus relationships to the objects it references |
Operators: doing more than a direct lookup
Method chains aren't limited to just navigating to a value. You can apply operators at any step to transform or evaluate the data along the way. For example:
.count— how many items are in a list.first/.last— pull the first or last item.filter('key', 'operator', 'value')— narrow a list down to items that match.domain/.username— extract parts of an email address.length— character count of a string
So a chain like:
trigger > account > inquiries.filter('status', '=', 'declined').count
reads as: "from the trigger, go to its account, look at all its inquiries, keep only the declined ones, and count them."
For the full list of operators and how to combine them, see Using Conditional Step Operators.
Context matters: what's available depends on where you are
The picker only shows you data that exists in your current context. A few examples:
- In a workflow conditional step, what's reachable from
triggerdepends on what kind of object triggered the workflow. An inquiry-triggered workflow exposes inquiry data; an account-triggered workflow exposes account data. - In an inquiry branching step, you can only reach verification data for modules that appear before the branching step in the flow.
- Some fields only appear when a corresponding feature is enabled or a corresponding object exists. For example,
document_typeonly appears when a Document Verification has run.
If you don't see the data you expected in the picker, check that the upstream module or trigger type actually produces it.
Where you'll see method chains
Method chains appear anywhere in the Dashboard where you reference a piece of data dynamically:
- Conditional steps in Workflows
- Branching steps in Inquiry templates
- Action step parameters in Workflows (for example, mapping inquiry fields into a new verification)
- Update Object steps in Workflows
- Output steps in Workflows
- Custom code blocks and templated strings
The picker is consistent across all of these — once you've used method chains in one place, you'll recognize them everywhere.