👤 For users with a process in production who distribute work across team members
🔐 Available on all plans (round robin distribution is a paid plan feature)
🎯 For anyone who wants every card to enter a phase already owned, without relying on someone remembering to assign it
A card just entered the analysis phase. It has a deadline, it has its data filled in, it has everything except someone in charge of moving it forward. No one gets notified, no one feels it is theirs, and the card sits waiting for someone, at some point, to notice it exists. When volume is small, the person who modeled the process covers that gap from memory. When volume grows, the gap becomes a silent bottleneck: work no one picked up because, formally, it belonged to no one.
By the end of this article, you will know how to choose the right automatic assignment mechanism for your process, so that every card reaches a work phase already owned, without a new assignment erasing whoever was responsible before. Pipefy offers more than one path for this, and choosing between them is what separates a process where work flows from one where it stalls.
📖 What you will understand here:
What is at stake when a card has no owner
Before configuring anything, it helps to separate two problems that look alike and are not.
The first is the orphan card: it enters a phase and no one is notified, because no rule defined who answers for it there. The second is subtler: the wrong owner, or worse, the accidental replacement. You set up an assignment in the analysis phase, and it erases the requester who had been the owner since the card was opened. The card gained a new owner and lost the old one, and the traceability of who started it went with it.
The question that guides every decision below is: does this phase's owner need to add to the people already following the card, or replace them? In most processes, the answer is add. Someone who opened the request stays interested in how it ends.
When a fixed per phase assignee is already enough
The most common case has the most direct solution. If every time a card enters a phase the owner is always the same person or the same pair of people, a fixed per phase assignment solves it with one automation.
The reasoning: you define a rule that fires when the card enters the phase and adds that phase's owner. One detail worth your peace of mind: the native add owner action sums the person to the existing owners, it does not replace them. Whoever was already on the card stays. And the owner defined this way remains with the card through the following phases, it does not disappear when the card advances. In other words, the native mechanism already handles accumulated ownership across the flow, without you needing anything beyond the automation.
Decision criterion: use a fixed per phase assignment when each phase's owner is predictable and stable. This fits most approval processes with one defined approver per step.
- Learn more: Automation: update the assignee field for the step by step of configuring the rule.
When the owner depends on the card's context
Not every process has a fixed owner per phase. In many, who approves depends on something only known once the card is created: the requester's department, the purchase amount, the country of operation. A request from Engineering goes to one approver; the same request from Sales goes to another.
Here the decision changes. Instead of pinning a person into the phase rule, you store the relationship between context and owner in an approvers database, each record tying a department to its respective approvers. The card connects to that record through a connection field filled in at entry, and the automation assigns the owner by pulling the value from inside the connected record, dynamically, rather than a name hardcoded into the rule.
The practical upside: when an approver changes, you edit one record in the database and every future process already respects the change. You do not have to reopen automation by automation to swap a name.
Decision criterion: use database assignment when the owner varies according to a card's data and you want a single place to maintain that relationship. The more "who approves" changes over time, the more this path pays off.
- Learn more: How to create an automation to define assignees via database to see how the database and the connection are built.
When the goal is to balance the team's workload
There is a third scenario that is not about who the right owner is, but about not overloading the same person every time. Support queue, triage, document review: any qualified team member can take it, and what you want is to distribute evenly.
For this there is round robin distribution. Instead of sending every card to one person, the automation rotates among the members you defined, handing out cards uniformly across them.
Decision criterion: use round robin when anyone on the list can take the card and the goal is load balance, not matching a context. If it matters *who* takes it, that is database or fixed assignment. If it matters that the queue moves fairly, that is round robin.
Round robin is a paid plan feature. Before designing your process around it, confirm availability on your plan so you do not build a dependency your account cannot support.
The golden rule: one owner per phase, and no accidental replacement
Regardless of the chosen mechanism, two modeling guidelines support all of them and prevent future rework.
The first: keep a single assignee field per phase. Multiple assignee fields in the same step create ambiguity about who actually answers for the card there, and complicate any automation or integration that depends on that value.
The second: you want to add owners, not swap them. Since the native assignment already adds without replacing and the owner persists through the following phases, the native mechanism covers most processes well. In external integration scenarios or bulk assignment outside the normal phase flow, there is a more technical path via HTTP request that guarantees the same add without replace behavior. That path belongs to the technical fundamentals article, not to a step you configure day to day.
- Learn more: Technical fundamentals and Service Account for the HTTP assignment scenario.
What happens if the owner leaves the company
One caution is worth noting that only shows up months after everything is set up. When the assignment pins a specific name, whether fixed in the automation or as a member of a database record, that person leaving the company breaks the rule silently: cards start entering the phase without the expected owner.
That is why the database path scales better in the long run. Replacing an approver who left becomes editing one record, not hunting down every automation that mentioned that name. And keeping assignments backed by the Service Account, rather than personal accounts, prevents a departure from interrupting the process. This is the kind of decision that does not hurt now and saves you a whole afternoon of maintenance later.
Before moving on, confirm you understand:
☐ The difference between an ownerless card and an owner accidentally replaced, and why the native assignment adds instead of swapping
☐ Which of the three paths fits your case: fixed owner per phase, contextual owner via database, or round robin to balance load
☐ That you can decide, right now, which mechanism to apply to the next work phase of your process so that no card enters it without an owner
