Why CallerID is not detected in Bitrix24
Incoming call number identification is a basic scenario: the phone rings, and in Bitrix24 the client card opens automatically with the history of inquiries.
When this does not happen, the operator spends the beginning of the conversation on manual search, and the call itself remains unattached to the deal. There are exactly three causes, and they repeat from implementation to implementation.
The first is a mismatch in number format. The PBX transmits the number in one form, the database stores it in another: with or without country code, with a city prefix or leading 8, with an extension separated by a hyphen.
Comparison is done by string, so two spellings of the same number are two different clients for the portal. It is fixed by normalization: a single rule for converting to international format for all channels plus separate rules for short and internal numbers.
The second is that telephony and the portal are not connected in one segment. The integration is configured, but a new direction, an additional purchased number, or a new employee remained outside routing — the call arrives, but there is nothing to attach it to.
The opposite also happens: inbound permissions are not granted, and the portal does not know which operator to route the call to and whose card should receive the history.
The third is loss of the original number during forwarding. When a call is transferred to another department or to a mobile phone, the card receives the number of the person transferring it, or the field remains empty.
The same applies to external forwarding through a telecom operator: an intermediate address reaches the portal instead of the client number, and the call lands on someone else's contact.
We analyze how this is closed: we compare formats along the entire call path, check the PBX-portal link for each number and employee, and run test calls through scenarios — new inbound, transferred, missed, and callback.
What changes after correct number identification
Number identification (CallerID) works at the junction of two systems: the provider transmits the calling number, and Bitrix24 matches it against the contact database before the operator picks up the phone.
If matching is configured, the client card opens automatically on a call — with deal history, the responsible manager, and recent inquiries. The conversation begins not with the question "who is this and what is it about," but immediately with context.
This changes three metrics at once. Inbound handling speed increases: the first seconds of the conversation are no longer spent on identification.
The share of missed inquiries falls because the call is routed to the person responsible for the deal rather than to a general queue, where whoever is available takes it.
A separate class of telephony failures disappears: inquiries accepted without attachment to a card and then not found in the pipeline; duplicate contacts with the same number in different formats; missed calls that no one knew about because the call did not create a task.
Stability rests on number normalization: a single storage format, comparison rules that take country code into account, and parsing of forwarded and internal calls.
Without this, the number arrives in a form that does not match the record in the database, and the card does not open — externally the setting works, but there is no effect.
Telephony connection methods and number identification
Number identification in Bitrix24 does not work on its own: first you need to understand how the call even gets into the system.
The chosen scheme determines whether the operator sees the client's name before picking up the phone and whether the number is written to the card automatically — or will have to be searched for manually.
There are four options, and they solve different tasks: from a quick start on a cloud line to preserving an already working fleet of devices. Below is a comparison by operating conditions and limitations that appear not during connection but in daily operation.
Comparison of connection schemes
| Option | When it fits | Limitations |
|---|---|---|
| Through a telecom operator | One office, calls to a landline number, quick launch needed | Number identification works only for this operator's lines; the set of services is determined by the provider |
| Own PBX and internal lines | Several offices, own extensions, transfers between employees | Requires a gateway and equipment maintenance; number matching is configured separately |
| Virtual line | Distributed team, work without desk phones | Dependence on channel quality; some phones are moved to software |
| Hybrid scheme | An own PBX exists, but some directions are more convenient to give to an operator | Diagnostics are more difficult: the number may be lost at the junction of two circuits |
We separately check what exactly the operator provides — a landline number, mobile, or extension. If the format differs from the system's expectations, number identification works partially, and this becomes clear on the first day on the line, not during setup.
Setup procedure: from line audit to verification
CallerID in Bitrix24 is not a checkbox in the number card but a link between three layers: the operator and PBX, the portal's telephony, and call routing rules.
A failure in any of them produces the same result — the manager sees "Unknown number" and loses the context of the conversation. Therefore we proceed in stages, and each ends with a verifiable result.
- Telephone line audit. We count numbers and extensions, clarify the operator and reception scenario: shared number, direct number, forwarding from mobile. We record exactly where the number is lost — at the PBX entry, during transfer to the portal, or already during routing.
- Call routing scheme. We draw the call path: number → line → queue → responsible person → card. We determine how hidden and transit calls are handled and where an unanswered call goes.
- Configuring the PBX-portal link. We register the line in telephony, set extensions and groups, and synchronize the employee directory. Separately, we compare the number recording format with how it is stored in contacts — otherwise client search will not work.
- Populating the card. We configure what the manager sees on an inbound call: a pop-up card, creation of an inquiry or deal, a task for the responsible person. For repeat calls — attachment to the existing contact so that history is not duplicated.
- Verification on real calls. We run through a checklist: a call from a known number, from a new one, from a hidden one, via forwarding, unanswered. We compare what the operator saw and what was recorded in the client card.
- Policy and handover. We provide the routing scheme, a table of lines and extensions, instructions for the portal administrator, and the procedure to follow if the number stops being identified.
Documentation, routing schemes, and policies
We hand over the work together with a package of documents: using it, telephony can be operated and developed without us.
We collect the materials during setup rather than adding them after launch — therefore the scheme describes the actual portal configuration, not project intentions.
- Routing scheme — inbound lines, queues, groups, transfer rules, and points where the client number is populated or lost.
- Number population rules — a mapping table: line and queue, displayed number, who changes it and under what conditions.
- Responsibility and permissions matrix — who on the client side can edit the rules, and for whom changes are available only through a request.
- Instructions for operators — what an inbound call looks like with an identified and unidentified number, what is visible in the card, and where to report a discrepancy.
- 1C integration map — where the client number is stored, how exchange delay affects identification, and what to do with new counterparties.
- Telephony failure policy — procedure, responsible persons, fallback communication channel, and logging of missed inquiries.
- Change log and rollback point — what changed and when in routes and rules, how to restore the previous configuration, and in what timeframe.
- Procedure for connecting new numbers — request, database check, test call, commissioning, and marking in the scheme.
We review the package on every change of routes or connection of a new line. Otherwise, the documents diverge from the settings and stop helping exactly when they are needed.
Case study: how a class of failures with number population disappeared
The client is a service company with two reception lines: sales and technical support.
Calls were received in Bitrix24, but the number was populated only for calls to a landline number — from mobile phones and after forwarding, the technical number of the telecom operator arrived.
The manager opened the conversation blindly, the share of missed calls during peak hours reached 18%, and answering took up to 45 seconds: this time was spent on manually searching for the client in the database.
What was restructured
Our engineers went through the chain from the provider line to the card: they enabled number identification (CallerID) on all inbound calls, added format normalization before contact search, described rules for forwarded calls, and created a directory mapping extensions to employees.
For cases when the number still is not identified, they defined a separate scenario: the call does not create a duplicate but is linked to the client's latest deal based on IVR data. The card with the number opens before the first ring.
After additional configuration, the share of missed calls decreased to 6%, average response time to 12 seconds, and calls without attachment to a card remained a fraction of a percent.
A side effect: contacts stopped being duplicated — one client equals one card, no matter which number they call from. The class of failures "unknown number on the phone" disappeared along with manual call reconciliation and requests to restore conversation history.
If CallerID is configured in Bitrix24 but the number is not populated
A classic case: a direct test call populates the card, but a working call does not.
Forwarding is to blame: when transferring to another employee, another branch, or a mobile phone, the operator provides the number of the last leg and leaves the original in a service field that Bitrix24 does not read when parsing the call.
Compare the operator's call detail records with the call log — a discrepancy in the number field will immediately show where exactly it was substituted.
Extension lines break attachment differently.
While the number is assigned to the office's external line, CallerID works on all legs; as soon as an employee is on an extension, the match must be built as a pair "external number + extension," otherwise some calls arrive without an owner. When transferring between offices, the extension loses its attachment first.
Several cities and numbers add another layer. Each external number needs its own inbound line and its own routing rule; when they are all dumped into one line, the card is populated based on the last caller and looks broken.
Separately check the format: leading 8, parentheses, city code — if the record in the database and the value in the call differ, the contact simply is not found.
Telephony diagnostics is built on three sources: the operator's call detail records, the call log, and the current attachment map. Then we run scenarios one by one — a direct call, through the IVR, from an extension, through forwarding to another city.
This shows the specific leg on which the number is lost, rather than "telephony does not work."
After adjusting the attachment map and normalizing formats, population works on all legs, including branches. All that remains is to fix the policy: what we check when changing operator, adding a number, or opening a new office.
Technical questions about number identification
Some doubts repeat on almost every project: in what form the number will arrive, what to do with multiple lines, how to make sure nothing broke after an update. Below are practical answers that usually resolve questions before work begins.
In what format does the incoming number arrive?
The PBX provides the number as the operator transmits it: with a country code and without separators, or in national form.
Therefore we configure normalization — we bring all variants to a single template; otherwise one subscriber is created in the database as two different cards and the call history breaks.
What should be done if there are several telephone lines?
Each line is matched with its own number and its own processing queue; routing is built by line and by time of day. Otherwise a call to the second line falls into the general queue, and the client waits for an answer from a department that is not relevant to them.
How can I check that number identification works after an update?
We run a control set: an inbound call from a mobile phone, an inbound call through a landline line, a missed call, and a transfer between employees.
We check the log to see whether the card was created, whether an already known client was matched, and whether the number was lost in an intermediate segment.
Does identification work for outbound calls?
When calling from the card, the number is populated automatically, and the conversation recording is linked to the client.
If the manager calls from the device directly, the attachment depends on whether the call goes through the integration — we check this scenario separately and describe it in the policy.
What if the number still is not identified?
The call is not lost — it goes into the general list without attachment to a card, and it can be processed manually. The log shows in which segment the number disappeared: the PBX, the operator, or the routing rule. This is the first thing we look at during analysis.
Let's discuss your telephony task
To discuss a telephony task substantively, we need source data on lines and reception scenarios. Using them, we reproduce an inbound call and see in which segment the number is lost or the label in the card is substituted. You do not have to collect everything at once — start with what you have at hand.
What to send for an estimate:
- Line scheme: operators, number of numbers, how they are set up in the portal — through a connector, forwarding from a landline, or a separate gateway.
- Reception scenarios: who answers first, whether there is a queue and extensions, where the call goes after business hours.
- Examples of numbers — three to five real inbound calls, including those where the subscriber's name is not identified or is shown incorrectly.
- Entry points: website, callback form, messengers, social networks, calls to employees' personal mobile phones.
- Access: portal administrator, telecom operator account, person responsible for telephony on the client side.
- Current routing rules and card label: whether the name, inquiry source, and responsible person need to be populated.
- Limitations: requirements for storing conversation recordings and personal data policy.
Using this data, we compare what arrives in the call event, check the match against the contact database, and come back with an implementation work plan and an estimate of setup timelines. Describe the task — if the scheme is incomplete, we will clarify what is missing ourselves.