This article will provide an in-depth walkthrough of your Dynamic Flow Template and guide you through the settings you can configure to get production-ready.

Flow view

This view maps all of the possible pathways through the inquiry. As end users progress through each screen in this map, the path they take depends on branching and routing configurations in the Dashboard.

1. Welcome screen: This is the first screen of the flow and the first screen that the user will see when an inquiry is created for them.
2. Country Select screen: Next, the user will progress to the Country Select screen, to help us identify where their Government ID is from. If you’re only allowing IDs from one country, you might opt to remove this screen.
3. Government ID collection: Now we’ll collect the user’s Government ID.
   • This collection experience consists of a screen series (asking for ID selection, capturing the images, having the user verify the submission, etc).
   • You can expand the view in the editor to see the entire experience.
4. Verification: After we’ve collected the user’s ID, we’ll run a verification action on it. If you hover over this action sequence in the editor, you’ll see it consists of two steps: one to run the verification, and one to write the verification’s fields (the extracted ID fields) back to the inquiry
5. Branching step: Now we’re introducing a Branching step to conditionally route the user to the next screen depending on the result of their verification.
   • If the user passes the verification, we’ll move onto Selfie collection (after another action step to update the account fields).
   • If the user fails but has not exhausted all of their attempts, they will be shown the “Couldn’t verify photos” screen and then routed to the Government ID screen to try again.
   • If neither of these conditions are true, the user is routed to the Fail screen.
   📣 At the end of the second and third routes, you’ll see boxes with arrows in them. These are called Connector Steps, and we use them to route the user to a screen that exists elsewhere in the flow.

   

6. Selfie collection: We collect the selfie (again, via a series of combined screens).
7. Selfie verification: We’ll run the collected selfie through verification.
8. Branching step: The same pass/retry/fail logic exists for the selfie verification.
   • This template only includes Government ID and Selfie verifications, so if the user also passes the selfie verification, then they will have successfully completed their inquiry.
   • Otherwise, they will be prompted to retry and ultimately fail if none of the retries are successful. The badges above the “Success” and “Fail” screens indicate the status the inquiry will assume (completed and failed respectively).

Verification template view

Each verification is made up of a variety of different verification checks, each of which can be Required, Not Required, or Disabled. For a verification attempt to pass, it must pass all required checks. You are able to see and configure the checks for each of your verifications in the inquiry’s Configuration editor. See this article for more information on configuring checks.

Getting your Dynamic Flow Template production-ready: a checklist

1. Set the theme
2. Adjust wording and component-level styling
3. Collect any additional information you need from the user
4. Configure verification checks and allowed ID types
5. Adjust the number of retries if desired
6. Set capture methods and file types
7. Configure inquiry expiration settings

1. Style the inquiry in Theme Editor

Clicking Theme will bring up the Theme Editor, where you can set overall look and feel of your Dynamic Flow Template — including colors, fonts, and, and text placement.

Each Theme Set is global and is represented by a card, so once you've finalized changes to a Theme Set, you'll need to set the Theme on the desired Inquiry Templates within the specific Inquiry Template configurations.

2. Adjust wording and component-level styling

Clicking the ✏️ icon or double-clicking on any screen will bring you to the Screen Editor. Here, clicking on any Component (any item within the screen) will bring up a sidebar where you can edit the text and style. Note that any styles you apply on the component directly are for this component only, and will not affect your overall theme.

You can also edit any translations you have by pressing the “Edit translations” button, and see a list of all of your enabled languages in the Configure view (by default, all languages that Persona offers are enabled).

3. Collect any additional information you need from the user

Between any two screens, or between a screen and an action, you’ll see a purple circle that turns into a ➕ when you hover over it. Clicking on it will bring open a submenu that gives you the option to add a new screen, module, action sequence, branching, or connector.

This new screen starts off as a blank canvas, but by accessing the Component Library you can drag-and-drop display and components onto the screen and change their text (as shown previously). Persona default screens generally follow this format:

• Title component
• Spacer
• Other components (text, input, etc)
• “Continue” button

When adding any input components, set a descriptive Field Key for these components, because the Field Key will be the identifier for the value in the API response. A good field key will accurately describe the information that’s being asked for, like name_first or address_country_code

• To set a Field Key for a new field, edit the Field Label immediately after adding the component.

• To set a Field Key for an existing field, change the selection to an existing one using the Field dropdown

  

4. Configure verification checks and allowed ID types

The overall success or failure of a verification will depend on its verification check configuration. Persona checks can be Required, Not Required, or Disabled.

• All non-Disabled checks will run on every verification.
• A verification attempt can only pass if all of its required checks pass.
• If the verification attempt fails, the user will be prompted to retry until they exhaust all of their attempts (see below on configuring retries).

Head to this page for instructions on how to configure your verification checks along with your allowed ID types.

5. Adjust the number of retries if desired

Click on the Branching Step that appears after a verification to open up its logic.

You’ll see that on the “Retry” path, the conditional looks something like trigger.flow_state.run_<verification>_attempts < 5 by default (flow_state is a variable that’s internal to the inquiry). You can change the limit on verification attempts by clicking on and editing the expression in the panel. Change the value from 5, the default, to another value.

6. Set capture methods and file types

For each verification, you’ll be able to set the capture type in the Configurations Editor.

7. Configure inquiry expiration settings

To ensure users aren’t allowed access to their inquiries indefinitely, but to avoid friction for users who might not complete their inquiries right away, you can configure your Expiration intervals settings. The default settings are shown below.

Next

The next steps are to test your flow, then go live!