👤 For all users
🔐 Available for all plans
🎯 For anyone who wants to eliminate manual card movement when a key piece of information is recorded
Moving a card manually looks simple, but it hides a real cost: someone needs to notice that the information was filled in, remember to act, and not be in the middle of another task. As volume grows, this step becomes a bottleneck. Cards sit in the wrong phase, visibility drops, and the process loses reliability.
Field based movement automation solves exactly this point. When critical information is recorded, the card moves forward on its own. The team stops managing movement and starts managing the process.
📖 What you'll understand here:
When this automation makes sense
The "a field is updated" trigger is the right event when the card's progression depends on a piece of information, not a decision.
The distinction matters. If the card should move forward because someone analyzed and approved it, the right trigger is different: an explicit human action, not a field being filled in. But if the card should move forward because a required piece of information was recorded, the updated field is the ideal trigger.
Situations where this logic applies:
An onboarding process where the card only moves to "Equipment" when the "start date" field is filled in by HR. There's no decision: the date exists, the process moves on.
A purchasing process where the card moves to "Awaiting payment" when the "invoice" field is filled in by the supplier. The invoice arrived: the process moves on.
A support process where the card moves to "In progress" when the "assigned analyst" field receives a name. The owner has been assigned: the card leaves the queue.
In all these cases, filling in the field is the information that signals the process can move forward. The automation just executes what would already be done manually.
How to structure the rule
Every field based movement automation follows the same logic:
Event: a field is updated Condition: which field, and with which value (or simply "is not empty") Action: move the card to phase X
The most important point is the condition. Without it, any update to any field on the card triggers the movement, which is rarely the desired behavior.
The condition is what turns a generic trigger into a business rule. Always specify which field should be updated and, whenever possible, which value or state that field needs to have for the card to move forward.
Structured example:
Event: a field is updated Condition: field "person responsible for the request" is not empty Action: move the card to the "In progress" phase
With this rule, the card only moves forward when the responsible field is filled in. If any other field on the card is edited, the automation doesn't fire.
A real use case
Process: system access requests, managed by the IT team.
Problem: cards reached the "Review" phase and sat there because the responsible analyst wasn't assigned automatically. The manager had to manually check which cards still had no owner and distribute the demands.
The configured automation:
- Event: a field is updated
- Condition: field "assigned analyst" is not empty
- Action: move the card to the "In execution" phase
When the manager assigns the analyst, the card moves forward on its own to the execution phase. The "Review" queue started showing only what truly had no owner yet, without mixing it with what was already underway.
Result: visibility into what's pending versus what's already moving, with no manual movement at all.
What this rule looks like in Pipefy
The example below uses an internal support request process. Adapt the field and phase names to your own context.
Scenario: the card reaches the "Queue" phase with no owner. When the coordinator assigns an analyst in the "person responsible for the request" field, the card should automatically move to "In progress".
In your pipe's automations screen, configure:
- Event: A field is updated. Select the specific field: "person responsible for the request"
- Condition: field "person responsible for the request" is not empty. This ensures the automation only fires when the field receives a value, not when it's cleared or replaced with empty.
- Action: move the card to the "In progress" phase
Save the rule and test it with a real card: fill in the responsible field and watch the card move forward.
The same pattern works for any field of the assignee, tag, or select type. Change the field in the condition and the phase in the action. The structure of the rule doesn't change.
Which fields appear in the selector and why some are missing
A common question: when configuring the "a field is updated" event, some fields appear in the list while others do not. Whether a field is mandatory is not the deciding factor.
Pipefy lists all fields in the pipe, organized by form: the Start Form appears first, followed by the forms for each phase in order. Fields from all phases appear, regardless of whether they are mandatory.
If a field does not appear, the most common reasons are:
- The field has not yet been created. It may seem obvious, but it is worth confirming: the field must exist in the pipe before it can appear in the automation.
The field is a connection type. Fields that connect cards to other pipes or databases do not appear as options for the "field updated" trigger.
You are looking at the wrong pipe. For pipes with connections, ensure you are configuring the automation in the correct pipe.
If the field exists, is editable, and is not a connection type, it will appear in the list grouped by the phase where it is located.
What to watch for before activating
Set the condition before saving the rule. An automation with no condition on the "field updated" trigger will fire for any edit on the card. In active pipes, this can generate unexpected movements and consume automation tasks unnecessarily.
Consider the timing of the fill in. If the field in question can be filled in at any phase of the pipe, the automation will fire regardless of where the card is. Assess whether this is the expected behavior or whether an additional phase condition is needed.
Automation tasks are counted at the check, not the action. Every time the "field updated" event occurs, Pipefy checks the rule and counts a task, even if the condition isn't met and the card doesn't move. For frequently updated fields, consumption can be higher than it looks.
Before moving on, confirm:
☐ You identified which field, when filled in, signals that the card should move forward
☐ You set the correct condition on the rule (which field, which value or state)
☐ You checked whether the field can be filled in during other phases and whether that affects the expected behavior
☐ The automation is active and you followed at least one card through it
