How Calls Are Matched to CRM Records

Overview

When a call arrives, it carries one piece of identifying information about the other party: a phone number. There is no concept of "who this call was with" in the incoming data — no name, no record type, no CRM identifier. Just a number.

This is not a limitation of the package. It reflects how phone systems work. A call from a given number is a call from a number. Whether that number belongs to a broker, an applicant, a supplier, or someone who dialled incorrectly is information that lives in your CRM — not in the call system.

Associating a call with a specific CRM record, or a specific type of record, requires matching that number against your data. And that matching is inherently unreliable.

The Ambiguity Problem

Phone numbers are not unique identifiers for people or record types in CRM data. Several common situations make reliable matching impossible.

One number, multiple records — The same mobile number can appear on a Contact record, an Account record, and a custom object record simultaneously. If a call arrives from that number, there is no way to determine which record it "belongs to."

One number, multiple record types — Organisations that use Contact record types may find the same phone number on contacts of different types. The same person might appear in multiple roles across different deals or relationships.

Shared and organisational numbers — Office switchboards, shared mobiles, and call-forwarding numbers mean a single phone number can represent many different people depending on who answers or who placed the call.

Numbers that change hands — Phone numbers are reassigned. A number that belonged to one person last year may belong to a completely different person today. A match on a number is a best-guess at the time of the call, not a reliable record of intent.

Unregistered numbers — Many calls will come from numbers that do not appear on any CRM record at all. There is simply no match to be made.

Any attempt to say "this call was with a [specific record type]" is a guess at best, and a misleading one at worst. The package does not make that guess.

How the Timeline Works Around This

The CallCore timeline component does associate calls with CRM records — but it does so at view time, not at sync time.

When a user opens a record page with the timeline component, the package:

1. Gathers all phone numbers associated with the record being viewed — from the record itself and from related records, depending on how the package is configured for that object type
2. Queries for call segments where the external phone number matches any of those gathered numbers
3. Returns the results scoped to what the running user is permitted to see

This is a calls involving numbers associated with this record query — not a calls that belong to this record statement. The distinction matters:

• The same call can appear on multiple record pages simultaneously, because the same phone number can be associated with multiple records
• There is no stored link between a call and any CRM record — the association is computed fresh each time the page loads
• The matching is scoped to the record being viewed, so each user sees calls relevant to the context they are working in

This approach gives contextually useful results without making false claims about record ownership. The call is not "owned" by any record. It is surfaced when the numbers match.

Why Salesforce Reporting Cannot Replicate This

Salesforce reports and dashboards are built on stored object relationships — lookup fields and master-detail fields written to the database when a record is saved. A report that filters calls by CRM record type requires an actual lookup field pointing from the call record to a Contact (or Account, or any other object). That field does not exist, and there are several reasons why it cannot simply be added.

There is no single right answer to store — A call from a number that matches three CRM records cannot be stored against all three in a single report row. Picking one arbitrarily would produce misleading data. Storing multiple would require a different data structure entirely, which Salesforce Report Builder cannot traverse.

The matching logic cannot be expressed in report formulas — The timeline applies phone number normalisation (converting numbers from local format to a standard international format), scope resolution (determining which related records to include based on the record being viewed), and permission filtering. None of this logic is available in Salesforce report formulas or filters.

Phone numbers on CRM records are not in a comparable format — Numbers stored on Contact or Account records are typically entered in local format. Call data arrives in a normalised international format. A direct field comparison in a report would find no matches.

The matching is inherently org-specific — Which objects hold phone numbers, and how they relate to each other, varies by organisation. The package can be configured to gather numbers from Contacts, Accounts, custom objects, or related lists. A fixed report join would only cover whichever objects the report was built for.

The result is that filtering or grouping call reports by CRM record type — or by any CRM record attribute — is not achievable through Salesforce's native report builder, regardless of what fields are added to the call data object.

What You Can Reliably Report On

The Call Activity Log records what is known about the call itself — facts that come directly from the call system and require no CRM matching. These are accurate and suitable for reporting:

Reporting on call volume, team activity, response rates, handle times, and inbound versus outbound patterns using these fields is reliable and accurate.

Attempting to join this data to CRM record attributes — record types, object types, deal stages, or any other field from your CRM — is not supported, for the reasons described above.