A trigger in Bitrix24 is an event sensor: a customer pays an invoice, an email arrives, a CRM form is filled in, an inbound call is logged — the trigger catches the event and moves the deal or lead to a set stage. That is all it does on its own: the real work begins afterwards, when the robots on the new stage fire. Let's look at which triggers exist, how the "trigger → stage → robots" chain is built, and why triggers most often "don't work" for the same handful of reasons.

How is a trigger different from a robot?

By direction. A robot is a reaction to a stage: a deal lands in a column, the robot performs an action (email, task, field change). A trigger is a reaction to an external event — a payment, an email, a call, a website visit, a field change — and its single action is always the same: move the item to a stage. It's easy to remember: a trigger moves, a robot does. Both are configured on the same Robots screen above the kanban: robots are bound to stages, triggers sit in a separate column on the right, each specifying which stage to move the item to.

Which triggers exist, and how does the chain with robots work?

The main groups are: communications (inbound email, call, open-channel message), payments and documents (invoice paid, document viewed), forms and website (CRM form filled in, page visit), data changes (a field changed, a timeline entry appeared), and tasks (the status of a linked task changed). The chain is designed from the event outward: "the customer paid" → the trigger moves the deal to "Paid" → the stage robots send a receipt, create a shipping task, and notify the manager. All the logic lives in the stage robots — which is why stages built for triggers should be event-based ("Paid", "Responded to quote") rather than vague.

How do you add conditions to a trigger that doesn't have any?

Triggers have minimal settings of their own: "email arrived" can't tell who the email is from, "field changed" doesn't know which value it changed to. Filtering is done on the receiving stage: the first robot is Compound condition — it checks a combination of fields (source = ads AND amount above the threshold) and returns Y/N, which the process uses either to continue processing or to return the deal to its original stage. Before processing it helps to validate the data: Check that a field is filled in catches cards without a phone number or an amount, and the ternary operator substitutes a default value in place of an empty one. That way the trigger stays a simple sensor and the intelligence sits in the robots.

Why doesn't my trigger fire? A checklist

Five causes cover almost everything. The deal is already on the target stage — a trigger won't move an item to where it already sits. The trigger is set up in a different pipeline — each pipeline has its own set, so check that you configured it where the deal actually lives. The event isn't what it seems: "inbound email" fires on an email linked to a CRM entity, not on any mail at all; "invoice paid" fires on an invoice status change in Bitrix24, not on money arriving in the bank. Permissions and integrations: a call trigger won't fire without connected telephony, a form trigger won't fire if the form isn't a Bitrix24 CRM form. And order in the list: when several triggers compete for the same event, the topmost one fires — check the priority.

Bottom line

Triggers are the entry layer of automation: they listen to the world and move cards, while the decisions are made by the robots on the stages. Extra conditions, checks, and default values come from the robots in the Roboteka catalog: installed from the Market for free, and working on the same Robots screen.