Every service team eventually has to answer a simple question: how do we know the person on the phone is really the customer? Asking for a date of birth and a street address used to be enough. Today, much of that information can be found online, and customers expect verification to be quick. This guide explains how to design caller identity verification in Salesforce, using one-time SMS codes, fallback questions and a clear audit trail.
Caller identity verification in Salesforce means confirming a customer's identity before an agent discusses or changes their account, and recording the result. A strong default is a one-time code sent by SMS to the mobile number already on file, which the customer reads back to the agent. When the customer can't access that phone, agents fall back to a set number of knowledge questions or a customer PIN. A guided flow keeps every agent consistent and logs each attempt. Vantage Point builds these processes through its workflow automation and process optimization services.
Service calls are a common entry point for account takeover. A caller who can pass weak verification may be able to change an email address, redirect a payment or learn personal details. Even without fraud, inconsistent verification creates risk. One agent asks three questions, another asks one, and nobody can later show what was checked.
A defined verification process protects customers, gives agents confidence, and gives compliance and audit teams a clear record. It also speeds up calls, because agents aren't improvising.
Most service teams combine two or three methods. Each has strengths and weaknesses.
| Method | How it works | Strengths | Weaknesses |
|---|---|---|---|
| One-time SMS code | A short code is texted to the mobile number on file, and the customer reads it to the agent. | Fast, familiar, proves access to the phone. | Fails if the number is outdated. SIM-swap fraud is a known risk. |
| One-time email code | A code is sent to the email address on file. | Useful when SMS isn't available. | Slower during a live call, and email accounts can be compromised. |
| Knowledge questions | The customer answers questions about account details. | Works without a device. | Answers may be guessable or found online. |
| Customer PIN | The customer sets a PIN that's asked on future calls. | Quick and within the customer's control. | Needs a secure setup and reset process. |
A common design uses the SMS code as the primary method, with knowledge questions as the fallback and a customer PIN added over time for faster future calls.
Here's a typical design using a screen flow on the agent's console:
Keep codes short-lived, usually a few minutes, and limit the number of attempts. Store only what you need, and never write the code itself into notes or case comments.
This is the part teams most often forget to design. A customer may have changed numbers, lost their phone, or be calling from abroad. The fallback needs to be clear and consistent:
Many orgs already send text messages for reminders, alerts or marketing through an SMS provider or an AppExchange app. Before building a new integration, check whether that existing service can be called from Flow. Reusing it can save time, avoid a second vendor contract and keep message history in one place.
Questions to ask:
If the existing tool doesn't fit, a dedicated transactional SMS provider connected through an invocable action is usually straightforward. Our guide to modern contact center architecture covers how telephony and messaging tools fit together.
Some Salesforce industry clouds include identity verification features with flow templates for contact center agents. For example, Salesforce's contact center documentation describes a Verify Customer Identity flow template that confirms identifiers and logs call details. Availability depends on your edition and licenses.
If your org doesn't include these features, a custom screen flow with a verification log object delivers the same core outcome: consistent steps, clear pass or fail, and a record of every attempt.
A verification log turns a phone conversation into evidence. Capture at least:
Report on failures and fallbacks regularly. A spike in failed attempts on one account can signal fraud, and a high fallback rate can mean contact details on file are out of date.
The best-designed flow still fails if agents don't trust it or customers find it confusing. A short, staged rollout helps:
Plan a clean-up of contact data alongside the rollout. Every outdated mobile number becomes a fallback call, so a campaign asking customers to confirm their details pays off quickly.
Vantage Point designs and builds caller verification processes in Salesforce, from the policy decisions through the screen flow, SMS integration and reporting. Our workflow automation team builds guided agent processes, our Service Cloud Voice services connect telephony to the agent console, and our compliance and security solutions cover audit and data handling. We've completed 400+ engagements for 150+ clients, with a 4.71/5.0 average engagement rating and 95% client retention. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.
A good verification process protects customers without slowing agents down. Vantage Point can design your methods and fallbacks, build the flow in Salesforce, and connect your SMS tools. Talk to Vantage Point about your service process.
Most teams use a guided screen flow that sends a one-time code to the contact details on file or asks a set of verification questions. The flow records pass or fail, the method used and the agent, so every call follows the same steps.
Yes, through a messaging product or an SMS provider connected to Flow. The flow generates the code, sends it to the mobile number on the account, and checks what the customer reads back.
Use a defined fallback, such as a fixed number of knowledge questions or a customer PIN. Consider limiting what a fallback verification can unlock, especially changes to contact or payment details.
It's a strong improvement over knowledge questions alone, because it proves access to the phone on file. SMS can be targeted through SIM-swap fraud, so high-risk actions may need an extra check.
No. The flow should generate and compare the code without displaying it to the agent, and the code shouldn't be stored in notes, cases or activity history.
Often, yes. If the tool offers a Flow action or API for single transactional messages, it can send verification codes. Check sender setup, message storage and consent rules first.
The customer, agent, date and time, method, which questions were asked, the result, and any action taken afterward. Don't store the answers themselves.