Omnia Lab or Bitrix24 automation rules: what each one covers

What do Bitrix24 automation rules and triggers do well?

This is the built-in automation mechanism, tied to pipeline stages. It is configured without a developer and works out of the box. These strengths come straight from the official documentation.

• A rule runs on its own when an item lands on a stage: send an email, create a task, generate a document, notify a manager, reassign the owner.
• A trigger moves the deal forward by itself. It watches customer actions and changes in items — a link clicked in an email, an inbound call, an invoice paid — and moves the CRM item to the stage where the trigger is configured.
• Every rule has three built-in settings: execution order (sequential or independent), timing (immediately, after a delay, or a set time before an event) and a condition — for example, deal amount.
• Customer communication is native: send an email, place a call that reads out text or plays a recording, send a messenger or social network message, send an SMS, invite the customer to a Telegram chat.
• The same mechanism works across four tools: CRM, tasks, Bitrix24 Sign and digital workplaces.
• There is a built-in debugger: the scenario runs on a test deal with an action log and skipped pauses. In the official plan comparison table, the row for the CRM deal rule debugger is marked as available on every plan, including Free.
• Automation is available from day one: the Free plan lists 5 in the automation rules and triggers row; paid plans from Basic upward are marked as available.
• The mechanism is extensible: an application can register its own rule via bizproc.robot.add and its own trigger via crm.automation.trigger.add, and return the result to the process via bizproc.event.send.

For heavier scenarios there are two neighbouring tools: business processes with the visual Designer (Professional and Enterprise) and RPA for simple internal approvals outside CRM.

Where does the stage-based model run out of room?

These are not complaints about the product — they are the boundaries of the model and the caveats Bitrix24 documents itself. Worth knowing before you build quality control on top of automation rules.

• The model is stage-based by design: a rule runs when an item lands on the stage where it is configured, and a trigger moves the item to the stage where it is configured. A scenario that cannot be expressed as movement between stages cannot be expressed here.
• Rules live inside their own container: in tasks they have to be configured separately for each project, and in CRM they are set per entity and per stage. There is no portal-wide rule set.
• A condition is evaluated at the moment the rule fires. If an external system fills fields in gradually through webhooks, the rule may read a field before anything has been written to it.
• Editing a scenario does not reach instances that are already running — they finish under the parameters that applied when they started.
• Several rules changing the same data at once can conflict with each other. That is a separate entry in the official list of reasons automation did not work.
• Communication rules depend on connected channels: email needs a mailbox connected for the responsible employee, calls need telephony, SMS needs a chosen provider, a Telegram invitation needs a connected Telegram channel.
• Business processes, the Business Process Designer and editing rules through the constructor are available only on Professional and Enterprise. The Free plan has 5 automations and a single sales pipeline.
• Taking inventory means opening the interface: bizproc.robot.list returns rules registered by the application, and crm.automation.trigger.list returns triggers added by the application. Anything assembled by hand in the interface is not listed by those methods.

The official table publishes no numeric ceiling on rules or runs for paid plans — it simply marks them as available. The only published number is 5, on the Free plan.

What can an automation rule not see by its nature?

A rule reacts to an event: a stage changed, a field changed, a call arrived. Four things in a sales floor are not events at all — they live in the text of the conversation and in the recording of the call.

• The meaning of a message. To a rule, a message is a fact, not content. Omnia Lab reads the text: a message that consists entirely of "ok" or "thanks" closes the conversation, while the same word inside a live sentence does not, and the response timer keeps running. Marketplace service notices do not open an SLA and do not distort response time, and any live text from the customer wins.
• Whether a human actually replied. Triggers catch an inbound call, an email being read, an invoice being paid, a field changing — a human reply is not on that list. Omnia Lab measures time to the first real contact and escalates on a ladder: 5, 15 and 17 minutes to the shared sales chat, 10 minutes to the rep in private, 20 minutes to the head of sales. A reply, a call or the "no reply needed" button closes the measurement and clears every reminder. At night escalation stages are cancelled, not pushed to the morning.
• A promise made in plain text. "I'll call you at four", "I'll send the quote by end of day" — to a rule this is an ordinary message. Omnia Lab turns it into a task with a deadline: a private ping 30 minutes before it is due, another private ping 15 minutes after it is missed with "Done" and "Postpone" buttons, and only after an hour does it reach the shared chat. Before every ping the system rereads the conversation: if the promise is already kept, the task closes itself. Customer promises work the same way — "I'll look at it in an hour" becomes a task due at the customer's own time plus 30 minutes.
• Whether a closure was justified. A rule will execute everything configured on the Lost stage and will never ask why the deal was lost. Omnia Lab reviews every closure to spam or lost against the whole history — chat, comments, the card, the transcript of a recent call — and returns an unjustified closure to work, no more than once per deal, with a decision log. During a mass cleanup of the pipeline (more than 30 closures in 2 hours) returns are muted: the system does not argue with a deliberate human decision.

Measured before and after rollout at existing clients: median first response dropped from 32 to 6.5 minutes, and the share of deals with a prepayment rose from 4—7% to 13%.

How do the two approaches compare point by point?

On the left, the criterion. On the right, how each tool handles it.

What starts the scenario

Automation rules and triggers: landing on a stage, plus events — inbound call, email read, invoice paid, field changed. Omnia Lab: CRM and telephony events plus meaning — message text, call transcript, the fact that a human replied.

Where the rules live

Automation rules and triggers: inside a specific entity and a specific stage; in tasks, separately for each project. Omnia Lab: 33 modules with individual switches and 85 settings in the admin panel, applied in under 60 seconds without a restart.

First-response control

Automation rules and triggers: a timed notification on a stage. Omnia Lab: measurement to the first real contact counted in working seconds, a 5/10/15/17/20-minute ladder, and one live reminder per thread — a new one deletes the previous.

Promises and commitments

Automation rules and triggers: a task is created by the stage scenario. Omnia Lab: the task comes out of a sentence in the conversation, from both the rep's promise and the customer's; a duplicate guard skips it if an open task already exists within ±45 minutes.

Missed calls

Automation rules and triggers: an inbound call is a native trigger event that moves the item to the right stage. Omnia Lab: a callback task due in 30 minutes, silent on Telegram at night, closed automatically by a real conversation of 15 seconds or longer.

Call quality

Automation rules and triggers: a call can be placed and recorded into the scenario. Omnia Lab: transcription, a 0–100 score where the code does the arithmetic and the AI only supplies quoted facts, plus a review task for the rep.

Closure review

Automation rules and triggers: they execute whatever is configured on the terminal stage. Omnia Lab: a verdict on every closure to spam or lost, and a return to work for unjustified ones, at most once per deal.

Debugging and transparency

Automation rules and triggers: a debugger on a test deal (marked as available on all plans in the pricing table) and a business process event log kept for 7 days on Professional and Enterprise. Omnia Lab: an analytics layer refreshed hourly with 90 days of depth, an error log and AI provider monitoring.

Taking inventory

Automation rules and triggers: what was built by hand is visible in the interface, while REST list methods return only the application's own objects. Omnia Lab: every action and verdict is a structured record inside a single conversation history per deal.

Which one should you pick, and when?

The two tools solve different problems, so the answer is usually "both, for different jobs".

• An email, an SMS, a task or a notification to the manager when a stage changes — that is an automation rule. It is configured without programming and costs nothing beyond your plan.
• Moving a deal on an event — a call came in, the customer opened an email, an invoice was paid — that is a trigger.
• An internal approval outside CRM — that is RPA. Branching logic with conditions and parallel paths — the Business Process Designer on Professional or Enterprise.
• A customer is waiting for an answer while the deal sits on a perfectly correct stage — that is outside the stage-based model. It needs a first-response timer and escalation to a manager.
• Reps promise and forget, the pipeline gets cleaned by gut feeling, and the head of sales does not trust the numbers in the report — that is Omnia Lab's territory.
• Most often both are true at once: automation rules hold the mechanics of the pipeline, Omnia Lab holds the meaning of the conversation. They do not compete for the same work.

What does each option cost?

Automation rules are not sold separately — they are a function of the Bitrix24 plan. The prices below are published on the official pricing page and were checked on 21 August 2026.

Bitrix24 cloud (per month, for the whole company)

Free — 0 ₽ with unlimited users; Basic — 2,490 ₽ for 5 users; Standard — 6,990 ₽ for 50 users; Professional — 13,990 ₽ for 100 users; Enterprise-250 — 33,990 ₽. The page also shows discounted promotional prices.

What the plan includes

On Free, the automation rules and triggers row shows 5 (with a single sales pipeline). From Basic upward the limit is removed. Business processes, the Business Process Designer and rule editing through the constructor start at Professional.

Availability in Russia

The product is Russian: 1C-Bitrix24 is listed in the Unified Register of Russian Software (registry entry No. 25, rights holder OOO BITRIX), prices are in roubles, and both cloud and self-hosted editions exist, with a 15-day demo of the top plan.

Omnia Lab

It sits on top of your existing Bitrix24 or amoCRM account and does not replace it. The audit is free and takes 3–5 days; rollout takes 3–5 days. At launch every module is dormant until you switch them on one by one.

Bitrix24 prices change — check bitrix24.ru/prices for current figures. Marketplace subscription pricing is published separately; we did not verify it and do not quote it.