Integration of 1C-Bitrix with Bitrix24: automatic lead transfer

Lead transfer from Bitrix24 to 1C: where requests get lost

A website request reaches CRM in seconds — and that is often where the journey ends.

Next comes lead transfer to the accounting system, and it is at this junction that the chain breaks: the manager sees the inquiry, but neither an order, nor a counterparty, nor the correspondence history appears in the accounting database.

On the surface, the Bitrix24 and 1C integration is configured, the exchange runs on schedule, but some records never arrive.

The first typical gap is record matching. A lead arrives without the key that links it to a counterparty: the phone number is written in a different format, the email is in another field, the company name is entered differently.

The exchange picks up only new records, while changes to already created ones remain in place. When the connection breaks, the packet does not pass through completely, and a repeated run creates a second record for the same request — this is how lead duplicates appear.

The second gap is errors that no one finds out about. A required field is not filled in or a catalog is not matched — the exchange postpones the record and writes it to a log that no one reads.

The request formally exists, but it never reached accounting and surfaces a week later, when the client has already left.

When failures become regular, the team returns to manual request transfer: the manager exports a list, copies data, and creates the counterparty manually. This does not speed up the work but adds another source of discrepancies — lost requests continue at this step. Let's look at how this is closed.

What automatic exchange provides: speed and integrity

Automatic data exchange removes the manual link from the chain “website → manager → accounting system.” A handler on the 1C-Bitrix side sends the request to Bitrix24 at the moment the form is submitted, and reverse synchronization returns the deal status and responsible person to the card. The manager works with an already created deal instead of sorting through incoming emails.

Speed of request appearance in the accounting system

With batch export, a request sits in the database for up to half an hour: while the queue passes, while the manager gets to the email. With event-based exchange, the card appears in seconds, and response time starts counting from the moment the form is submitted.

The speed of request processing grows not because of “faster managers” but because there is no waiting — first contact in most cases happens within the first minutes.

How many inquiries stop getting lost

The second effect is data integrity. Each inquiry receives a matching key based on phone and email address, so a repeated request does not create a second deal but is attached to the existing card.

Duplicate cutting closes two typical losses: requests that failed when the accounting system was unavailable, and those lost during manual transfer from email.

Failed sends go to the exchange log with the error text — they are visible and can be sent again without asking the client whether they wrote at all.

Lead transfer: event-based or scheduled exchange

Lead transfer from a website on 1C-Bitrix to Bitrix24 can be solved with four schemes, and the choice between them determines delay, fault tolerance, and the volume of manual corrections. Below is a comparison of when each option is appropriate and where it starts to get in the way.

Event-based exchange and batch export

Event mode sends the lead at the moment the form is confirmed: the handler on the website side immediately creates a deal and contact in CRM.

Batch mode collects requests into a queue and sends them on a schedule — cheaper in terms of load, but the lead appears in CRM minutes or hours later.

Direct connection to the accounting database

Direct reading from the accounting database tables bypasses the standard exchange: it holds locks on records, breaks when the configuration is updated, and returns data from unfinished transactions.

This produces duplicate deals and lost requests, so we leave such a connection for one-time reconciliations, while routing the lead flow through an event with a key that prevents a repeated send from creating a second deal.

How we set up the exchange: from audit to launch

Request exchange breaks quietly: a request from the website goes out, but it is not in Bitrix24 — or it arrives twice and gets lost between responsible people.

That is why integration implementation follows a single order — from auditing data flows to handover to operation, where we verify every step before launch.

1. Data flow audit: collect all request entry points and record where each record should go.
2. Catalog inventory: reconcile users, sources, stages, and rejection reasons by codes in the two systems.
3. Field and status mapping: assign a destination, transformation rule, and default value to each field.
4. Exchange setup with duplicate protection by composite key and logging of every request.
5. Test run of the exchange on a database copy — production scenarios, repeated send, connection loss.
6. Discrepancy procedure and employee training: how to read the log and what to do with a request that did not go through.

Audit of request flows and catalogs

Most of the time goes into the audit: usually we find channels through which requests came around the accounting system — an old form, a department mailbox, a manager's correspondence.

We document field mapping in a table “source — destination — rule — requiredness”: it immediately shows which data is lost at the boundary.

Testing on a database copy and real scenarios

We configure the exchange not on the production database but on its copy: we run real scenarios, repeated transfer of one request, status change, and catalog edit. This way the exchange is tested on a volume close to production, and launch happens without stopping request intake.

What you keep: schemes, settings, procedures

After handover, you keep not a “working button” but a kit that lets you maintain, develop, and hand over the integration to another team — without digging through correspondence and engineers' heads.

• Integration documentation: where requests come from and go to, which fields are required, what happens with a duplicate or an empty phone number.
• Exchange scheme: request sources, intermediate queues, responsible services, and points where the exchange can be stopped without data loss.
• Support procedure: who responds to a failure and within what time frame, how the integrity of transferred requests is checked, and where to view the exchange log.
• Settings handover: export of rules, catalogs, and access rights with a description of what changes and where when a new channel is connected.
• Manager instructions: what is visible in the lead card, how to recognize an untransferred request, and where to report a problem.
• Checklist for adding a new channel: which test requests to run before launch.

Settings and field mapping rules

A separate table contains the mapping: which form field corresponds to which entity field, which values are filled in by default, and what to do with empty required attributes.

Duplicate search rules are written explicitly — by phone, email, or their combination — so that a repeated request does not create a second deal.

Procedure for actions during an exchange failure

Here, step by step: how to notice that the exchange has stopped, how to understand at which stage requests were lost, how to enable repeated transfer from the queue, and how to make sure no duplicates appeared.

Separately — the escalation order and contacts, as well as how to resume the exchange from the interruption point without recreating leads manually.

Case study: how manual request transfer between systems was eliminated

The project is a supplier of industrial equipment with a dealer network: a request from the website or email must reach both CRM and the accounting system, where an invoice and order are created for it.

There was no exchange between 1C-Bitrix and Bitrix24 — the manager transferred data manually and kept reconciliation using an email log.

Situation before implementation

Every request went through double entry: first a card in CRM, then the same contact and request composition in the accounting system. This took up to two hours a day for one employee, and it did not look like a problem until they started counting losses.

The discrepancy was not detected immediately: a request could be in CRM but not in accounting — the client received an invoice late or did not receive one at all.

The share of requests brought to accounting without manual intervention stayed around 60%, the average first response time was 4–6 hours, and every ninth deal came back with a repeated inquiry, “I already wrote.”

Result in numbers

We built event-based exchange: new request, change of responsible person, change in request composition, deal closure.

Each change goes to the adjacent system with a unique request key, so repeat cards are not created, and failed transfers go into a queue with a log and automatic retry instead of email.

After launch, the share of requests reaching accounting without manual intervention grew from 60% to 99.4%, first response time dropped to 15 minutes during working hours, and repeated inquiries due to lost requests fell from every ninth to one in forty. Two hours of manual operations per day were freed up for calls and work with dealers.

What to do if some requests bypass the exchange

Bypass request channels appear where inquiry intake is not the only one: a form on a subdomain, a separate telephony number, a messenger chat, an email to the sales department's shared mailbox.

Each such path creates a card on its own, the source field remains empty, and data desynchronization accumulates: duplicate contacts in the customer base, one deal on the accounting side, and a channel report that does not match any export.

Exchange diagnostics begins with reconciling logs: how many entities left one system, how many were accepted by the other, and at which step the timestamps diverge.

Then a test request is run through each channel — what identifier it receives, in what status it reaches accounting, and whether a duplicate is created by phone.

In a similar project, requests came from Bitrix24, telephony, and email, while the exchange with the accounting system accepted only the first point.

We consolidated the channels into a common intake and linked records by phone and email: the share of bypassing inquiries fell to isolated cases, and discrepancies in reports are closed with a weekly review instead of manually reconciling every deal.

Common technical questions about request exchange

Questions at the design stage of exchange between 1C-Bitrix and Bitrix24 concern not the request transfer itself but system behavior in abnormal situations: where the databases are located, what happens when the portal is unavailable, and who has the right to change matching rules. Below are short answers, and on a call we will go through each point using your configuration.

What happens to a request if the exchange channel is unavailable?

The request is not lost: it remains in the queue on the website side and goes to the portal on the first successful scheduled attempt. Repeated sending is protected by the matching key, so one request will not create a second deal.

The log shows how many records are waiting to be sent and when the last successful exchange occurred.

Where do duplicates come from and how do you close them?

Duplicates appear when a visitor submits the form twice or inquires from different sources. Before creating a record, the exchange checks the composite key — email, phone, and source — and if they match, it supplements the existing deal instead of creating a new one. Previously accumulated duplicates are closed with a one-time matching pass.

Who can change field matching rules?

The rules are stored in the exchange configuration, not in the portal interface, so they will not be accidentally overwritten. Changes are made by a designated role: an edit is tested on the test environment and only then transferred to production. Change history is preserved — you can see who changed the field mapping and when.

What data is sent when a request is transferred?

We transfer only what is needed to work with the inquiry: contacts, request text, source labels, and page link. Service and unnecessary fields are not duplicated. The data composition is fixed in the exchange description and changes only by agreement.

Let's discuss your request exchange scheme

To come back with a project estimate and implementation plan rather than general considerations, we need a minimum of input on your scheme.

Lead transfer almost always already works somehow — scheduled export, email to the responsible person, or manual transfer — and it needs to be analyzed before changing anything.

In the first conversation, we clarify:

• Request sources: website, forms, telephony, messengers, email — which channels are involved and which of them are currently lost or processed manually.
• System deployment environments: where the accounting system, website, and portal physically reside — on your own servers or at a provider — and whether there is direct network access between them.
• Matching rules: by what attribute to link a request with a contact and deal — phone, email, requisites, order number — and what to do on a match or an empty field.
• Reverse exchange: which deal statuses should return to the website and accounting system, who changes them, and how often.
• Critical scenarios: what is unacceptable to lose, what volume of requests passes per day, and how the system should behave when one of the parties is unavailable.
• Access and responsible persons: who on the customer side confirms changes and owns service settings.

Describe the task in free form — we will come back with a project estimate and implementation plan that includes the queue and redelivery scheme.