Bitrix24 business process setup: from simple to complex scenarios

Where business process setup in Bitrix24 breaks in practice

Business process setup in Bitrix24 almost always starts with a template that works on demo data: the start condition is described by a single field, stages match the policy, and responsible people are assigned manually.

In a live flow, the start condition is the first to fail — a request comes from a form, email, or messenger, and if the template checks only the source from CRM, the process does not start at all.

The request stays in the card without movement, and it is remembered only when the client calls again.

The second bottleneck is the responsible person.

They are hard-coded in the template as a constant, rather than through the 'deal owner' field or the department head, so approval gets stuck during vacation or dismissal: the task hangs in the 'pending approval' status, and no one sees that it has no owner.

Such tasks are found weeks later, deadlines are already missed, and the approval history is scattered across comments.

Then statuses diverge between departments. Sales move the stage in the deal, production runs its own smart process, and the warehouse has a separate list; there is no synchronization between them.

Manual data transfer between departments appears: export to spreadsheets, re-entering the same request, discrepancies in reports. The manager sees not the real deadline but the date someone entered manually.

Every such gap costs more than it seems: requests are lost, approval time grows, and reporting stops reconciling. We will look at how this is closed — from correct start conditions to a single request status.

Effects of automation: deadlines, failures, people's workload

The effect of process automation is measured not by the number of configured rules but by metrics: how much time a request takes from submission to closure, what share of routes pass without manual intervention, and how many requests are lost at department handoffs. Below is a checklist we use to compare the result before and after implementation on Bitrix24.

• Reduced approval time: the route is built by request type and amount, the task reaches the responsible person immediately — the path to a decision is measured in hours, and does not depend on who opens their email when.
• Transparent request statuses: the card stores the stage, owner, and time spent in it; the manager sees stuck requests without calling the assignees.
• Fewer manual operations: details are pulled from 1C, documents are generated from a template, and the record goes to the client card — re-entry and data transfer between systems are eliminated.
• Elimination of lost requests: an escalation rule raises the task higher if there is no response within a set time — a request cannot remain without an owner.
• People's workload: reminders, deadline control, and task distribution are handled by rules, while employees focus on meaningful work instead of reconciliation.

We take metrics in a limited environment before rollout and repeat them after launch: if approval time has not decreased, we rewrite the rule rather than leave it 'as configured.'

Comparison of automation approaches: what to choose for the task

Automation on the portal is assembled from four mechanisms, and the choice between them determines how much logic will later have to be rewritten.

Business process setup in Bitrix24 most often starts with robots and triggers: they fire on an event — stage change, task creation, new request — and cover linear rules without branching.

But as soon as a condition appears such as 'if the amount is above the threshold, we send it for a second round of approval,' the rule becomes overgrown with duplicates and stops being readable.

Four mechanisms and their boundaries

The route designer provides parallel sections, roles, and return points, but the limitations of the process designer should be known in advance: the set of blocks is fixed, nested logic is assembled with workaround templates, and support requires a person who remembers the purpose of each block.

If calculations, exchange with external systems, or a custom interface are needed, the logic is moved to a service or the portal is customized for the task.

In practice, the mechanisms are combined: event rules handle operational actions, the route handles approvals, and customization handles what cannot be expressed with ready-made blocks.

Comparing automation approaches comes down to one question: does the logic fit into standard elements, or will it have to be written?

Work order: from assessment to handover to support

When a process is assembled 'by feel,' it breaks on the first exception: the approver is on vacation, the request came back after a rejection, the amount exceeded the threshold.

That is why process implementation goes in stages, and each ends with a verifiable artifact — otherwise rework surfaces already in the production environment.

1. Assessment of portal processes. We analyze who the initiator is, who approves, and by what attribute the route branches — request type, amount, department. We separately record current workarounds: approval in a messenger, edits by email, 'called and agreed.'
2. Route diagram. We assemble a request approval diagram: steps, branching conditions, response deadlines, and behavior on rejection and return. You approve the diagram — edits at this stage take hours, not weeks of rework.
3. Setup. We transfer the diagram to the portal: stages, tasks, automatic actions, recalculation of the responsible person when an employee is absent, notifications, and printed forms.
4. Route testing on real data. We run not test 'Ivanov and Petrov,' but an export from your database: with real permissions, department nesting, and request statuses. We separately check rejection, return for rework, and restart.
5. Training. Role-based instructions — for the initiator, approver, and controller — plus a review of typical mistakes so the route is not bypassed on the very first day.
6. Handover to support. We provide the diagram, settings, permission matrix, and run log; we discuss which changes you make yourself and which go through customization.

What you keep: diagrams, policies, instructions

Business process setup in Bitrix24 ends not with launching the route but with a package of documents that the portal lives by afterward without us.

Without it, a month later no one remembers why approval goes in two steps, who has the right to change conditions, and what to do with a request stuck in the middle.

• Process map — which chains are automated, where each begins and ends, who owns the result at each step, and by what condition the request moves further.
• Route diagrams — a snapshot of configured scenarios: transition conditions, automatic actions, notification templates. They let you restore the logic even if the settings were changed not by us.
• Request handling policy — response deadlines at each stage, who receives escalation, what counts as overdue, and how to correctly close a request without a response.
• Employee access rights — a 'role — process — action' matrix: who sees only their own requests, who approves, who cannot skip a stage, and which administrators have the right to change settings.
• Employee instructions — step-by-step scenarios with illustrations: create a request, attach a file, pass it further, handle a rejection. With a review of typical mistakes that cause requests to get stuck.
• Portal process documentation — a single document explaining statuses, card fields, and roles. It removes discrepancies when a new employee reads a status differently from the process author.
• Change procedure — how an edit gets into work: a customization request, testing in a test environment and on a limited group, publication, and a rollback path to the previous route version.

All of this remains with you in an open form, not in correspondence with the contractor. Six months later, the process can be expanded or handed over to another team without reconstructing the logic from logs and employee surveys.

Case study: how request approval time was reduced

A manufacturing company with branches: procurement and repair requests went by email and messengers, and the portal on Bitrix24 was used more as a file storage.

Approval got stuck between managers — a request could wait a day until someone noticed it, and it was escalated by phone.

Metrics before and after

The route was split into branches: the request type and amount determine who approves, and each step has a deadline — when it expires, the task goes higher, and the initiator receives a notification. The decision history remains in the card; there is no need to search correspondence.

The results of implementation on the portal are a transparent queue: the manager sees what is waiting specifically for their decision, and policy-based reporting is collected automatically. Approval time decreased from a week to a day and a half and no longer depends on vacations.

Old requests are finalized in the previous route, new ones go through the new one — switching without stopping work.

How do business processes differ from robots and triggers?

A trigger and a robot are a reaction to an event. A trigger catches a condition: a deal moved to a stage, a reply to an email arrived, a list item was created.

A robot performs one action and completes; the pair has no state between runs: it does not remember the previous step and cannot wait.

A business process is a route with state. It is assembled from steps, each assigned to a responsible person, and can branch by conditions and stop while waiting: until the approver makes a decision, the next step does not start.

A step has a deadline, escalation on overdue, and history — you can see who acted and when, and where the route stopped.

The difference is in execution control. Robots answer the question 'what to do in response to an event' and do not store context between runs.

A route answers 'who, in what order, and by what deadline': it returns the document for rework, raises it to a higher level, and closes only after the final approval.

What to choose for automation: a linear scenario without a person — an event, one or two actions, a notification — is handled by robots, which fire instantly.

As soon as an approver, branching by request type or amount, or deadline control appears, a route is needed, while a robot starts the process and picks up the result upon completion.

A common mistake is assembling approval on robots: tasks are sent, but there is no way to return them for rework, and no execution history remains.

Common technical questions before starting

Before starting, the same doubts usually come up: will working routes have to be broken, what to do with approvals in email and spreadsheets, and how to connect external participants.

Approvals are happening in email and spreadsheets — what will happen to them?

We replace them piece by piece: approval becomes a task with a responsible person and deadline, the document becomes a card with versions instead of an attachment, and the spreadsheet becomes a process report.

Incoming email can remain a starting point: the email creates a request, and then the route continues inside the system.

How do we connect external participants without an account?

We provide limited access: the person sees only their own request and their own tasks. For those who do not log into the system, email and confirmation via a link remain — the response is recorded in the process even if it came by email.

Employees bypass the route — how is this closed?

Usually the reason is that the route is slower than an agreement in a messenger. Therefore we shorten the steps: remove unnecessary approvals, set deadlines and reminders.

The start is recorded in the system — a request outside the route does not move, and this is visible in the report.

Let's discuss the task and come back with an implementation plan

To discuss an automation task, you do not need to prepare a technical specification — it is enough to describe how the process goes now and show where it breaks. We will ask clarifying questions and assemble a draft diagram ourselves. To start, we need a minimum from you:

• a list of the process steps in their current form and who performs them at each step;
• roles and departments involved in approvals, and who can see what;
• examples of requests, emails, and documents that the process works with;
• integration points with 1C, email, telephony, and external services;
• constraints: policies, response deadlines, mandatory checks, and prohibitions;
• the criterion by which you will understand that the process works as needed.

In response, you receive an estimate of automation work: a process diagram with roles and transitions, a breakdown into stages, the scope of work for each, access requirements, and the rollout procedure.

This is not 'a single figure for the whole project' — you can see how long setup takes, how long testing on real data takes, and how long migrating historical requests takes. We separately note what depends on related systems and what can be launched independently.

The first step of implementation is analyzing one process with an engineer and a draft diagram based on its results. Then we approve the process implementation plan by stages and start with the area that delivers the effect fastest. Describe the task — we will come back with an estimate and a plan.