👤 For all users
🔐 Available for all plans
🎯 For anyone who wants to automate repetitive tasks and doesn't know where to start
When a process grows, manual tasks grow with it. Someone needs to move the card. Someone needs to send the email. Someone needs to remember to update the field. The work isn't complex, but it takes time and, sooner or later, something slips through.
Pipefy's automations solve exactly this problem: you set the rule once, and Pipefy takes care of execution every time the situation repeats. Before configuring anything, it's worth understanding the logic behind it. Once the mental model is clear, every automation you want to create becomes just a variation of the same pattern.
📖 What you'll understand here:
The logic behind every automation
Every automation in Pipefy follows the same structure: event → condition → action.
- The event is the trigger: something happens in your pipe. A card enters a phase. A field is filled in. A deadline is reached. As soon as the event occurs, Pipefy checks whether there is an automation configured for it.
- The condition is an optional filter. It answers the question: "should this specific event trigger the action, or only when some additional criterion is true?" If you don't set up any condition, every event triggers the action. If you do set one up, only the cases that pass the filter move forward.
- The action is what happens automatically: the card is moved, the email is sent, the field is updated, the child card is created.
The condition is optional, but it's what turns a generic automation into a business rule. Without a condition, the rule runs for everything. With a condition, it only runs when it makes sense.
Available events: what can trigger an automation
Pipefy offers different types of events. Grouping them by nature helps you choose the right trigger for each situation.
- Card movement events: card entering a phase, card leaving a phase, all connected cards moved to a phase. Use these when the trigger is the progression of the process, not a specific edit.
- Data editing events: a field updated on the starting form or on a phase form. Use these when what matters is the change of a piece of data, not the change of stage.
- Time events: recurring activity (every hour, day, week, or month) and deadline alert (card overdue, expired, or due). Use these when the automation needs to act regardless of what the user does, purely by calendar or clock.
- External events: email received in the pipe and HTTP request response. Use these when the trigger comes from outside Pipefy.
Available actions: what Pipefy can execute
When the event occurs and the condition is met, Pipefy executes the action. The available options are:
- Move the card to a specific phase in the same pipe
- Send an email template
- Update a field on a phase form
- Create a card or record in another pipe or database
- Create a card or record in the same pipe
- Move the parent card to a specific phase (requires connected pipes)
- Distribute assignees
- Apply a formula
- Make an HTTP request
- Create with AI
Each action executes exactly one thing. If you need two events to happen at the same time, like moving the card and sending an email, you create two automations with the same event.
How this works in a real process
Context: HR team managing employee reimbursement requests.
Problem: when a request reaches the "Awaiting manager approval" phase, no one automatically notifies the person responsible. The process gets stuck because communication depends on the requester remembering to notify them.
The automation:
- Event: card enters the "Awaiting manager approval" phase
- Condition: none (every request needs the notice)
- Action: send an email to the "approver" field
With a single rule, the manager receives the notification as soon as the request reaches the correct phase, with no manual intervention. The flow continues.
This is the most common starting point for new users: a phase entry event combined with a notification. From there, variations are just refinements of the same pattern.
When to use the condition
The event → action logic solves most cases. But real processes have variations that require the filter.
Imagine a purchase request pipe. The event "card enters the Approval phase" happens for every request, regardless of the amount. If you want the notification to the CFO to fire only for requests above $10,000, the condition is the right tool.
Without it, you'd need separate automations for each variation, or you'd send irrelevant notifications to people who don't need to act. With it, a single rule covers the entire variation of the process.
Automation rules and automation tasks: the difference matters
Pipefy separates two concepts that frequently cause confusion.
Automation rules are the automations you configure, meaning the combination of event and action you define in each pipe. There is no limit on rules: you can create as many as you need, in as many pipes as you want, at no extra cost.
Automation tasks are the triggers these rules perform. Every time a configured event occurs, Pipefy counts a task, even if the condition isn't met and the action doesn't happen. The check itself already counts as a task.
Example: you create a rule so that, whenever João creates a card, the priority field is updated to "High".
- João creates a card. The field is updated. Tasks consumed: 1.
- Someone else creates a card. The field is not updated. Tasks consumed: 1.
In both cases, the task is counted because the event occurred and Pipefy carried out the check.
Monthly task limits vary by plan. If you exceed your plan's limit, you can purchase additional tasks through an add-on or upgrade. See the options on the Pipefy pricing page.
Pay attention in high volume pipes. If the event is frequent and the condition filters out most cases, task consumption can be higher than it looks. Every check counts, even when the action doesn't fire. Review whether the condition is well calibrated before activating the rule in production.
The criterion that separates what's worth automating
Not every manual task should become an automation. The central criterion is simple: does the task require human judgment, or does it just require someone to remember to do it?
If the answer is "it just needs someone to remember", it's a candidate for automation. If it requires analysis, context, or a decision, the human still needs to be in the loop.
Examples of tasks that require judgment: Assessing whether a proposal is within scope. Deciding the priority of a ticket with incomplete information. Approving an exception outside standard policy.
Examples of tasks that just require someone to remember: Notifying the approver when the request reaches the right phase. Moving the card to "Done" when all required fields are filled in. Creating the onboarding card as soon as the hire is confirmed.
When you look at your pipe through this lens, automation candidates show up fast.
Three signs that a point in the process calls for automation
1. The same action always happens, with no variation
If the same thing needs to happen every time a card enters a phase, that's a rule disguised as a manual task. The process has already decided what to do. All that's missing is letting Pipefy execute it.
Example: every approved purchase request needs a confirmation email to the requester. No exceptions. That's automation.
2. The process gets stuck when someone is unavailable
If a step depends on a specific person remembering to act, the process has a fragile point. Vacation, a long meeting, a busy day: the queue stops. Automations remove this dependency at the points that don't require judgment.
Example: the manager only finds out there's a pending approval when the requester sends a message. The notice should be automatic.
3. Repetitive fields are always filled in with the same value
When the team fills in a field with the same content in most cases, that information can be set automatically as the default and changed only when necessary.
Example: every card created in the facilities pipe starts with the "requesting department" field filled in as "Operations", because 90% of requests come from that team.
Where to start: the friction map
Before opening the automations screen, do this exercise on your pipe.
Go through each phase and answer: what needs to happen when a card enters this phase? What needs to happen when a card leaves? What needs to happen if a card sits idle here for more than X days?
The answers that come automatically ("obviously we need to notify so and so", "we always update this field") are your first candidates.
Sort each one into two groups:
High frequency + zero variation: automate now. These are the rules that save the most time and carry the least risk.
High frequency + some variation: assess whether a condition solves it. A rule with a filter covers most cases without eliminating the exceptions.
Common trap: automating before the process is stable. If phases still change frequently, every change will require reconfiguring the automations. Wait for the pipe to complete at least two or three real cycles before creating rules.
An example of a mapped process
Process: expense reimbursement requests.
Phases: Filling out → Awaiting approval → Approved → Finance → Done
Going through each phase with the questions above, three immediate candidates come up:
Card enters "Awaiting approval". The responsible manager needs to be notified. Always. No variation. Automation: send an email to the "responsible manager" field.
Card enters "Approved". The requester needs to know it was approved. Always. Automation: send a confirmation email to the "requester" field.
Card sits idle in "Finance" for more than 3 days. The finance team needs a reminder. Whenever the deadline is exceeded. Automation: deadline alert with notification to the person responsible.
Three automations. None requires human judgment. All of them remove dependency on memory and reduce the risk of the process getting stuck due to lack of communication.
What to leave for later
More sophisticated automations, like creating cards in connected pipes, triggering HTTP requests, or using AI to fill in fields, make sense once the basic process is already running reliably.
Start with notifications and movements. They have immediate impact, are easy to adjust, and teach you how the system behaves before you add complexity.
Remember the task counter: every automation check consumes a task, even when the condition isn't met and the action doesn't fire. In high volume pipes, prioritize well calibrated conditions to avoid unnecessary consumption.
Before moving on, confirm that you understand:
☐ What an event is and its role in automation
☐ When to use a condition and when to skip it
☐ Which action makes sense for the problem you want to solve
☐ Which process in your pipe has the most repetitive manual work today
