Website enquiries stop reaching the CRM after an employee leaves. Or a new contractor gets access to the portal but cannot find where the connection to the accounting system runs. In both cases, the business faces the same problem: the integration exists, but nobody knows how to hand it over.
It is better to discover this dependency before a staffing change. Here is a practical plan for managers and administrators: list the connections, decide what to do with each one and verify the outcome using a clear example.
What the Bitrix24 system user provides
The Bitrix24 September overview, updated on 13 October 2026, covered the system user separately. The topic is useful for companies seeking to keep connected services running through team changes.
According to the official guide, this service account is created when a Marketplace application is installed or a departing employee’s active webhooks are retained. Associated integrations are listed under “Developers — Integrations.”
However, handing over the entire system may require more than one action in the portal. An external connection has its own components: a server, configuration, access to another system, an error log and someone responsible for support.
Consider a hypothetical company receiving website enquiries. Even if the CRM side remains connected, sending enquiries may depend on a website hosted by the previous contractor. The review should therefore cover the enquiry’s entire journey.
List the connections and their owners
Start with a simple register. For each connection, describe the business task it handles and how to tell whether it works. An application name rarely explains the consequences of disabling it.
Useful details include:
- the data source and destination;
- which records are transferred and what triggers the exchange;
- where the supporting code or external service runs;
- who manages payments, hosting and access;
- who receives error notifications;
- whom to contact when something fails.
Do not put secret URLs or keys in a shared register. Record their storage location and the person responsible for access instead. When handing over documents, separately check that the company has authorised access to the necessary materials and configuration.
Ask the departing specialist to talk through one normal workflow, from the customer’s action to the CRM record. This can reveal manual steps that are invisible in the list of connections.
Decide what to do with each connection
First determine which connections remain necessary, which need replacing and which should be disabled. Keeping everything automatically can leave forgotten connections running alongside useful ones.
The employee dismissal instructions describe the choice: disable webhooks or retain them under the system user. Retention preserves access through existing URLs. Consider who knows those URLs before deciding.
For an ongoing connection, agree how access will be managed. If a secret needs replacing, identify every place that uses it, the update sequence and the verification method in advance. Otherwise, some services may continue using the old configuration.
Do not restore a former employee’s login merely to fix an unknown dependency. First establish the specific cause of the failure and assign a specialist who can resolve it using agreed access.
Test the complete exchange and error handling
Prepare a test example with a known expected outcome for every important workflow. For instance, one test website enquiry should create one record in the correct pipeline, with the correct source and owner.
Check more than the existence of the record. Compare transferred fields, event time and record ownership, and check for unwanted duplicates. For two-way exchanges, test the reverse direction separately.
Include unusual situations where useful:
- sending the same event again;
- temporary unavailability of the external service;
- a change of owner;
- a missing required field;
- recovery from a failed transfer.
Run tests in an agreed environment without unwanted messages to real customers. The test scope depends on the specific integration: some capabilities need clarification from its developer, while missing mechanisms may require separate work.
Accept the handover and organise support
Before completing the work, agree who monitors the exchange and how the team will learn about problems. “Everything works” should be supported by tested workflows and an available diagnostic method.
Check plan and subscription conditions on the actual portal. For example, the Marketplace guide explicitly requires a subscription for REST API and webhooks in the ru zone. A company’s country of operation does not by itself determine its portal’s conditions.
A short checklist can close the handover:
- connections are listed and a decision made for each;
- necessary access has been checked;
- test workflows have passed;
- errors and limitations are documented;
- someone is responsible for support.
If the issue also involves pipelines and salespeople’s work, supplement the review with our article on CRM implementation mistakes.
To discuss the situation with QQDev, prepare a list of integrations, external systems and known failures. Contact us through the Bitrix24 audit page. This preparation helps distinguish configuration work from tasks that require restoring documentation or improving the exchange.