An automation rule that "did not work" in Bitrix24 (Alaio) is two different failures wearing the same face: the rule never started, or it started, evaluated its condition and quietly exited. The fix for one is useless for the other, so the first job is telling them apart — and the log does that in seconds. Below is the diagnostic order, most common first.
Did it never start, or start and exit silently?
Open the item and look at its automation log. Each rule carries a status: green with a check mark — ran successfully; green with an alert icon — ran and failed with an error; white with a spinning circle — paused, still waiting; white with no icon — never executed. That last one is the important signal: nothing about the rule's own settings matters yet, so look at the stage and the conditions instead.
Test mode is more readable still: its log marks met conditions green and unmet ones orange, delayed runs blue, errors red.
Why is the entry condition the usual culprit?
Most "it didn't run" reports are a condition that evaluated to false against data you assumed was there: a field that is "obviously filled" is empty when the item enters the stage, a value arrives as text where a number was expected, a comparison points at a similarly named neighbouring field.
Arguing with the settings gets you nowhere — put an unconditional probe on the stage. The Check if a field is filled robot returns a Y/N flag with the current value, so the log shows what the field really held when the rule fired. For combined checks, Compound condition (AND / OR / NOT) evaluates several comparisons with explicit grouping and returns one Y/N.
One documented trap: a condition with a time range that crosses midnight does not work as one span — split it into two ranges inside the same day.
Did the item ever reach that stage?
Rules fire when an item lands on the stage they are bound to. A rule on a stage the deal skipped never gets its turn, and a rule you added today does not apply to items already parked on that stage — the entry event happened before the rule existed. Rules are also per-pipeline: editing one leaves every other untouched. For smart processes, automation rules, triggers and the workflow designer can be disabled in the settings entirely. How stages, rules and workflows relate is covered in the workflow automation guide and the automation rules guide.
Why do rules fail on items created by an integration?
When an item is created through a webhook or an application, the rule starts the moment the item appears, while the integration is still writing the remaining fields. The condition reads a field that will be filled a second later, finds it empty and exits. Bitrix24's own recommendation is to delay execution so the data has time to land.
If the gap is short, an explicit pause is enough: Short pause waits the number of seconds you specify, then signals success so the rest of the chain runs against complete data. If the integration is the suspect, check what it sent — see the webhooks guide and REST API error codes.
What if the rule ran but ended with an error?
An error status moves the investigation from logic to environment. Most causes are permission-related: a rule acts on behalf of a user, and if that user cannot see the item, edit the field or move the stage, the action fails. Missing required information stops actions too — an email step with no configured sender is the classic example, and required fields behave the same way.
Two documented quirks: special characters such as >, <, =, +, @ and # in variable and activity names break settings forms and make parameters disappear; and editing a workflow does not affect instances already running, so finish the active run and start a fresh one before deciding your change did nothing.
What about two rules on the same stage?
When several rules on one stage touch the same data, the outcome depends on which wrote last, and the symptom is an unexpected field value or the wrong assigned employee rather than a rule that visibly failed. The documented fix is to set the "change on behalf of" role consistently across the rules involved; if two rules genuinely compete, one rule with explicit branching is cleaner.
Check the plan too: workflows depend on the plan level, and after a downgrade running workflows stop and new ones cannot start until you move back up.
What is the fastest way through all this?
Read the status first. No icon: it never ran — check the stage, the pipeline and retroactivity. Alert icon: it ran and broke — check permissions, senders and required fields. Green check with no visible effect: the rule did what it was told and the settings are wrong. Behind all three sits one cause more common than the rest — a condition that was false at the moment of truth.