Personally Identifiable Information (PII): Any information, data, or documents that can help identify an individual.
Flow: A descriptive reference to any processes and branching logical paths, start to finish within an Inquiry.
Flows are designed to give you flexibility in how you logically sequence various steps including the screens you end users will engage with in an Inquiry.

Inquiry Flows are organized visually to start on the left and work their way to terminal screens on the right.

Workflows are organized visually to start at the top and work their way down to a terminal step.
Step: Any discrete process within a Persona flow (Workflow or Inquiry) is referred to as a Step.
For example in the example above a Branching Condition step splits into three routes, with each route including an action step that updates the status of the related inquiry.
End User: A person that a Persona customer is seeking to collect, verify, or reverify identity information from.
User: Users are profiles of team members who are granted access to a customer’s Persona Organization, with access determined by their Role.
Organizations: An Organization is an instance of a Persona object that houses all objects related to a Persona customer including the dashboard experience, environments, billing, users, and product objects.
Account: An object representing a unique end user or business, that acts a system of record for all objects related to a specific person or a business.

While an Inquiry can collect PII from a person or business, that’s a moment in time snapshot of that entity. With an Account, you can collect repeated interactions with that entity in one place. With our example above, Alexander J. Sample has completed three inquiries and all of them have been collected under his account. That includes all the verifications from those inquiries. Other objects like Reports related to the entity can also be attached to the account. This allows you to monitor the entity over time in one place.
Inquiry: An object representing one attempt at collection and verification of identity information from an end user, usually using Verifications.

The goal of an inquiry is to allow an end user to submit PII and to have it verified via a relevant verification. The experience for the end user is controlled first through the screens they will interact with, but also by setting conditions and criteria that determine whether they pass or fail specific verifications and ultimately the Inquiry as whole. This experience can be adjusted based on your sensitivity to fraud, with certain paths requiring more scrutiny based on the higher risks.
Transaction: A product that enables integration with Persona via API to trigger subsequent Workflows and run additional Verifications, Reports, business logic, and other processes.
In the case that you have already collected end user data, you can avoid inputing it via an Inquiry by instead submit the data via an API call directly to Persona. The verifications that would be included in an Inquiry can instead be handled within a workflow set the trigger off the transaction.
Verification: An object that runs multiple tests called Verification Checks, to scrutinize end user PII for likelihood of authenticity, validity, and assurance that the information is true and real.

Persona has numerous Verifications, each one tailored to the type of PII its trying to verify. Each verification includes customized tests called checks that scrutinize a specific aspect of the item being reviewed. For example in the example Government ID verification above, we can see a “Compromised submission” and “Allowed ID type” check. The compromised submission check is looking for signs the submitted ID has been altered, while the Allowed ID type is checking that the submitted ID is one of the allowed IDs that have been configured.
The status of Verifications and their individual checks can be referenced in conditional logic to drive automations in Inquiries and Workflows.
Reports: Report products provide additional identity data from private and government sources to help organizations enhance identity information. For example, Reports may pull in information like address history, published government watchlist matches, media mentions, or business records.

Workflow: An automation tool that lets you create flexible, no-code or code-based workflows to streamline identity-related processes in Persona that can trigger actions based on events, API calls, or schedules, integrate with Persona products and third-party apps, and build logic using conditions, parallel execution & custom web requests.

A workflow allows you to create an automated flow that can interact with nearly every Persona object and product in your organization. A few examples:
- Workflows can be scheduled to trigger, or start, at a set time in the future allowing recurring processes to be automated.
- Workflows can set off notifications to your team, or send emails to your end users inviting them to complete an Inquiry.
- Workflows can update Accounts, create and send new Inquiries, run Reports and Verifications, start a Graph query, and create and attach a Case.
Cases: A product that allows customers to build UI display templates that arrange and surface attached objects like inquiries, verifications, reports, transactions, and accounts for further investigation, often conducted by manual review teams.

And with the Case Actions feature, a mini workflow for that case template, your review team can automate complex steps into the click of a button.
Tags: A feature available on most Persona products allowing you to store custom context or observations to help drive manual and automated decisioning.

Tags can be attached to any of the following Persona objects: Accounts, Cases, Inquiries, Transactions, Reports, & Verifications. Within workflow and inquiries, conditional branches can reference tag and use them to drive their logic. Tags can also be used as a quick at a glance indicator during manual review, to help inform the reviewer about how the object was handled by their automated logic. In the example above, the Business Registry Verification was run, attached to a Case, and then the BRV Passed? conditional branch either tags the Case with the custom BRV PASSED or BRV FAILED tag. The case reviewer would be able to see either of those tags at a glance instead of having to hunt down the verification.
Lists: A set of products that allows you to store attributes like emails, IP addresses, and images, that can be matched against the content of an Inquiry or Workflow to then take subsequent actions if there is a list match.

Lists can be used to contain a set of objects of the same Type. List types include Country, IP Address, Geolocation, etc. You can use flow logic to check to see if information collected information matches an existing List entry. Common use cases for Lists include auto declining inquiries with known fraudulent Social Security Numbers, Phone numbers, and IP Addresses.
**Graph:**A visual, interactive link analysis product that allows customers to investigate relationships between Accounts, IP addresses, device information, phone numbers and other data that can indicate patterns of fraud.
Trying to identify fraud rings and suspect behavior is difficult without a holistic view of your user data. By analyzing shared attributes, behaviors, and interactions across all Accounts, Graph enables you to identify, investigate, and take action against suspicious users and bad actors. Graph helps teams systematically conduct investigations, respond to threats, and build proactive fraud prevention measures.
Integrations: Various 3rd party products that can be integrated into Persona. Integrations can be used to support seamless user authentication, team communication, data enrichment, sales and customer support workflows, and much more.