Automation of employee termination in Bitrix24

Setting up termination in Bitrix24: where the process breaks

Termination in Bitrix24 starts not with the employee card but with a message in the messenger: “Petrov is leaving, disable access.” After that, everything lives in correspondence, and this is the first break point—the event has no initiator, status, or deadline, so no one checks whether it reached completion. Some steps are silently forgotten, and some are performed halfway.

The second point is access. The account is set to “terminated,” but active sessions and the mobile app remain working until their natural expiration.

Participation in groups, invitations to the external portal, subscriptions, and shared drive rights are preserved—and data continues to go to external addresses after the person has already left the premises.

The third point is unfinished cases. Tasks where the departing employee was the creator or responsible person hang in “in progress” status; robots and automation rules tied to them stop triggering, while their deadlines continue.

Documents and contracts remain without an owner, the successor has no rights, and support handles requests manually, reconstructing history from correspondence.

The fourth is the link with the accounting system. As long as the employee is listed as active in 1C, synchronization will return them to the portal after manual deactivation.

We explain how this is closed: where a single launch point for termination is set, how access revocation is controlled, and how the handover of cases and documents is completed before account closure.

What changes in the service after automation

After automation, termination stops being a chain of manual assignments. An event in the employee card launches a scenario: revoke rights, close active sessions, forward mail, transfer cases to the manager. We break down what changes in measurable terms.

Access closure time

From application submission to account blocking and rights revocation takes 15–30 minutes instead of a day. The scenario is assembled on Bitrix24 business processes and does not depend on which admin is on shift—the bottleneck “waiting for the right person” disappears.

Share of manual operations

About eight out of ten manual actions leave the process: creating requests, reconciling the list of rights across services, emails to support for external systems. The engineer gets involved only where the system cannot complete a step itself, and immediately sees which one.

Failure class that gets closed

The main failure class is residual access: the account remains after departure, and no one revokes rights in external services. Every action is logged, so an audit shows what and when was disabled rather than reconstructing the picture from emails.

Handover of cases to a new employee

Cases are handed over on the first day: requests and files are forwarded, correspondence history and attachments are in shared space, access is granted by role template. Onboarding into work takes hours instead of a week of approvals.

Modes of bypassing tasks during termination: comparison of approaches

When an employee leaves, they leave behind tasks in progress, approvals, and issued access. The process cannot be stopped entirely: some tasks have already been accepted by contractors and have deadlines, and some are tied to external counterparties.

Therefore the bypass mode is chosen not “for convenience” but based on where tasks physically reside and how uniform they are.

The choice is dictated not by company size but by the share of tasks outside the portal. If almost everything is in the portal, a standard business process with a robot at the entry point is enough.

As soon as external systems and non-standard roles appear, modes are combined: the list covers exceptions, robots and integrations cover the regular flow.

Implementation stages: from account audit to handover

The order of stages here matters more than speed: rights and responsible persons are inherited between entities, and if they are disabled in arbitrary order, some access remains as a “tail”—the account is closed, but invitations to calendars, external services, and subscriptions continue to work. Therefore, we set up termination in Bitrix24 as a sequence with a verifiable result at each step.

1. Audit of accounts and rights. We collect an inventory: which entities are tied to the employee—profile, email, groups and departments, tasks and projects, owned deals and leads, shared drives, external integrations. The result is a table “employee — resource — owner — action upon termination.”

2. Approval scheme. We determine who initiates the process, who confirms, where the point of no return is: manager, HR, information systems responsible. We record which steps run automatically and which require explicit confirmation.

3. Scenario setup. We assemble the business process: launch event, stages, transfer of tasks and clients to another employee, auto-reply to emails, scheduled login blocking and access revocation, archiving of correspondence and files.

4. Test termination run. We run the scenario on a dummy employee with the same groups and rights as a typical departing employee—this shows the real process branches, not theoretical ones.

5. Check completeness of deactivation. We go through the checklist: login, active sessions, external services, subscriptions and mailing lists, tasks without an assignee, documents with open links.

6. Handover of the regulation and training of responsible persons. We provide the process diagram, launch and rollback instructions, the procedure for failures, and review real cases with employees.

After handover, for the first weeks we keep an operations log—it shows which steps worked automatically and where a person intervened, and serves as the basis for targeted adjustments.

Package of documents and configurations at delivery

At delivery, the customer receives not an oral report but a set of artifacts that HR and support use without our involvement.

Each document is tied to the actual portal settings: if the department structure or access rules change, this is reflected in the text rather than left in the memory of the engineer who performed the implementation.

• Integration map — which systems participate in the termination process, in which direction data flows, and what happens if one of them is unavailable.
• Access rights matrix — the link “employee role — portal groups — drives, calendars, chats” with a note on what is revoked upon termination and what remains with the manager.
• Access closure regulation — procedure with control points: when the process starts, who confirms, at what point the account is blocked.
• Instructions for HR — which card fields are mandatory, how to launch the scenario manually for an unscheduled termination, and where to look if a step did not execute.
• Instructions for support — how to read the log, which errors are standard, which to forward to us, and what is allowed to be edited without a developer.
• Check log — control scenarios (termination during vacation, transfer between departments, employee return) and the frequency of running them after portal updates.
• Procedure for edits without us — where configurations and templates are located, how to change access rules and approval routes so that a portal update does not overwrite them.

We deliver the package alongside the portal—in the knowledge base, with versions and the date of the last reconciliation.

Case: how access closure time was reduced

Termination proceeded by email to HR, and then along an approval chain: manager, HR, security service, administrator, plus two more confirmations.

While the request took three business days, the terminated employee retained access to the corporate drive, CRM, and internal chats, and no one picked up their open tasks—some simply fell out of the department’s work.

We rebuilt the process around the employee card status in Bitrix24: the HR specialist changes it to “Terminated,” and then a single scenario launches without manual emails.

One approval remained—the manager confirms the set of access rights, after which robots process the queue: email, drive, CRM, remote access, groups, and mailing lists are disabled in parallel, and open tasks are reassigned to the deputy while preserving correspondence history.

Metrics before and after

• Approvals per termination: 6 → 1.
• Full deactivation time: 3 business days → 40 minutes, including the backup service.
• Lost tasks during handover: 11 out of 20 → 0.
• Share of terminations closed without manual reminders: 68% → 100%.

If a service does not confirm deactivation within 15 minutes, the scenario escalates the task to the on-duty engineer—access does not remain “hanging” silently.

Access reporting

For each termination, a log is compiled: employee, set of closed access rights, time of each deactivation, responsible person, and a link to the original request.

The export is generated automatically and goes to a regular reconciliation—if access is found open, it appears in the report as a discrepancy and is closed again with the reason recorded.

What to do if access lives in different perimeters?

Some accounts live outside the common directory: local accounting database, warehouse system, file storage, office access, and corporate communications. Each keeps its own records and is blocked in its own way—from an integration call to a manual edit in the admin panel.

Different account perimeters are brought into one launch scenario.

Termination is initiated by a business process in Bitrix24, which for each perimeter calls its own handler: an integration, data exchange, or a task for the responsible person if the system has no automatic interface.

A single launch point is needed not for the tidiness of the scheme—one event instead of seven separate emails eliminates the scenario “access was closed, but the warehouse was forgotten.”

The unified list is stored in the same place: a smart process or list where each system has a row with the deactivation method, responsible person, deadline, and criticality flag.

This list becomes the source of truth—the scenario is built from it, and it also shows what has actually been disabled and what is stuck in approval.

The list of forgotten systems is collected through an inventory: login logs for past periods, active network connections, an onboarding survey—“what else was issued at onboarding.” Then the rule applies: a system is not put into operation until it is entered into the registry with a deactivation handler.

Where there is no automation, the scenario assigns a task to the responsible person with deadline control, and uncompleted items are escalated to the manager.

Local systems stop falling out of the process, and forgotten ones surface at the next employee’s onboarding—before they are used.

Frequently asked technical questions about access and timelines

Before starting termination setup, customers and HR ask the same questions. Below are short technical answers: they determine how the scenario is assembled and what will be included in the regulation.

How do I schedule the launch for the last working day?

A delayed start is tied to the date from the employee card, not to the moment the application is submitted. The scenario will trigger on the required day even if the order is drawn up in advance.

How is vacation followed by termination handled?

The date is taken from the order, not from the last day of vacation. Access is closed at the end of vacation, and cases and tasks are handed over before it begins.

Who receives notifications, and is confirmation required?

Notifications go to the manager, HR, and the person responsible for assets. We configure handover of cases and rights revocation with confirmation—the scenario will not close access ahead of time.

What should be done with systems that have no standard connection to Bitrix24?

For them we use intermediate handlers and scheduled tasks. External services and local databases are disabled in the same order as the main account.

Let's discuss the task: preparation for scenario launch

To come back with an estimate and plan rather than general words, we need a short introductory snapshot of your environment. Usually it takes one conversation or chat—after that we review the systems ourselves with test access and clarify details. Please gather what you already have at hand.

• Request for estimate — what exactly should happen automatically: full access closure, transfer of tasks and files, generation of the order, or the entire chain end to end.
• List of systems and roles — where the employee has accounts (portal, accounting system, email, file storage, cash desks and warehouses), who initiates termination, who approves, who confirms.
• Current termination procedure — how it works today: which steps are manual, who performs them, at which stage requests are most often lost and active access remains.
• Access limitations — which accounts are administrative, where there is no software interface and an operator is needed, whether you can provide us with a test environment with anonymized data.
• Data handling rules — what is transferred to the manager or colleague, what goes to the archive, what is deleted according to the regulation and after what period.
• Timelines and testing window — when the scenario can be run on a test employee to see the result before launching on real people.
• Acceptance of the result — who on the customer side accepts the work and by what criteria: the terminated employee cannot log in to systems, tasks are redistributed, documents are available to the successor.

If there is no answer for some points yet, send what you have. We will close the gaps on a call; they do not prevent starting the estimate.