Why typical Bitrix24 business processes hit a ceiling
A typical business process in Bitrix24 handles linear scenarios well: approval by template, notification to the responsible person, task creation by trigger.
The ceiling begins where the logic stops being linear — you need a calculation based on data from an external system, branching across a dozen conditions, writing the result back to the accounting database. At that point, the built-in actions don't fail; they simply stop covering the scenario in full.
After that, the process becomes overgrown with manual operations. An employee exports a report, checks statuses by eye, transfers numbers into the card, and manually launches the next step.
Each such insert is a bottleneck of automation: it ties deadlines to a person, introduces errors during copying, and leaves no trace by which you can later figure out exactly where the data was lost.
The longer the chain, the more expensive each manual operation in the business process — and the less sense the automation itself makes.
The limitations of typical scenarios show up predictably: no access to an external source, no computed field, no conditional transition by a composite rule, no write-back to the source system.
You can't work around this with a template — you can only add the missing action for the specific logic.
This is exactly where custom business process actions come in: they plug into the designer on par with the built-in ones and remove the ceiling where the standard set hits its limit.
Let's break down how this is solved and what exactly gets removed from manual operations.
What custom business process action development delivers
Standard Bitrix24 actions cover typical scenarios: changing a stage, creating a task, sending an email.
As soon as a process runs into an accounting system, a non-standard calculation, or an external service, a manual step appears — an employee transfers data, reconciles balances, manually triggers the next stage.
It is precisely at these junctions that the bulk of manual errors accumulates and approval speed is lost.
Custom action development moves such operations inside the business process.
The action itself contacts the accounting system, checks conditions, writes the result back to the card, and passes the process onward — without human involvement and without intermediate exports to spreadsheets.
Where the effect is visible fastest
Approval speed grows because checks and data requests run in parallel with the request's movement, not after it. An approval that previously waited for manual reconciliation now goes through in a single pass: conditions checked, responsible parties notified, decision recorded.
The automation share is calculated simply: if eight out of ten process steps are performed by actions, two manual operations remain. Each new action removes a specific step from that remainder, and the share grows predictably, rather than "on the whole, by feel."
The reduction in manual errors is an eliminated class of failures, not individual fixes. Data transfer between systems, manual recalculation, a forgotten notification — all of this disappears because the operation is performed by an action with fixed logic. The error no longer depends on an employee's workload and attentiveness.
Next, we will look at how such actions are designed and what remains with you after implementation.
Implementation approaches: comparing options
The choice between built-in tools and a custom action is a choice between launch speed and controllability of logic. Built-in robots and automation rules cover typical scenarios: stage change, notification, task creation, working with fields.
As long as the process fits within their conditions, there is no need to write code — setup takes hours rather than days, and the process owner can maintain it themselves.
The limitation begins where non-standard logic appears: calculation based on data from an accounting system, branching by several conditions at once, calling an external service, writing to a related entity.
With standard tools this is either not expressible, or it gets assembled into a fragile chain of dozens of rules that cannot be debugged. A custom action solves the task with a single node that has a clear input and output.
| Option | When it fits | Limitations |
|---|---|---|
| Built-in robots | Typical operations with stages, fields, tasks | No access to external systems, logic only from ready-made blocks |
| Automation rules | Simple "if — then" conditions within an entity | Do not scale: the chain grows, debugging and handover become more difficult |
| Custom actions | Non-standard logic, calculations, data exchange | Require development, testing, and maintenance during updates |
| External integrations | Connection to an accounting system, services, third-party APIs | Depend on the availability of the external side, error and retry control is needed |
In practice, approaches are combined: routine work is left to built-in robots, while non-standard areas are moved into custom actions. This keeps the process readable, and changes do not break neighboring scenarios — let's break down how this is arranged in the implementation.
How implementation works: stages of engineering work
We start with an audit: we analyze the current logic in Bitrix24 — which robots and actions are already in use, where the process breaks down into manual work, what data comes from 1C and external systems.
The output is a process map with bottlenecks and a list of operations that make sense to automate with custom actions.
Next, we design the scheme: we determine where standard actions are sufficient and where our own are needed, describe the input and output parameters, failure points, and rollback rules.
Only after that do we write the code — this way the action fits into the process right away instead of being reworked along the way.
- Business process audit. We capture the current logic, record manual operations, and reconcile data between Bitrix24, 1C, and external services.
- Scheme design. We agree on the chain of actions, parameters, trigger conditions, and error behavior.
- Action development. We implement custom actions for specific operations and connect them to business processes and robots.
- Scenario testing. We run the process on test data: standard situations, edge cases, and failures of external systems.
- Setting up rights and access. We delineate roles so that an action does not expose unnecessary data.
- Solution handover. We deploy to the production environment, document the actions, and train the team.
- Support. We monitor stability after launch and refine the logic as processes change.
Handover is not a formality: we provide a description of each action, an administrator's guide, and the rollback procedure. The client's team can change parameters and add steps on their own without waiting for us. If the process changes, we come back with an estimate for the refinement.
What the customer receives upon completion
Implementation is considered complete not at the moment when the process has run on a test deal, but when the customer's team can maintain it independently.
That is why we hand over not a "working scenario," but a package that allows the process to be developed without us.
- Configured custom actions — each one published in the production environment, with a description of input and output parameters, handling of empty values, and clear error text in the process log.
- Process diagrams — up-to-date diagrams with branching points, transition conditions, and an indication of exactly where the external system is connected.
- Access rules — a role matrix: who starts the process, who sees intermediate statuses, who can cancel or restart an action manually.
- Documentation — a description of each action, its parameters, and typical failures, plus instructions for the portal administrator on editing conditions without a developer.
- Maintenance regulations — the procedure for updates when the external contour changes, monitoring checkpoints, and criteria that show the process has degraded.
- A set of test scenarios — a run on boundary data: empty fields, duplicates, loss of connection with the external system, repeated launch.
- Knowledge transfer — a recording of the walkthrough with the customer's team and contacts of engineers during the warranty support period.
We separately document logging: for each run, it is visible what data came in as input, what the external system returned, and at which step the process stopped. This removes the main maintenance risk — when there is a failure but the cause is not visible.
The package remains with the customer in their environment. Describe the task — we will come back with an estimate and a plan.
Case study: how manual operations in request approval were eliminated
The client — a manufacturing company with branches — approved purchase requests manually: a manager filled out a form, accounting checked the budget, the manager signed off, and procurement issued an invoice.
Each transition lived in email and messengers, and only the person handling the request knew its status. Out of 40-60 requests per week, about a quarter were lost or stuck, and the average processing time reached up to three days.
We broke the process down step by step and saw that half of the operations were mechanical: limit checking, counterparty substitution, notifying the next approver, creating a task for procurement.
These were moved into custom business process actions in Bitrix24 — the robot itself reads the amount from the card, compares it with the department's limit, and either passes the request on or returns it to the initiator with a reason for rejection.
What changed in numbers
| Metric | Before | After |
|---|---|---|
| Request processing time | up to 3 days | 4-6 hours |
| Share of automatic steps | ~30% | ~85% |
| Operator errors (incorrect limit, lost request) | 8-10 per week | 0-1 |
Only the steps requiring a human decision remained manual: large amounts and non-standard counterparties. Every action writes an entry to the log — you can see who approved and when, at which step the request was delayed, and why.
Why this works sustainably
The key is that the actions are not tied to specific employees: an approver leaves, but the logic remains. We added handling for rejections and re-runs: if an approver does not respond for more than a day, the request is escalated to the manager instead of hanging.
A month after launch, the share of requests closed without manual intervention holds at 85%, and procurement has stopped keeping parallel spreadsheets for control.
How a custom action differs from a robot and an automation rule
An automation robot and an automation rule are declarative mechanisms: you pick a ready-made action from the catalog and set the trigger conditions. A robot is tied to a stage or an entity event, while a rule works on triggers and can filter records by fields.
As long as the logic fits "if the status changed — notify the responsible person," the built-in tools are enough, and there is no need to pile on code.
A custom action is executable code that plugs into the same visual builder but runs arbitrary logic inside.
The difference shows up where the built-in set hits its limits: you need to reach an external system, pull data from several entities, run a calculation using a non-standard formula, or perform an operation that simply is not in the catalog.
In that situation, a robot and a rule will either fail to fire or require a chain of a dozen workaround steps that cannot be maintained.
The key difference is external calls. A robot works inside the portal and does not go beyond it. A custom action can call an external service, wait for a response, parse it, and write the result back into the card.
This is exactly where what cannot be assembled with declarative tools appears: integration with a warehouse, accounting, a delivery service, or the customer's own system.
There is a second boundary too — context management. A robot fires on a specific event and barely remembers history.
A custom action gets access to the entity's data, can read related records, accumulate state between runs, and make a decision based on a combination of conditions. This turns a business process from a set of reactions into a full-fledged scenario.
The practical criterion is simple: if a task is described with the words "notify," "create a task," "change a field" — a robot or a rule will do.
If "fetch from an external system," "calculate by a formula," "cross-check against several sources" appear — you need your own logic.
We analyze the process, show where this boundary lies, and write the action so that it stays readable for your team instead of turning into a black box.
Technical concerns before starting work
Before starting, almost every customer team asks the same set of questions: will the customization break the current portal, what will happen when the platform is updated, will it withstand the load, and how to roll back if something goes wrong. Below are the answers on the merits, without generalities.
Version compatibility: will the customization work on our edition?
We write custom business process actions for the current platform branch and verify them on your configuration before release. First, we take a snapshot of the portal — edition, installed modules, core version — and build a test stand that replicates production.
If the portal is on an old branch, we separately record which calls will need to be adapted during the transition, and factor this into the architecture from the start.
What happens when the platform is updated?
Updates do not overwrite custom code: actions live in a separate namespace and do not conflict with the core. We do not modify stock files — we only extend through supported integration points.
Before each update, we run regression on scenarios with custom actions to catch incompatibilities on the test stand rather than on the production portal.
Will the portal withstand the load?
We design actions so that heavy operations do not block business processes: long-running tasks go into a background queue, calls to external systems are cached, and bulk scenarios are split into batches.
On the test stand, we run a load profile close to peak and monitor response time and resource consumption. If there is a bottleneck, it is visible before launch, not in the middle of a workday.
How to roll back changes if something goes wrong?
Each release is a separate set of files and migrations with versioning. A rollback restores the previous state of the action without losing data accumulated in the process.
Before deployment, we make a backup of the affected entities, and the migration itself goes first to the test stand, then to the production portal — with a return point at each step.
Describe your configuration and task — we will come back with an estimate, a work plan, and a rollback scheme.
Let's discuss your task and come back with an estimate
To come back with an estimate and a plan rather than generalities, we need your current scenario: how the process is launched today, which systems are involved in it, and exactly where the manual link is slowing things down.
Describe it in free form — then we will break down the logic step by step and propose a set of custom business process actions for your case.
- Which data and entities are involved: requests, deals, invoices, counterparties, documents, statuses.
- Where manual operations currently are: transferring data between systems, approvals, notifications, exports.
- Which systems must exchange data: Bitrix24, 1C, external services, internal databases.
- Which conditions and branches are critical: amount thresholds, approver roles, deadlines, exceptions.
- What should happen on failure: retry, notification to the responsible person, rollback of the step.
- Access and permission constraints: who sees and changes data at each stage.
Based on this, we prepare a work plan: which actions we create, how we link them into a chain, where we place checks and control points. You see the set of actions and the logic of transitions in advance — before development starts, not after delivery.
The timeline estimate is based on scope: the number of actions, the number of integrations, the complexity of conditions, and the volume of data being transferred. For each item, we name the stage and the result so that you can compare the plan against your priorities.
Describe the task — we will come back with an estimate and a plan for your scenario.