Gilbert Gao

During a new sales process, not every customer needs to complete identity verification. Many organizations first make a risk decision: if the customer appears low risk, the sale can continue through the standard path; if the customer is considered high risk, the business may require an additional identity verification step before the downstream sales process can move forward.

That is where a Salesforce and Persona integration becomes useful.

In this pattern, Salesforce does not perform the identity verification itself. Salesforce owns the sales process, customer record, verification request, and downstream automation. Persona owns the identity verification experience through a Persona Inquiry, including the customer-facing flow for ID upload, selfie or liveness checks, matching, and decisioning.

The challenge is not just verifying identity; it is doing it without breaking the sales process or losing visibility inside Salesforce. The integration goal is straightforward: when a high-risk customer is identified, Salesforce creates a controlled verification request, sends the customer to Persona, and lets Persona update Salesforce when the verification result is ready.

Integration Pattern Overview

This article uses three main concepts:

The core relationship is:

• One Salesforce Account can have many Persona Actions over time.
• One Persona Action maps to one Persona Inquiry.
• One Persona Inquiry maps back to one Persona Action.

This 1-to-1 mapping between Persona Action and Persona Inquiry keeps each verification attempt auditable. It also makes retries and expirations easier to manage because Salesforce can always identify the exact verification request associated with a Persona Inquiry.

The following diagram shows the hosted-flow version of this integration pattern.

Persona Inquiry Template Configuration

The focus of this article is the Salesforce-Persona integration, so the Persona background can stay concise. The key Persona configuration concept is the Persona Inquiry Template.

A Persona Inquiry Template is the reusable configuration, or blueprint, for a verification flow. A Persona Inquiry is a specific instance of that template created for one customer verification request. In this pattern, Salesforce creates a new Persona Inquiry from the selected template whenever a Persona Action needs ID verification.

For a high-risk sales flow, the template may include:

• Government ID upload
• Selfie or liveness capture
• ID-to-selfie matching
• Decision outcomes such as approved, declined, or needs review
• Branding and customer-facing instructions

Persona supports template versioning. If Salesforce uses an Inquiry Template ID beginning with itmpl_, new Persona inquiries use the latest published version of that template. If Salesforce uses an Inquiry Template Version ID beginning with itmplv_, Salesforce is pinned to a specific version snapshot.

That decision is architectural. Use the template ID when Persona configuration changes should take effect without a Salesforce deployment. Use the template version ID when Salesforce should stay locked to a tested version of the verification flow.

In many organizations, template ownership sits with the identity, risk, or compliance team, while Salesforce owns when the template is invoked and how the result affects the sales process.

Identifier Mapping

A common design mistake is using only the Salesforce Account ID to map Persona results back to Salesforce. That works only if a customer can have one verification request. In practice, the same customer may retry verification, re-verify later, abandon a previous attempt, or have an old request expire.

A stronger pattern is to send two Salesforce identifiers to Persona:

The Persona reference-id links multiple Persona inquiries to the same customer, while the custom actionId identifies the exact Salesforce Persona Action record to update when Persona sends the verification result.

This gives the integration two levels of correlation:

• Customer-level correlation through the Salesforce Account ID
• Verification-request correlation through the Salesforce Persona Action ID

When Persona updates Salesforce directly through a Salesforce connection, the Persona Workflow can use actionId to find and update the correct Persona Action record. If the implementation uses a webhook instead, the same actionId should be included in the webhook payload and used by Salesforce or middleware to locate the correct record.

Updating Salesforce from Persona

There are two common ways to update Salesforce after Persona completes the verification.

In this design, the preferred path is Persona Workflow with a Salesforce connection. Persona already has the actionId, so the Workflow can locate the corresponding Persona Action and update its status based on the verification result.

For example:

• If the Persona Inquiry is approved, update the Persona Action status to Approved.
• If the Persona Inquiry fails or is declined, update the Persona Action status to Failed.
• If the result requires manual review, route it according to the business process, such as keeping the action pending or assigning it to a review queue.

Webhooks are still a valid integration option. They are especially useful when the Salesforce update needs custom Apex logic, middleware transformation, additional fraud checks, or complex orchestration. The important design principle is the same in both patterns: Persona must send enough context, especially actionId, so the exact Persona Action can be updated deterministically.

End-to-End Flow

The end-to-end flow looks like this:

1. A Salesforce process or upstream risk engine flags a customer as high risk.
2. Salesforce creates a Persona Action with status New.
3. Salesforce calls Persona’s API to create a Persona Inquiry from the selected Inquiry Template.
4. Persona returns the Persona Inquiry ID.
5. Salesforce stores the Persona Inquiry ID on the Persona Action.
6. Salesforce generates or requests a verification link.
7. Salesforce sends the link to the customer by email, SMS, portal notification, or another approved channel.
8. Salesforce updates the Persona Action status to Requested.
9. The customer opens the Persona verification flow.
10. The customer completes ID upload, selfie or liveness capture, and matching.
11. Persona evaluates the verification result.
12. A Persona Workflow uses the Salesforce connection to update the matching Persona Action record to Approved or Failed.

Salesforce then controls the downstream process:

• If the Persona Action becomes Approved, the sales process can continue.
• If the Persona Action becomes Failed, Salesforce can apply business rules, such as creating a new Persona Action for another attempt.
• If the Persona Action becomes Expired, the current verification request should no longer be usable.

Calling Persona from Salesforce

The exact payload depends on your Persona configuration, but the following Apex-style example shows the key integration values Salesforce should send when creating a Persona Inquiry. It is intentionally short: production code should add stronger error handling, request/response logging, retry controls, response typing, and secure exception handling.

public with sharing class PersonaInquiryService {
    public static String createInquiry(
        Id accountId,
        Id personaActionId,
        String inquiryTemplateId,
        Datetime expiresAt
    ) {
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:Persona_Named_Credential/api/v1/inquiries');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setHeader('Idempotency-Key', String.valueOf(personaActionId));
        Map<String, Object> body = new Map<String, Object>{
            'data' => new Map<String, Object>{
                'attributes' => new Map<String, Object>{
                    'inquiry-template-id' => inquiryTemplateId,
                    'expires-at' => expiresAt.formatGmt('yyyy-MM-dd\'T\'HH:mm:ss.SSS\'Z\''),
                    'fields' => new Map<String, Object>{
                        'actionId' => new Map<String, Object>{
                            'type' => 'string',
                            'value' => String.valueOf(personaActionId)
                        }
                    }
                }
            },
            'meta' => new Map<String, Object>{
                'auto-create-account-reference-id' => String.valueOf(accountId)
            }
        };
        req.setBody(JSON.serialize(body));
        HttpResponse res = new Http().send(req);
        if (res.getStatusCode() < 200 || res.getStatusCode() >= 300) {
            throw new CalloutException('Persona create inquiry failed: ' + res.getBody());
        }
        Map<String, Object> parsed =
            (Map<String, Object>) JSON.deserializeUntyped(res.getBody());
        Map<String, Object> data = (Map<String, Object>) parsed.get('data');
        return (String) data.get('id');
    }
}

In this implementation pattern, the create-inquiry API response returns the Persona Inquiry ID. Salesforce should save that ID on the Persona Action record. If Salesforce needs a customer access link, it can generate the hosted URL from the Inquiry ID or make a separate Persona API call to create a one-time link, depending on the selected user experience.

Use a Salesforce Named Credential or secure middleware layer for Persona authentication. Do not hardcode API keys in Apex.

Hosted Flow, Embedded Flow, and Link Strategy

The diagram for this article shows a Persona Hosted Flow pattern. In that approach, Salesforce sends the customer a Persona-hosted verification URL by email, SMS, or another communication channel. The customer leaves the Salesforce-controlled process, completes the Persona experience, and Persona updates Salesforce after verification.

That is not the only possible pattern.

Once Salesforce has created and stored the Persona Inquiry ID, the same architecture can also support an Embedded Flow pattern. In an embedded flow, the business can present Persona inside a web page or portal experience instead of sending the customer to a separate hosted page. The key design remains the same: Salesforce owns the Persona Action, and Persona owns the Persona Inquiry.

There are also different link strategies:

One-time links are usually a better production pattern for email or SMS because they avoid exposing the raw Inquiry ID in the customer-facing link. A one-time link should be treated as single-use access, not as a reusable resume link.

If the customer needs to resume verification later, Salesforce can generate a fresh one-time link for the same Persona Inquiry. That can be triggered by a support agent, sales rep, automated reminder, or secure self-service resend flow.

Expiration Design

Expiration is important because verification links should not live forever.

This pattern uses two expiration controls:

1. When Salesforce creates the Persona Inquiry, it sets or relies on an expiration policy so the inquiry is not valid indefinitely.
2. When Salesforce sets the Persona Action status to Expired, Salesforce triggers an API call to Persona to expire the Persona Inquiry.

Both controls are useful.

Persona-side expiration protects verification sessions and links that were created but never completed. Salesforce-driven expiration handles business events: a sale is cancelled, a duplicate request is found, a newer verification attempt replaces the old one, or a user manually withdraws the verification requirement.

Expiration should be controlled from both sides: Persona protects the verification session with inquiry/session expiration, while Salesforce can explicitly expire the Persona Inquiry when the Persona Action is no longer valid.

After the Persona Inquiry is expired, the old customer link should no longer allow verification. That keeps the Salesforce business state and the Persona verification state aligned.

Salesforce Status Lifecycle

The Persona Action status is the control point for the Salesforce process.

Persona has its own inquiry statuses and events. Salesforce does not need to mirror them exactly. Instead, Salesforce should map Persona results into business-friendly Persona Action statuses that downstream automation can understand.

For example, Persona can use a Workflow and Salesforce connection to update a Persona Action to Approved. Salesforce can then trigger the next sales process. If Persona updates the action to Failed, Salesforce can apply the retry rules defined by the business.

Design Considerations and Best Practices

A few design choices make this integration easier to support:

• Use a Salesforce Named Credential or secure middleware layer for Persona API authentication.
• Store the Persona Inquiry ID on the Salesforce Persona Action.
• Use Salesforce Account ID as the Persona reference-id, rather than email address or sensitive personal information.
• Use actionId so Persona Workflow or webhook-based updates can find the exact Persona Action.
• If using Persona Workflow with a Salesforce connection, keep the field mapping simple and deterministic.
• If using webhooks, make webhook processing idempotent because events may be retried.
• Log request and response metadata for operational support.
• Consider one-time links for email or SMS delivery.
• Decide whether Salesforce should use the latest Inquiry Template ID or a pinned Inquiry Template Version ID.
• Define retry rules clearly so each new attempt creates a clean Persona Action and Persona Inquiry.

The retry rule is especially important. If a customer fails verification and the business allows another attempt, a clean design is to create a new Persona Action and a new Persona Inquiry. That keeps every attempt separate and auditable.

Why This Pattern Works

This pattern works well because responsibilities are clearly separated:

• Salesforce keeps the customer record, audit trail, and sales process state.
• Persona handles the specialized identity verification experience.
• The Persona Action and Persona Inquiry mapping makes each attempt traceable.
• Retry and expiration rules remain controlled by Salesforce business logic.
• Persona Workflow can update Salesforce directly, while webhooks remain available for teams that need additional integration control.

Conclusion

The main design principle is straightforward:

Salesforce owns the sales process and Persona Action lifecycle; Persona owns the identity verification experience through the Persona Inquiry.

This division of responsibility gives Salesforce teams a reusable integration pattern. Salesforce decides when verification is needed, tracks every verification attempt, controls downstream automation, and keeps the audit trail. Persona provides the specialized ID verification flow and can update Salesforce directly through a Workflow and Salesforce connection.

For high-risk new sales, this pattern creates a clean bridge between risk decisioning, customer identity verification, and Salesforce-driven business process automation.