# Method Chains

> How method chains reference dynamic data in Workflows and branching logic: start at a root object like trigger, follow relationships, and apply operators.

Source: https://help.withpersona.com/articles/6ADlpksU5PGtbzlxiT6KEh/
Section: Workflows > Introduction > Key Concepts

## 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:

1.  **A root** — usually `trigger`, the object that initiated the workflow or that the branching step is operating on.
2.  **One or more steps** — each step either drills into an attribute (like `country_code`) or follows a relationship to another object (like `account` or `verification_government_id`).
3.  **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](https://help.withpersona.com/articles/5HnQvtkzFUkUSo9gdgECnX/).

## 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 `trigger` depends 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_type` only 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.