When a robot in Bitrix24 "doesn't work", in most cases it either never ran at all or it ran and stopped on a condition — and those are two different diagnostic branches. The log tells them apart, so there's no need to fix the pipeline by guesswork. We go step by step: the robot log on the card, the stage, retroactivity, launch conditions, permissions and plan, the source app that was removed. For each symptom — one concrete check.
Where to start: the robot log on the card
The first diagnostic question — did the robot run at all? The "Robots" log on the element's card answers it: which robots started, when, and how they ended. Three outcomes — three different directions. No record — the robot didn't run: check the stage, the pipeline and retroactivity, those are the next two sections. There's a record and it ended with an error — read its text: usually it's the executor's permissions or incorrect parameters, the section on the environment below. There's a record, the status is successful, but there's "no effect" — the robot did exactly what was configured, the configuration just isn't right: open the parameters and check the fields, values and recipients against expectations.
Is the robot on the wrong stage?
Robots are tied to a stage and fire the moment an element lands on it. Hence the typical misses. The robot is configured in a different pipeline: each pipeline has its own set of robots — make sure you edited the one the deal lives in. The robot is on a stage the deal doesn't pass through: when a card is moved across several columns at once, the target stage's robots fire and the intermediate ones stay untouched. The deal was already on the stage when the robot was added — that's a separate case, covered in the next section. Basic robot setup and how robots differ from triggers is in the article on robots.
Why doesn't a robot act retroactively?
A robot is a reaction to the event "an element landed on a stage". If you add a robot to a stage where twenty deals are already sitting, for them the event passed long ago — the new robot won't fire on them. This isn't a glitch, it's normal behavior: robots don't run retroactively. What to do with old cards: move them to a neighboring stage and back — the event will happen again; for bulk handling, select the deals in the list and change the stage with a group operation. And a rule for the future: after adding or changing a robot, run one trial deal through the stage right away — don't wait for the discrepancy to surface on live records.
A condition cut it off: what does the robot actually see?
Launch conditions filter when a robot fires, and the cut-off is almost always due to data diverging from expectations: a field that's "definitely filled" is still empty at the moment of entering the stage; a value arrives in a different format; a comparison caught the wrong field. Arguing with the settings is pointless — look at the data through the process's eyes. The Check if a field is filled robot accepts the entity type, ID and field code and returns a Y/N flag plus the current value: put it on the stage with no conditions — the log will show what's really in the field at the moment it fires. A combination of checks is run by Compound condition (AND / OR / NOT): up to four comparisons with AND/OR logic and a final Y/N. After that you fix not the pipeline, but the data or the condition itself.
Permissions, plan or a removed app?
If there are errors in the log — look at the environment, not the logic. A robot performs its action on behalf of the assigned user: no rights to the element, the section or the stage change — the action fails. Automation depends on the plan: after moving to a simpler one, some robots stop being available — check the capabilities of your current plan. A separate case is robots installed by apps from the Bitrix24 Market: if the source app was removed or the Market subscription expired, its robots disappear from the templates or stop running — check the list of installed apps. And remember that a trigger isn't a robot: if the card doesn't even move to the stage, diagnose the triggers.
Checklist
The "Robots" log on the card: did the robot run, and with what result. Pipeline and stage: the robot is where the deal actually passes through. Retroactivity: a robot doesn't act on old deals — run them through the stage again. Conditions: check the actual field values with a diagnostic robot, not from memory. Environment: the executor's permissions, the plan, whether the source app is alive. The diagnostic bricks — the filled-field check, the compound condition — are in the Roboteka catalog: free installation from the Bitrix24 Market. No fit for your need — describe the task, we build the robot for free.