👤 For users with an active process who set up automations and noticed they stopped firing or moving cards
🔐 Available on all plans (behavior varies by plan on automation limits)
🎯 For anyone who wants to figure out on their own why a silent automation stopped, without opening a ticket
A card enters the phase that should trigger the automation, and nothing happens. The process just stalls there. No one got the email, the card didn't advance, and day to day this feels like the flow “choked” for no clear reason. The uncomfortable part is rarely the automation itself: it's not knowing where to look first. Rebuilding everything from scratch is usually the first instinct, and almost always the most expensive one.
There's a diagnostic path that saves that rework. By the end of this article, you'll know which order to investigate in, what the automation log reveals about each run, and how to identify, from the evidence, which of the most common causes is behind the problem.
📖 What you'll understand here:
The rule is there, but the process won't move: where to look first
When an automation stops, the cause is almost always in one of three layers, and it's worth investigating in this order, from most to least likely.
- The trigger condition. The automation depends on an event (a card entered a phase, a field was updated). If the event didn't happen exactly as the rule expects, it never even runs.
- The card's state. Empty required fields, invalid data formats, or a destination phase not enabled will block the move before the automation completes.
- The relationship between rules and pipes. Two automations with the same trigger, or a pipe connection with advanced options on, produce behavior that looks random but has a cause.
Before touching the rule, confirm the event actually happened. An automation that “didn't fire” often never had its trigger satisfied, and no amount of reconfiguring fixes that.
The automation log: evidence before guesswork
Pipefy records what happens to each automation, and that's where diagnosis should start, before any changes. The record shows the trigger's execution status, which tasks succeeded and which failed, and the date and time of each, with filters to segment the list. Instead of guessing why the rule didn't run, you read what actually happened.
Reading the log flips the logic of the investigation. If the run shows as failed, the problem is in the card or the configuration, and you know where to look. If it doesn't show at all, the trigger wasn't satisfied, and the focus shifts to the trigger condition, not the action. Opening a specific record reveals the detail of that run, which usually points straight to the cause.
The automation logs feature is in Beta. Its behavior and screen naming may change; confirm the exact name and availability in your environment before guiding your team.
Learn more: Automation logs and how automation rules and tasks work.
The five most common causes and how to recognize each
When it's a card-moving automation that stopped, five causes account for most cases. What differs between them is the evidence each leaves; that's what tells you which one to investigate.
1. Field filled in an invalid format
Email, phone, and document fields need valid data in the expected format. When the data doesn't match, the field is highlighted in red and the move won't complete. How to spot it: open the card and look for the flagged field; the evidence is visual and immediate.
2. Required field left blank
A card with an unfilled required field won't move. This applies to the start form (an automation that moves the card right after creation can't coexist with required fields on the start form) and to the previous phase's form. How to spot it: if the automation fires on card entry and never works, suspect a required field on the start form first.
3. Destination phase not enabled for the move
Every new phase is created without permission to move into it from existing phases. If you recently created the destination phase and the automation never ran to it, the move-enablement in the source phase's advanced settings is the first place to check. How to spot it: the rule is correct, the card is complete, but it never reaches the newly created destination.
4. Pipe connection with advanced options on
When cards pass through a connection field to another pipe, advanced options active on that field can block the move. How to spot it: the automation involves connected pipes and the block happens exactly at the connection point.
5. Selection fields with mismatched options between pipes
In connected pipes, selection fields (single or list) must have exactly the same options, written the same way. If they diverge, Pipefy won't transfer the data, and an automation that depends on that update won't happen. How to spot it: the problem shows up only in the flow between two pipes, and disappears once the selection fields are aligned.
Notice the pattern: causes 1 and 2 live inside a single pipe; causes 4 and 5 only appear when pipes are connected. Knowing which situation you're in cuts half your hypotheses at once.
When the problem isn't the rule, but plan usage
There's a scenario where the configuration is flawless and automations still stop: the plan's automation task limit. Every trigger or check counts as a task, and each plan has its limit. The telltale sign is different from a broken rule: it isn't one specific automation failing, it's several stopping at once, typically near the end of the billing cycle. If the evidence points here, the path is to monitor usage, not reconfigure the rules.
Learn more: how Pipefy counts automations on your plan.
If none of this fixed it
Went through the three layers, read the log, ruled out plan usage, and the automation is still stuck? By then the evidence is gathered: you know whether the run failed or never appeared, in which pipe, and from which phase. With that picture ready, reaching out to support stops being “my automation doesn't work” and becomes a specific report, which resolves faster.
Before you move on, make sure you understand:
☐ That the investigation starts with the most likely layer (the trigger condition), not with rebuilding the rule
☐ That the automation log shows whether the run failed or never happened, and that defines where to look
☐ That you can look at a stuck card and recognize, from the evidence, which of the five causes is at play
