👤 For anyone coordinating approvals or reviews that depend on rounds of revision
🔐 Available on all plans
🎯 So you can make sure every return for revision stays traceable, with history preserved and movement automated between the reviewer and the person doing the work
Every process that runs through approval or review has a moment when something has to go back. A document that arrived incomplete, a request with the wrong amount, a submission missing an attachment nobody sent. The first time it happens, it's usually handled in conversation: a note in chat, an email asking for the fix, and the card sits waiting. By the second and third time, that same fix starts to cost you, because nobody can say anymore how many times that card has gone back or what was asked for in each round.
By the end of this article, you'll know how to structure that back and forth as a deliberate architecture decision in your process: a dedicated revision phase, a record of each round, and a return movement that happens through automation rather than someone remembering to move the card. The goal isn't to stop things from going back, it's to make sure every return leaves a trail.
📖 What you'll take away:
The back and forth is an architecture decision, not a feature
It helps to start with something that changes how you solve this: the back and forth flow isn't a button you switch on in Pipefy. It's a way of designing the process. That distinction matters, because the natural temptation is to send the card back by dragging it manually to the previous phase whenever it needs a fix. It works the first few times, and it erases every piece of information about what happened there.
When you treat the return as part of the design, three questions guide how you build it: where the card goes back to, what gets recorded about the round, and how the movement happens. Answering those three consistently is what turns a process that "sometimes goes back" into one that knows exactly how many times it went back and why.
The question that separates a well modeled back and forth from a workaround is simple: if you removed the person who coordinates revisions today, would the process still tell its own story? If the answer is no, the history lives in someone's head, not in the process.
When to create a dedicated revision phase
The most important design decision is whether the revision deserves its own phase. The answer is almost always yes, for a practical reason: when a card simply goes back to its original phase, it mixes in with the cards arriving for the first time. Whoever works that phase can't tell what's new from what's rework, and the revision loses priority precisely when it tends to be most urgent.
A dedicated revision phase solves this in two ways. It visually separates what came back from what's new, and it gives you a specific place to measure how long revisions take. In practice, it's the difference between "this card is in the review phase" and "this card came back for revision a second time and has been here for three days."
To name that phase, follow the same clarity you use across the process: a name that describes the card's state, not the action of whoever works on it. "Awaiting revision" or "In revision with requester" communicates better than "Fix," because anyone looking at the board immediately understands who the process is waiting on.
If you notice the revision involves several steps, several people, or starts to change the scope of what was being approved, it stops being a phase and becomes a sign you may need an auxiliary pipe dedicated to the review cycle. That's a topic for another time, but it's worth recognizing the limit: a revision phase handles the simple return; multiple correction steps call for a larger structure.
Preserve the history of each round
This is the heart of traceability. Every time a card goes back for revision, some new information appears: what was wrong, what was asked for, when it came back. If that information lives only in the field the requester is about to rewrite, it disappears the moment the fix is made. The second round erases the first.
The team's established practice for this is keeping a dedicated long text field for the revision history. On each return, the reason for that round is recorded there, with a date, before the input fields get filled in again. The original field keeps being edited normally by the requester; the history field only accumulates. By the end of the process, that field tells the whole story: how many times it went back, what was asked in each round, and when.
The decision criterion here is about what needs to survive the next edit. Fields the requester rewrites don't work as history, because each new version wipes out the last. History needs a place that only receives, never replaces.
Automate the movement with a button, never manually
The last piece is how the card moves. And here's a modeling rule that applies to any critical movement, not just this return movement: approvals and revision returns should happen through automation or an action button, never by dragging the card manually.
The reason is consistency. When the return depends on someone dragging the card, everyone does it differently, and the actions that should accompany the move (recording the history, flagging visually that it came back, notifying the requester) depend on the memory of whoever moved it. When the return happens through an automation triggered by a button, all those actions happen together, always, in the same order. The reviewer decides the card needs a fix, triggers the button, and the process handles the rest.
In Pipefy, this movement is built as an automation following the naming pattern `[Trigger Phase] Scenario -> Action`, for example `[Review] Rejected for revision -> Move card`. The steps for configuring that automation is in the Help Center; what matters here is the design decision: the button is the trigger, and the automation carries everything that needs to happen on the return.
Learn more: check the Help Center for the steps for creating automations based on card actions.
The label that signals the return
Once the card comes back through automation, it's worth giving it a visual signal. A "Returned for revision" label assigned automatically by the same automation that moves the card lets anyone looking at the board immediately recognize that this card isn't a new submission, it's a correction round. The Help Center confirms that labels can be inserted into cards automatically through automation, without anyone tagging them manually.
This detail seems small, but it's what closes the loop on visual traceability: the history tells the round in writing, and the label tells it in color.
The SLA for the revision phase
The design closes by defining how long is reasonable to wait for a revision. A good practice is to agree, with the client or the team, on a maximum time for the revision phase, even if it's a generous estimate at first that you refine as the process runs. Without that deadline, a card sent back for revision can sit forgotten indefinitely, and the back and forth you designed to give control becomes a hole where cards vanish.
In Pipefy, this time tracking per phase is configured through the Permanence Alert, which monitors how long a card stays in a stage and triggers when the limit is exceeded. The steps are in the Help Center; the design decision is setting the number: what's the longest fair time for a revision to come back before you need to escalate.
Before you move on, make sure you understand:
☐ Why returning for revision is a natural part of approval and deserves its own phase instead of mixing with the intake queue
☐ That the history of each round needs a dedicated long text field that only accumulates and is never overwritten
☐ That you can build the return movement through an automation triggered by a button, carrying the history record and the signal label along with it
