WhatsApp in Bitrix24: what actually gets created in your portal

Most integration pages tell you what a product does. This one tells you what it creates inside your portal, by name, so that you can decide whether you want it there before you install anything — and so that you can find it afterwards.

Four things are registered in a Bitrix24 portal when ChatBridge24 is installed. Every one of them is visible in the portal, every one can be inspected, and three of the four are re-asserted automatically whenever an administrator opens the app.

1. An Open Channel connector, saabsoft_wa

The connector is what makes WhatsApp appear in Contact Center → Open Channels as a channel you can bind to a queue. Once a number is bound, inbound WhatsApp messages arrive in the Open Channel, an agent replies from Bitrix24’s own messenger, and delivery and read receipts travel back.

Two properties worth knowing:

• A number is bound to an Open Channel explicitly, by you. Installing the app registers the connector; it does not route anything. Binding changes how leads are created and how conversations are assigned, so it stays a decision rather than a default.
• Open Channels is optional. A large share of customers use this product as a WhatsApp inbox and an automation engine and never bind a channel at all. If you do not want WhatsApp conversations in your CRM, you do not have to have them there, and nothing degrades.

2. A tab on every CRM card

Four placements are registered: the detail tabs of Lead, Deal, Contact and Company. Each adds a WhatsApp tab to that card, in which an agent can read the thread and reply without leaving the record.

The matching is worth describing because it is where integrations usually go wrong. A CRM card is matched to a WhatsApp thread in three ways, in order: the Open Channels identifier stored on the record, a link we previously resolved and wrote back, then the phone number.

The tab runs the CRM lookup as the signed-in agent, not as the application. The record id arrives from the browser, so portal scoping cannot be what authorises it: Bitrix24’s own CRM permissions are the only thing that knows whether this agent may read that lead.

3. An automation robot, “Send WhatsApp message”

The robot appears in the automation designer for Leads, Deals, Contacts, Companies and Smart Processes, so a rule can send a WhatsApp message as a step.

This is the only unattended send path in the product, which is why it carries more guard-rails than anything else:

• Who is addressed is one field, and an empty one refuses. The “Send to” field is the only statement of the recipient. If it is empty, the step refuses and writes the reason on the record’s timeline — it does not fall back to the record’s own phone number.

• Every outcome writes a CRM timeline entry, including a refusal. A rule that refuses every run used to look, from inside Bitrix24, exactly like a rule that was not running. The reason lived in a log nobody opens.
• Caps in two scopes, counted in SQL. Per portal and per WhatsApp number, with the per-number cap being the one that matters: WhatsApp bans handsets, not tenants. Failed sends count, because a rule whose sends all fail is the dangerous case.
• A consecutive-failure breaker per number, cleared by an administrator.

4. Event handlers

The app binds handlers for the events it needs — an agent’s reply in the Open Channel, an application update, an uninstall. These are matched by event name, so re-asserting them is safe and idempotent.

What is not created

As important as the list above, and shorter:

• No custom fields on your CRM entities. If an inbound WhatsApp conversation creates a Lead or a Contact, it fills Bitrix24’s own fields — the native phone multifield and the Open Channels identifier — and nothing of ours.
• No users, no groups, no workflows of our own.
• Nothing on a card we did not match. A group chat never creates a CRM record at all, which deserves its own paragraph.

Why a group chat creates nothing

A WhatsApp group with forty participants, pushed naively into Open Lines, becomes forty contacts and forty lead candidates — and because Open Lines matches on phone number and creates a record when it misses, the first participant to speak would own all of it.

So a group is modelled as one Open Channel chat with no phone number attached, the roster is kept separately, and participants are not turned into contacts. Somebody becomes a contact by messaging the business directly.

How to inspect all of it yourself

Everything above is visible without our help:

1. Contact Center → Open Channels — the ChatBridge24 channel and which of your numbers is bound to which queue.
2. Any Lead or Deal — the WhatsApp tab, and whether the thread it shows is the one you expect.
3. CRM → Automation → the designer — the “Send WhatsApp message” step, and every rule that uses it.
4. The app’s own Automation page — a run log with one row per outcome, including every refusal and the reason for it.

The two transports, in one paragraph each

Official Cloud API. Meta’s own interface. Approved message templates, the 24-hour reply window, per-message pricing, and — the practical difference most people notice — it returns the customer’s phone number properly.

QR pairing. Your existing WhatsApp number, linked the way WhatsApp Web links it. No templates, no window, group chats work; and it is an unofficial client, so the number carries a real ban exposure on high-volume outbound to non-contacts, and WhatsApp increasingly withholds a contact’s phone number from a companion device.

Both run through the same inbox, the same connector, the same CRM tab and the same automation robot. Which one you want is a question about templates, groups and risk, not about features.