Why 1C and Bitrix24 exchange configuration breaks in the HR loop
Configuring the exchange between 1C and Bitrix24 in the HR loop breaks not because of a "bad product," but because of data discrepancies that accumulate unnoticed.
A classic failure: in 1C:ZUP an employee is transferred to another department, but in Bitrix24 they remain in the old structure — and requests, approvals, and access rights go to the wrong managers.
The org structure desync accumulates for months until someone discovers that half the team is listed in a non-existent department.
The second common cause is duplicate employees. 1C ZUP synchronization pulls a record by employee ID or SNILS, and if the key in the database has changed or the person was created manually, the system creates a second card instead of updating the existing one.
Then come manual edits: someone fixed the department directly in Bitrix24, the next exchange overwrote the change — and the automation failed again.
The third layer is the exchange queue. With a large number of employees and frequent HR events, jobs pile up, some fail with an error and remain stuck. The exchange is formally "enabled," but the data in Bitrix24 lags by days. Let's break down how this is resolved through configuration without manual intervention.
What correct integration delivers: the effect in numbers
The effect of integration is measured not by "convenience" but by how much manual input leaves the process and which class of failures disappears.
Before the exchange, an employee record is created in the accounting system and again in Bitrix24: two sources of truth, a discrepancy in department and position, duplicates upon rehiring.
After configuring the exchange between 1С and Bitrix24, data flows in one direction — from the accounting system to the portal, and manual input is reduced to zero for standard events: hiring, transfer, salary change, termination.
1С:ЗУП remains the single source of truth for HR data, while Bitrix24 is the working environment where this data is needed every day.
The matching rule by external identifier rather than by full name eliminates duplicates: rehiring the same person updates the existing record instead of creating a second one. This is the elimination of a class of failures, not a one-time cleanup of the directory.
The speed of onboarding directly depends on how up-to-date the data is. As long as the account, department, manager, and access rights appear on the day of starting, the new employee does not sit idle waiting.
Event-based exchange rather than a once-a-day schedule reduces the delay to minutes — the status in the portal matches the order rather than lagging a day behind it.
Reverse synchronization is also needed: vacation requests and absences submitted in the portal are returned to the accounting system, and the HR specialist does not transfer them by hand.
An exchange log with logs for each record enables analysis: you can see what was sent, what was rejected, and why — the discrepancy is caught at the input rather than during reconciliation at the end of the month.
Methods of data exchange between 1С:ЗУП and Bitrix24
The standard synchronization module 1С:ЗУП ↔ Bitrix24 covers the typical scenario: employee directory, org structure, hires and dismissals, absences. It works on a schedule, is configured through field mapping and export rules, and does not require a separate server.
The limitation is that extending the logic for non-standard fields and custom entities is difficult, and with large volumes the scheduled job starts competing for resources with accounting operations.
An intermediate database removes this limitation: 1С exports data to a separate environment, and Bitrix24 pulls it from there in batches and at a convenient pace. This option is appropriate when you need to enrich data from multiple sources or store a history of changes. The price is an additional node that must be maintained and reserved.
File exchange remains a workable solution for small environments and infrequent exports: a scheduled job generates a file, and the other side picks it up. Simple, transparent, easy to debug manually.
The limitations are predictable — no delivery guarantee, edit conflicts are resolved manually, and as the number of entities grows, confusion over file versions appears.
A service bus is needed when the exchange stops being a single pair of "1С — portal": multiple systems, different formats, requirements for logging and redelivery of messages.
The bus provides unified routing rules and decouples the sources, but this is already a separate infrastructure layer with its own cost of ownership.
| Option | When it fits | Limitations |
|---|---|---|
| Standard module | Typical exchange of directories and HR events | Difficult to extend for non-standard fields, competition for 1С resources |
| Intermediate database | Multiple sources, need for history and data enrichment | Additional node to maintain |
| File exchange | Small environment, infrequent exports, simple debugging environment | No delivery guarantee, manual conflict resolution |
| Service bus | Many systems, different formats, logging requirements | Separate infrastructure layer |
The choice is determined not by the fashionability of the approach, but by the number of sources, the frequency of changes, and fault-tolerance requirements.
In practice, most often they start with the standard module, and move to an intermediate database or a bus when a second or third data consumer appears.
How we build the exchange: stages of work
Exchange between 1С:ЗУП and Bitrix24 almost never comes down to "turning on the integration": each system has its own structure of reference data, and without a preliminary audit, data begins to duplicate or diverge already on the first run.
That is why we carry out the work in stages — from analyzing the current state to handing over the support regulations.
- Audit of reference data and current exchanges. We look at which departments, positions, schedules and employees are already set up in 1С:ЗУП and Bitrix24, where there are duplicates, where there are discrepancies in names, which exchanges are already configured and on what schedule.
- Designing the mapping scheme. We determine which object in 1С corresponds to which one in Bitrix24, who is the source of truth for each field, and how departments and positions are matched when the spelling differs.
- Configuring exchange rules. We form the rules for export and import: which fields are transferred, what is updated when changed, what remains read-only, and how new and terminated employees are handled.
- Test run on a copy. We run the exchange on a test environment with the real structure, but without risk to production data — this way we catch reference data conflicts before they reach production.
- Verification on real data. We launch the exchange in the production environment, reconcile employee cards, departments and access rights, and check the behavior when adding, transferring and terminating employees.
- Handing over the regulations. We record the exchange schedule, the procedure for actions in case of failure, the persons responsible for reference data and the rules for manual edits — so that support does not turn into a one-off call to an engineer.
Each stage ends with a result that can be verified: a completed mapping scheme, a run log, a reconciliation of cards. This allows launching the exchange without stopping HR processes and handing the system over to support with clear rules.
Access policies and roles in HR data synchronization
Exchange between the accounting system and the portal is always a question not of "how to transfer" but of "who has the right to see and change." If permissions are not separated, exporting the staff list drags along extra entities, and changes in reference data go both ways without control. Below is a set of settings that we check before launching the exchange.
- Synchronization roles. A separate service user with the minimum necessary set of permissions: reading reference data, writing to target entities, without access to administrative sections of the portal.
- Separation of permissions for reference data. Employees, departments, positions, and schedules — read-only for export; manual editing is closed, there is a single source of truth.
- Access policies for personal data. Field visibility (passport, address, contacts) is restricted by role: HR sees the full set, managers see only work-related attributes.
- Change logging. Each synchronization writes a log: who initiated it, which records were created, changed, or marked for deletion, and what was rejected due to a conflict.
- Conflict handling. A rule for side priority when fields diverge — so that parallel editing does not silently overwrite data.
- Consent to personal data processing. We record the basis for the export and the retention period, so that the set of fields matches the stated purposes.
- Access revocation procedure. Upon termination or a role change, portal permissions are reviewed the same day, not upon request.
These checks close typical risks: leakage through excessive permissions, "silent" overwriting of HR data, and the absence of a trail when investigating an incident. We configure them before the first production export — reworking policies on live data costs more.
Case study: eliminating duplicates and desynchronization at a large company
What it was like before the project
A company with a distributed structure — several legal entities and more than a thousand employees — kept HR records in 1С:ЗУП, while approvals, hiring requests, and onboarding were handled in Bitrix24.
There was no connection between the systems: an HR specialist would enter an employee into the accounting system, then manually duplicate the card on the corporate portal, and transfer changes for transfers and vacations in separate emails.
At peak load, this produced up to 30% discrepancies in the directory: a terminated employee remained active on the portal, while a newly hired one waited several days for an account and access to tasks.
What was changed
We separated the data flow by ownership: 1С:ЗУП remains the source of truth for HR events, Bitrix24 — for organizational processes.
The exchange was built on regular automatic transfer with an unambiguous matching key — the employee ID and internal identifier — so a repeated export updates the existing card rather than creating a second one.
Version conflicts are resolved by source priority: an edit in the accounting system overrides an outdated value on the portal, not the other way around.
Terminations and transfers were handled separately: an event in the accounting system triggers a chain on the portal — access blocking, task reassignment, and a change of manager in the org structure.
Exchange errors are not lost: discrepancies go into a log, through which an HR specialist can see which record failed and why.
What the result was
The directory stopped duplicating: discrepancies dropped from 30% to isolated cases that are resolved individually.
Onboarding a new employee accelerated from several days to one business day — accesses and tasks appear together with the HR event, rather than after back-and-forth messaging.
The load on the HR service decreased: manual card entry and list reconciliation are no longer part of routine tasks, freeing up time for hiring and onboarding.
We ran the project on Bitrix24 in conjunction with the client's accounting system — without replacing familiar tools and while preserving historical data.
How does exchange via the built-in module differ from an intermediate database?
The built-in exchange module is a connector that publishes 1C:ZUP data directly to Bitrix24 on a schedule or by event. It works "head-on": a change in an HR document initiates an export, and the portal receives a ready record about an employee, department, or absence.
The scheme is simple, is implemented quickly, and does not require a separate server — hence its popularity at the start. The limitation is that the exchange runs synchronously: if the portal is unavailable, the session breaks, and some records may not arrive.
Diagnosing such gaps is difficult — logs live on two sides, and figuring out exactly what was lost has to be done manually.
An intermediate database is a separate contour that pulls data from 1C and delivers it to Bitrix24 asynchronously, via a queue. If the portal goes down or responds slowly, the export is not lost: it waits in the queue and is retried according to retry rules.
That is why such a scheme provides predictable synchronization reliability where the built-in module starts "spitting out" errors — with large volumes, frequent changes, and multiple data sources.
The difference shows up in four dimensions. Speed: the built-in module is faster at small volumes, the intermediate database — at growing ones, because it loads data in batches and does not block the accounting system.
Failure resilience: the connector depends on the portal's availability at the moment of export, while the intermediate contour survives outages and catches up on the backlog.
Support complexity: the built-in module is simpler at the start, but during failures it requires manual investigation; the intermediate database is more complex to set up, but it provides an exchange log, retries, and a clear point of failure.
Infrastructure requirements: the connector needs only the portal itself, while the intermediate database needs a separate service and space for the queue.
The choice is not binary. At the start, with one source and a small staff, the built-in module gets the job done.
As soon as branches, several legal entities, or requirements for auditing HR changes appear — the intermediate database pays off because supporting the integration stops being manual work.
We set up both options and, at the assessment stage, show which of them will withstand your load profile.
Common technical questions about configuring integration
1C:ZUP and Bitrix24 integration is almost never deployed "from scratch" — more often it is embedded into an already running environment, where some employees are created manually and some come from the HR system.
That is why the first questions are always about compatibility, migration, and rollback, rather than the synchronization mechanism itself. Below are the things that most often come up during the assessment stage.
We already have a configured integration — will it have to be redone from scratch?
No. First, we capture the current scheme: which entities are synchronized, by what attribute records are matched, and what discrepancies have already accumulated.
Then we either extend the existing integration rules or migrate them to new matching logic — without stopping the portal. Cards already created manually are linked to records from 1C by an external key so as not to create duplicates.
What should be done when there is a version conflict between the integration module and the platform?
A version conflict is the most common reason why integration "stalls" after one of the sides is updated. We pin down a compatible combination of module and platform versions, test it on a database copy, and only then move it to the production environment.
If an update breaks the rules, we roll back to the previous combination, and the integration continues to run on the old rules until the discrepancy is resolved.
Can integration rules be updated without stopping synchronization?
Yes, with the right rollout order. We test new rules on a staging environment using a data copy, then enable them for part of the employees and verify the result.
The full switchover is done during a window of minimal activity — the queue is not lost, and unfinished operations are replayed after the switch. This way, updating the rules does not turn into several hours of downtime.
What happens to the integration if 1C or the portal is unavailable?
The integration does not "lose" data: changes accumulate in a queue on the source side and are sent once the connection is restored. We configure retries and notifications to the responsible person if the queue is not processed longer than a specified threshold.
This way, a failure on one side does not turn into a discrepancy that later has to be sorted out manually.
Let's discuss your 1C and Bitrix24 integration task
To come back with an estimate and a plan rather than generalities, we need your current landscape: which systems are already running, where employee records are kept, how the org structure, orders, and schedules are organized.
Setting up 1C and Bitrix24 exchange is not "turning on a connector" but reconciling reference data, access rights, and mapping rules, so the estimate depends on the state of the data no less than on the volume of code.
Describe the task — we will come back with a work plan, timelines, and team composition. This creates no obligations: first we understand your environment, then we propose a solution.
What is worth including in the task description:
- Which systems are in the environment: 1C:ZUP, Bitrix24, corporate portal, HR records — and what should exchange with what.
- Exchange direction: employees and org structure, orders and vacations, recruitment requests, onboarding of new hires.
- Data volume: number of employees, departments, frequency of changes, peak periods such as mass hiring.
- Current state: exchange is already partially set up, done manually, or absent; what errors and discrepancies are already observed.
- Requirements for access and permission separation: who sees HR data, whether synchronization with the domain is needed.
- Constraints: personal data regulations, security requirements, windows when exchange must not interfere with work.
- What you have already tried and why the result was unsatisfactory — this saves the diagnostic stage.
Based on this, we determine the HR integration scheme: which entities are synchronized, where the source of truth is, how conflicts are resolved when a record is changed simultaneously.
Then — exchange support: error monitoring, retries, logging, so that a discrepancy is caught before accounting reports it.
Describe the task in free form — we will come back with an estimate and a plan.