How to build a back and forth flow in Pipefy

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

A revision cycle needs a defined destination, a reason for returning the request, and a clear route back to review. Moving a card manually records a transition, but the move alone does not ensure that the reason for the revision and the expected response are captured in a structured way.

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.

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.

Preserve the history of each round

Each revision adds context: what needs to change, who requested the change, and when. Keep that record separate from the fields that will receive the corrected answer. Replacing an answer should not replace the record of why the revision was requested.

Keep a dedicated Long Text field for revision history. Append the reason, date, time, and the person requesting each revision before clearing or replacing the working fields. Preserve earlier entries when adding a new round. For example: a reimbursement receipt is unreadable, the reviewer requests a new file, and the next review records whether the replacement resolves the pending issue.

Controlled movement on the return

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.

Define the dependencies between recording the reason, notifying the requester, preparing the fields, and moving the card. An action button or an automation can support the decision to return a request. The order of dependent actions must be designed and tested; sharing a trigger does not, by itself, guarantee their execution order.

Choose the event that represents the reviewer's decision and the rules needed for the return. Document the trigger, conditions, and destination so another person can understand the flow. Read the official automation actions guide for the supported actions.

The label that signals the return

A Returned for revision label makes requests awaiting correction recognizable in the queue. Plan its update as part of the revision flow and define when it should be removed or retained. Keep labels used to describe a particular phase separate from labels intended to accompany the card throughout the process.

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.

Use the phase's late alert to track how long a card stays in the revision stage. This is separate from the card's due date. Agree on the expected response time, the person who follows up, and what happens after the limit. Rules that calculate a due date using a business calendar serve a different purpose from the phase alert. See the official alert guide.

Prepare the next round and test the return

Clear only information that must be supplied again, after preserving the revision record. Keep valid request data available. Attachments contain lists of files: decide whether the next round adds a document, removes an obsolete file, or replaces the list. In an API operation, ADD, REMOVE, and REPLACE express different intentions. See the field update operators.

Agree on when repeated revisions require escalation. A counter is useful when the team needs that indicator and can maintain it reliably. If an existing integration can update it, assess that option; if it adds several automation tasks only to count rounds, compare the cost with using the recorded history.

Before releasing the change, run two consecutive revision rounds with a test request. Check that both reasons remain with date and time, the correct fields are ready for another answer, the label represents the current situation, and the request returns to the expected reviewer. Also check the agreed phase alert.

Before moving on, confirm that 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

☐ You can define and test the dependencies between the revision record, field updates, labels, and card movement.