A business process instance failure is one of the most frequent complaints of Bitrix24 administrators. Tasks do not move, notifications do not arrive, and the log is empty.
Over years of designing business processes of various scales, we have identified a pattern: 80% of problems are laid down before the designer is even opened — at the stage of formalizing the logic.
A properly designed process saves up to 40% of manual work time and eliminates "stuck" instances. This article describes how to achieve this and what is included in the service of designing Bitrix24 business process logic.
A designed business process works 3-4 times more stably than one created hastily. For a typical process of 10 steps, time savings reach 20 hours per month, which reduces operating costs significantly each month.
A major system integrator confirms: "80% of errors in business processes are laid down at the design stage". That is why we focus primarily on formalization, not rapid implementation.
Main problems we solve
Typical situations clients come to us with:
- The process hangs at a wait step — the escalation timer was forgotten.
- A REST call to an external service fails, and the process does not handle the error.
- Notifications go to the wrong recipient because the "Responsible" field is not yet filled at the time of the step.
- Parallel branches create excessive load on cron — the
CBPSchedulerService::OnAgentagent runs every minute, and with hundreds of active instances the system slows down.
Each of these problems is solved at the design stage. A designed process is 3-4 times more stable than an improvised one — our practice confirms this.
How to design a business process so it does not hang?
Designing on paper before implementation reduces the number of errors by 3-4 times. Our approach includes four stages.
- Formalization in BPMN. We draw a flowchart with mandatory elements: start, end, branches, responsible parties, timers, escalations. Special attention goes to exception paths: what happens after 3 days of client silence, when the responsible person is on vacation, or when a payment error occurs. These are exactly what people forget in the designer, and the process hangs. You can learn more about the notation in public sources.
- Variable inventory. A process has instance variables, launch parameters, constants, and entity fields via
Document. We determine in advance which data is read, created, and written back. - Trigger definition. Processes are launched manually, by event (field change, stage change, entity addition), or on a schedule via agents. For event triggers, protection against repeated launch when returning to the same stage is important.
- Notification design. Notifications are addressed by role (responsible person, author, group). A typical mistake is a notification going to the "responsible person," but the "Responsible" field does not exist yet. We explicitly define the addressing chain for each step.
Case: contract approval process (from our practice)
Our client is a manufacturing company with 80 users. It needed to automate contract approval in CRM: lawyer → financial director → general director. The first version, made by the client, contained three sequential "Approve/Reject" tasks. On rejection, the process ended without the possibility of revision — a typical trap.
We designed and implemented:
- a "submission → approval" cycle with return for revision at any stage with a comment;
- escalation timer: if the lawyer does not respond within 2 business days — a notification to the manager;
- parallel notification to the initiator about the status at each step;
- recording the final status in a custom deal field for reporting;
- automatic creation of a task for the legal counsel with the contract file.
Implementation took 8 business days including testing in a test environment and deployment. Before this, the process "hung" for every third contract — after implementation, failures almost disappeared. Order business process design and get stable operation.
Comparison: designed process vs "quick and dirty"
| Parameter | Designed process | Improvised in the designer |
|---|---|---|
| Errors at launch | up to 1 per 10 processes | 3-4 per 10 processes |
| Debugging time | 1-2 days | up to a week |
| Failure resilience | full exception handling | hangs at any deviation |
Why do processes in Bitrix24 slow down?
Heavy business processes with many parallel branches and REST calls create load on cron. If the CBPSchedulerService::OnAgent agent runs every minute, and there are several hundred active instances — this is noticeable. We design with load in mind: we limit parallel activities and use delayed launches.
Limitations and pitfalls
Template versioning. Running instances continue to work according to the old version. When changes are made to the template, old processes do not update. You have to force-complete them or accept two versions running at the same time. We always draw up a migration plan.
REST activities. Calling external systems via REST requires mandatory error handling. If the service is unavailable, the process should not hang — timeouts and retries are needed.
Performance. Parallel branches with webhooks can consume all cron resources. We recommend no more than 3-5 parallel activities per process.
What is included in the service
- Formalization of the process in BPMN with approval
- Implementation in the Bizproc designer (template + variables)
- Documentation: description of steps, variables, exceptional situations
- Testing in a test environment and transfer to production
- Administrator training (1 hour)
- Warranty: 1 month of support after launch
Timelines
A simple linear process (5–8 steps) — 2-4 days. A process with branching, escalations, integrations — 1-3 weeks. Cost is calculated individually after task analysis.
To evaluate the project and get accurate timelines, contact us?
We only take on processes where we see real benefit for the business. Get a consultation — write to us.
Table: typical mistakes and solutions
| Mistake | Cause | Solution |
|---|---|---|
| Process hung on wait | No escalation timer | Add a timer with an action on trigger |
| REST call failed | Error status not handled | Use a Try-Catch block or a condition based on the response code |
| Notification did not arrive | Incorrect addressing | Link the notification to a role or a specific field |
Contact us to design a reliable business process. Order business process design today and get stable operation.