Automatic Number Identification (ANI)
Automatic Number Identification (ANI) is the caller's phone number that the telephony network captures and delivers with every inbound call.
Definition
Automatic Number Identification (ANI) is the caller's phone number that the telephony network captures and delivers with every inbound call. It arrives during call setup, alongside the dialed number known as DNIS, and it tells the receiving system who is on the line before anyone speaks. In a Salesforce contact center, the ANI is the signal that links a ringing phone to a known customer.
In Salesforce Voice (formerly Service Cloud Voice) the ANI flows from the telephony provider into Salesforce and drives caller matching. The platform searches your records for that phone number, finds the matching Contact, Account, Lead, or Person Account, and opens it on the agent's screen as a screen pop. The same number can shape routing, feed the IVR for self-service, and provide context the agent would otherwise have to ask for.
How ANI turns a ringing phone into a known customer
Where the ANI comes from
ANI is generated by the telephony network, not by Salesforce. The originating switch attaches the caller's number to the call signalling (SIP, ISDN, or SS7) as the call is set up, and it travels with the call to the receiving system. By the time the call reaches your contact center, the ANI is already present in the call metadata. In Salesforce Voice the telephony provider owns this layer. With the Amazon Connect option, AWS captures the number when the call hits the Connect instance and exposes it to contact flows and to Salesforce. With partner telephony or a bring-your-own-telephony setup, the partner's platform captures it and passes it across the integration. Either way, Salesforce receives the number rather than reading it off the wire itself. This matters for two reasons. First, the quality of the ANI depends on the carrier and the call path, so a small number of calls arrive with a blocked or missing number. Second, the format you receive (E.164, national, or raw digits) is set upstream, which is why normalising the value before any record lookup is so important.
ANI versus DNIS
ANI and DNIS answer two different questions about the same call. ANI is who is calling. DNIS, the Dialed Number Identification Service, is which of your numbers they dialed. A caller who rings your billing line and a caller who rings your sales line can share the same ANI, but their DNIS values differ, and that difference usually decides which queue they land in. Most well-designed routing uses both. DNIS tells the system which business function the customer chose, so the call starts in the right department. ANI tells the system who the customer is, so you can greet them by name, attach their history, or send a high-value account straight to a priority queue. One value sets the lane, the other personalises the trip. Keeping the two straight avoids a common design mistake: trying to route by ANI alone. ANI is excellent for identification and personalisation, but it does not tell you what the customer wants. Pair it with DNIS, menu selections, or the customer context you look up, and the routing logic gets much sharper.
Matching the ANI to a Salesforce record
The headline use of ANI is caller matching. When a call connects, Salesforce takes the incoming number and searches your data for it, then opens the matching record on the agent's screen as a screen pop. Configure Caller ID for your contact center controls this behaviour, and you choose which objects participate in the search. Out of the box the search covers standard phone fields on Contact, Account, Lead, and Person Account. A single clean match opens that record directly on the Voice Call. When several records share the number, which is common with shared household or office lines, Salesforce surfaces the candidates so the agent can pick the right one instead of guessing. The lookup is only as good as your data. If your phone fields are stored in mixed formats while the ANI arrives in E.164, the strings do not match and the screen pop misses a customer who is genuinely in your database. Standardising on one format, and deciding up front how to handle blocked or unknown numbers, is what separates a screen pop that feels magical from one agents learn to ignore.
ANI inside the IVR and routing flow
Before a human ever answers, the ANI can already be working. In the Amazon Connect option, a contact flow reads the caller's number from the Customer Number attribute and can branch on it. A typical pattern looks the caller up through a Lambda function that queries Salesforce, then offers self-service such as an order status or balance check tied to that account, with no agent involved. On the Salesforce side, routing is handled by an Omni-Channel flow assigned to the Voice channel. The flow can use the customer context derived from the ANI, the account tier, the open case, the product owned, to decide where the call should go. A recognised premium customer can skip the general queue and route straight to a specialist with the right skills. The important nuance is that routing decisions usually run on the looked-up context, not the raw ten digits. The ANI is the key that unlocks the record; the attributes on that record then drive the branching. Designing the flow around that lookup, rather than around the number itself, keeps the logic readable and easy to change.
ANI is identification, not authentication
It is tempting to treat a recognised ANI as proof of identity, and that is a mistake worth calling out. Caller numbers can be spoofed, phones get shared across a family or an office, and a number that once belonged to one customer can be reassigned to another. A matched ANI tells you who is probably calling, not who is definitely calling. Sound deployments use the ANI to start the conversation and then verify before exposing anything sensitive. That second step might be a PIN entered in the IVR, a voice-biometrics check, or a knowledge-based question the agent asks. The screen pop gives the agent context immediately, but account-level actions wait until identity is confirmed. ANI also feeds fraud signals rather than fraud decisions. Unusual patterns, a single number generating a flood of calls, or an origin that does not fit the customer's profile, can trigger extra verification or flag the interaction for review. Used this way, the number strengthens security as one input among several, instead of becoming a single point of failure that a spoofed call can walk straight through.
Format, missing numbers, and international calls
ANI does not arrive in one tidy shape. Depending on the carrier and the call path you might receive E.164 (the international format with a plus and country code), a national format, or unformatted digits. Salesforce Voice typically works in E.164, so the cleanest setup stores your Salesforce phone fields the same way. Mixed formats are the quiet killer of caller matching: the data is there, but the strings never line up, so the lookup returns nothing. Some calls carry no usable ANI at all. Callers who block caller ID, certain trunk configurations, and a few carrier edge cases produce a blank or withheld number. If your flow assumes an ANI is always present, those callers fall through to an agent with no context, which is exactly when a clear fallback path matters most. International calling adds its own wrinkles. The same subscriber can appear with or without a leading country code depending on where the call originates, so normalisation logic should reconcile those variants. Getting format, missing values, and country codes handled deliberately is what keeps ANI reliable across a real, global call volume.
ANI as a source of analytics and insight
Once the ANI has matched a call to a customer, that link becomes data you can analyse, not just a convenience for one agent. Because the Voice Call record carries the caller's number and connects to the matched Contact or Account, you can study call behaviour by customer, by segment, or by region over time. Einstein Conversation Insights builds on this foundation. With calls tied to known customers, the transcripts and outcomes can be segmented by account attributes, so you can see which customer types raise which issues and how those conversations resolve. The same linkage powers reporting on repeat callers, helping you spot customers who phone in again and again about the same unresolved problem. There is a privacy dimension too. The caller's number is personal data, and Salesforce Voice offers controls such as masking customer phone numbers so the full value is not exposed to every agent. A mature deployment treats the ANI as a useful but sensitive signal: valuable for matching, routing, and analytics, and handled under the same data-protection rules as any other piece of customer contact information.
How to act on the ANI in a Salesforce Voice contact center
ANI itself is delivered by your telephony provider, so you do not create it. What you configure in Salesforce is what the contact center does with that incoming number: which records it searches, what opens on the agent's screen, and how the call is routed. This is set up through Configure Caller ID and your Omni-Channel flow in a Salesforce Voice contact center.
- Confirm Voice is delivering the ANI
In a Salesforce Voice contact center, place a test inbound call and confirm the caller's number appears on the Voice Call. This proves the telephony provider is passing the ANI into Salesforce before you build any logic on top of it.
- Standardise your phone data
Decide on a single phone format (E.164 is the safe choice) and bring Contact, Account, Lead, and Person Account phone fields in line. Consistent formatting is what lets the incoming number match the stored number.
- Configure Caller ID matching
Use Configure Caller ID for your contact center to set which objects and phone fields the caller search covers, so a connecting call resolves to the right Contact, Account, Lead, or Person Account.
- Define screen pop and routing
Set the screen pop so the matched record opens for the agent, then build an Omni-Channel flow that uses the looked-up context, plus DNIS, to route the call to the right queue or skilled rep.
- Handle the exceptions
Add explicit paths for no-match, multi-match, and blocked or missing ANI, and add verification before any account-level action so a recognised number is never treated as proof of identity.
The standard objects whose phone fields the caller search can cover: Contact, Account, Lead, and Person Account.
The format your phone fields are stored in. Aligning these with the ANI format (typically E.164) is what makes matching reliable.
What opens for the agent on a match, the matched record or a screen flow, configured in the Omni-Channel flow.
The Omni-Channel flow that turns ANI-derived context and DNIS into a queue or skill assignment.
- Mixed phone formats are the top cause of missed matches: a stored number and the ANI must align (ideally E.164) or the lookup returns nothing.
- Never treat a matched ANI as authentication. Numbers are spoofable and phones are shared, so verify identity before exposing sensitive data.
- Some calls arrive with a blocked or missing ANI. Build a fallback path so those callers still reach an agent gracefully.
- Auto-opening one record on a shared line can surface the wrong customer. Let agents disambiguate when several records share the number.
Prefer this walkthrough as its own page? How to Automatic Number Identification (ANI) in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Configure Caller ID for Your Contact CenterSalesforce
- Service Cloud Voice Key ConceptsSalesforce
Straight from the source - Salesforce's reference material on Automatic Number Identification (ANI).
- Customize Call Routing in Salesforce VoiceSalesforce
- Get to Know Salesforce VoiceSalesforce
Hands-on resources to go deeper on Automatic Number Identification (ANI).
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Automatic Number Identification (ANI) deliver on an inbound call?
Q2. What does the CTI integration do with the ANI when a call connects?
Q3. Why is consistent phone-number formatting critical for ANI screen-pop matching?
Discussion
Loading discussion…