Custom Bitrix24 robots: when standard scenarios are not enough
Standard robots and triggers in Bitrix24 cover linear scenarios: change the stage, create a task, send an email from a template.
As soon as the deal logic grows conditions — discount approval based on the amount and customer segment, recalculating the payment schedule, assembling a document package from several entities — the builder hits its ceiling.
Custom Bitrix24 robots appear exactly where the standard ones fall short, and they close the gap between "almost automated" and a real process.
The cost of this gap is visible in manual operations in the CRM. A manager duplicates data between the deal, the invoice, and the customer card, manually recalculates terms on every edit, copies requisites, and reminds colleagues about the next step.
At a volume of dozens of deals per day, this means hours of routine, forgotten tasks, and missed deadlines — even though the logic itself is already described and repeats from deal to deal.
A robot on a business process removes this work entirely: it reads the deal fields itself, checks conditions, calls external systems, and writes the result back to the card.
Deal automation stops depending on whether the manager remembers the regulation — the rule is executed identically on every deal, and deviations surface as a task rather than as a forgotten item.
Let's break down how this is covered: which scenarios are worth moving into a robot, how it differs from a standard trigger, and what the process needs so that automation doesn't break on the first non-standard deal.
What custom Bitrix24 robots provide: effect and comparison of approaches
Custom Bitrix24 robots cover what standard scenarios do not handle: logic with external systems, conditional branching based on deal data, retries during integration failures.
The effect of CRM automation is measured not as "it became more convenient," but in concrete quantities — the share of operations without manual involvement, lead response time, the number of lost inquiries.
Where a measurable result appears
A robot at the deal stage pulls data from 1C and external services, checks conditions, and moves the deal forward without an operator — the share of manual operations drops by 60-80% in typical scenarios.
Processing an incoming lead with routing by region and manager workload reduces first response time from hours to minutes.
Retries and logging at every step eliminate the class of failures where "the integration went down, the request got stuck" — instead of silence in the logs, an entry appears with the reason and an automatic retry.
How it differs from standard tools
Standard robots and triggers operate within the boundaries of predefined actions: stage change, email, task. Business processes handle complex approvals, but poorly tolerate external calls and mass operations — they start to slow down at scale.
A custom robot is code inside the portal's business logic: it calls APIs, the 1C database, external services, makes decisions based on data, and writes the result back to the card.
| Option | When it fits | Limitations |
|---|---|---|
| Standard robots and triggers | Typical actions within the portal | No external calls or complex logic |
| Business processes | Approvals, long chains involving people | Hard to scale, weak error handling |
| Custom robots | Integrations, calculations, branching, mass operations | Require code maintenance and a test environment |
Bitrix24 provides extension points for such logic, but scenario design, failure handling, and maintenance remain on the team's side — that is exactly where sustainable results live.
How we implement custom robots: stages of engineering work
Implementing Bitrix24 robots begins not with configuration, but with an audit of business processes: we look at which scenarios already live in the CRM, where employees manually duplicate actions, and at which deal stages things get lost.
The output is a process map with the points where a robot removes manual work, and a list of exceptions that cannot be automated without risking the sales logic.
Next comes design and configuration. We tie each robot to a specific stage or event, describe trigger conditions, trigger fields, and the sequence of actions so that automation does not conflict with existing rules and business processes. Below are the stages that Bitrix24 robot implementation follows from start to handover.
- Audit of current scenarios. We analyze pipelines, stages, access rights, and manual operations. We record which actions are repeated most often and where delays occur.
- Approval of logic. We describe each scenario in words: trigger event, condition, action, responsible person. The client confirms the logic before configuration begins — edits at this stage are cheaper than after launch.
- Robot design. We determine the robot type for the task, the fields and stages at which it triggers, and the points where human control is needed.
- Configuration and assembly. We assemble the robots in Bitrix24, link them to business processes and notifications, and set up exception handling — what to do if data is incomplete or a deal has returned to a previous stage.
- Testing on real data. We run the scenarios on a copy of the pipeline: we check triggering, the absence of duplicates, and the correctness of notifications. We catch errors before rolling out to the production CRM.
- Launch and monitoring. We enable the robots in stages and monitor the metrics: share of automatic actions, time to pass through a stage, number of manual operations.
- Handover of documentation. We provide a description of each robot, scenario diagrams, and instructions for employees — the team can maintain and refine the automation without us.
This order delivers a predictable result: automation handles the routine rather than creating new routine. Describe your task — we will come back with an estimate and a stage-by-stage plan.
How does a custom robot differ from a business process and a trigger?
These are three different mechanisms with different areas of responsibility, and confusing them is a common reason why automation "doesn't work." A business process is a sequence of steps with state: it lives in an entity's card, guides it through stages, stores history, and requires that someone (or something) moves it forward.
A trigger is a reaction to an event: a field changed, an email arrived, a time came — the rule fired. Custom Bitrix24 robots occupy the third niche: they perform a specific action at the moment when a business process has reached the right point or a trigger has raised an event.
The difference shows up in practice. A business process is convenient where there is a regulation and execution control: approval, a staged deal, a request with multiple responsible parties.
A trigger handles simple "if — then" scenarios: move a deal to another stage, create a task, send a notification.
But as soon as the logic goes beyond standard conditions — a calculation based on data from an external system, counterparty verification, generating a document from a template with dozens of fields substituted — the standard blocks are not enough.
This is where custom logic in the CRM comes in. A robot does not replace a business process and does not duplicate a trigger: it is called from them as an executor and does what cannot be expressed with standard tools.
Choosing an automation mechanism is not about "what is more modern," but about "what matches the task": a regulation — a business process, a reaction to an event — a trigger, a non-standard action — a robot.
Mixing them indiscriminately is costly: logic sprawls across dozens of rules, conflicts with itself, and when a failure occurs it is unclear where to look for the cause.
When a robot or business process is designed for its own role, the card remains predictable, and changes in one scenario do not break the neighboring ones.
Case study: how custom robots removed the manual stage in the sales department
The sales department worked on Битрикс24, but between lead qualification and assigning a task to a manager there remained a manual stage: discount approval, checking receivables, assembling a commercial proposal from data in 1С. Each step lived in a specific employee's head, and the moment they went on vacation, deals stalled.
What it was like before implementation
A request from the website landed in the CRM, but from there it was moved by hand: the manager checked the counterparty against the 1С database, copied the details, and manually set the stage and a reminder.
Discount approval took an average of 4-6 hours — the robot could not start until data from two systems was collected. Measurements over two weeks showed: 22% of deals missed the first-touch deadline, and 8% went into work with an incorrect amount due to a desync with 1С.
What was changed
Custom robots were written that trigger on a stage change and independently reach out to 1С via integration.
The robot checks the counterparty, pulls the current receivables, inserts the details into the proposal template and, if the amount is within the regulation, moves the deal forward without manager involvement.
If the threshold is exceeded, it creates a task for the supervisor with the context already assembled, rather than with an empty card.
A separate robot monitors stalled deals: if a lead has not been touched within the allotted time, it redistributes it and records the reason in the history. The logic lives inside the CRM itself, so it does not depend on who is on shift today.
What it became
| Metric | Before | After |
|---|---|---|
| First-touch time | 4-6 hours | 15-20 minutes |
| Deals with a missed deadline | 22% | 3% |
| Amount errors due to 1С | 8% | 0 |
| Manual actions per deal | 6-7 | 2 |
The class of errors with an incorrect amount disappeared completely — data is no longer transferred by hand. Managers spend the freed-up time on calls rather than on reconciliation.
The solution is built on the standard business process mechanism of Битрикс24, so platform updates do not break the logic.
Doubts before implementation: compatibility, migration, rollback, and access
Custom Bitrix24 robots run on top of the standard business process engine and REST layer, so compatibility with an existing CRM is determined not by the robot's "magic" but by which entities and fields it touches.
If a robot writes to the standard fields of a deal, lead, or smart process and does not replace the core, it coexists with already configured pipelines, permissions, and triggers.
The risk arises in one place — when several robots write to the same field on an event: then the firing order is fixed in the settings and verified on a test environment before rollout.
What if the robot conflicts with the current automation? The conflict is caught at the design stage: we map out the events and fields, see who else is subscribed to them, and separate the robots by firing conditions.
If an overlap is unavoidable, the robot gets priority through a separate marker field rather than by editing existing rules.
How do migration and rollback work? The robot's logic is versioned: the configuration is exported to a file, changes go through a separate branch, and switching between versions is a single operation.
Rollback restores the previous configuration without losing accumulated data, because the robot does not store state within itself but reads it from the CRM.
What about access and security? The robot runs under a separate service user with the minimum necessary permissions — only the entities and methods that are actually needed. Tokens are stored in a secure vault, not in the code, and are rotated according to the policy.
Can the robot be modified after handover without us?
Yes. We hand over the configurations, event and field maps, and a description of the extension points. A staff engineer with Bitrix24 experience can make changes to the logic without rewriting the integration entirely.
After handover, the client receives:
- robot configurations with a description of each firing condition;
- an event and field map: who is subscribed to what and in what order it fires;
- the service user's permission scheme and the token rotation policy;
- instructions for rollout, version switching, and rollback;
- a verification checklist after changes to pipelines and smart processes;
- a log of test runs with recorded results.
Describe your configuration — which pipelines, smart processes, and external systems the automation affects. We will get back to you with an estimate and a work plan.
Timeline for implementing custom robots: stages and benchmarks
The timeline for implementing custom Bitrix24 robots depends not on the volume of code, but on how quickly the business logic can be fixed and access to the portal obtained.
Practice shows: the robot itself is written in a matter of days, but agreeing on trigger rules, testing on real deals, and moving to the production environment take up the bulk of the project.
That is why we build the implementation plan so that each stage delivers a verifiable result, rather than "moving toward the finish line."
Stages and approximate timelines
What affects the project duration
The spread in timelines comes from integration: if the robot only changes the deal stage and creates a task, that is one scope of work, but if it pulls data from 1C, reconciles stock balances, and initiates documents, that is a completely different one.
We separately allocate time for coordination when several departments are involved in the process: each party sees its own part of the logic, and it needs to be brought together into a single scenario without conflicts.
We do not stretch out stages artificially and do not start development before the rules are fixed. This order allows us to show a working prototype already in the first week and refine details on live data rather than on assumptions. Describe your task — we will come back with an estimate and a plan for your portal.