Who controls card movement in Pipefy?

A purchase has the manager’s approval but is still waiting for confirmation that it was registered in the ERP. Meanwhile, the purchasing team considers it ready for execution. When each participant uses a different signal to consider a stage complete, it becomes difficult to tell whether the request is actually ready to advance.

By the end of this article, you will know how to separate a business decision from a card move, define the roles of automations and flows, and document how to handle pending requests. The purchasing example is hypothetical, so you can apply the criteria to your own process.

What you will learn:

Separate the decision from the move

In Pipefy, a card holds information about a request, and its phase shows the stage of work. Moving it should reflect actual progress: an analysis is complete, an approval has been recorded, or the request is ready for another team.

Before choosing what will move the card, distinguish four responsibilities:

• Decide: who confirms that the request meets the business criterion.
• Inform: where the evidence needed for that decision comes from.
• Execute: which mechanism moves the card when the criteria are met.
• Maintain: who reviews the rule and follows up on exceptions.

In the purchasing example, the manager approves the expense, the ERP confirms registration, and a pipe automation can move the card according to the agreed rule. The person maintaining the process checks that this combination still reflects how the work should happen.

The card assignee may carry out a task without being the person who approves the purchase or maintains the integration. Document those differences so the team knows whom to contact.

For more on the relationship between an event, a condition, and an action, read How automations work in Pipefy.

Define where the movement rule belongs

When information comes from other systems, a recommended approach is to keep card movement in pipe automations and use Pipefy Integrations flows to supply the required data. A flow is the sequence of a trigger and actions that orchestrates the integration.

For the purchase, the design could work like this: the manager records approval, the integration returns the ERP confirmation, and the automation evaluates whether the request can advance. Agree with the integration maintainer on which updates should trigger that evaluation, including when the evidence arrives in different orders.

Make the division explicit: the flow supplies confirmation, and the automation executes the agreed move. If a pipe rule and an integration step independently command the same transition, review with their owners where that decision should belong.

Centralizing movement does not require a single automation for the entire process. Each transition can have its own rule, while notifications and updates retain separate responsibilities. What matters is being able to identify what controls each move.

This is an architectural choice. Integrations can also move cards through the API, but the technical ability to do so does not, by itself, determine where the rule should live.

Align allowed paths with the team’s decisions

Approving a purchase and moving it to execution have different meanings. Approval records a decision; movement indicates that the stage’s criteria have been met. When external confirmation is still pending, approval alone may not mean the work is complete.

For each critical phase, agree on three points:

• Destination: which stage matches the outcome, such as continuing, requesting changes, or closing the request.
• Evidence: what information needs to be available before leaving the phase.
• Participation: who can record the decision and who reviews an exception.

For approvals and requests for changes, prefer paths controlled by rules or actions defined for that decision. The phase change can then reflect the work performed. Check that destinations, required information, and access permissions match that design in the current process.

Having an assignee helps identify who works on the request, but it does not replace an access review. To explore how people and available paths fit together, read Phase movement control.

Plan for delayed responses and exceptions

External confirmation does not always arrive at the same time as an internal decision. Define what should happen while the process waits and who follows up. For the purchase, the question is: who checks the missing ERP confirmation before execution is released?

Also consider requests returned for changes. Imagine the requester revises the purchase, and a confirmation for the earlier request arrives afterward. Agree with the integration maintainer on how to recognize the valid version before allowing the card to advance. The earlier response should not count as sufficient evidence for the revised request.

If an urgent request needs an exceptional review, establish who can authorize it, what evidence is required, and where to record the reason. The exception needs a path that makes sense to whoever receives the request next.

When the rule is already defined but the card does not reach the expected destination, continue with How to diagnose an automation that stopped working, gathering an example of the expected and observed outcomes.

Document and test one transition before expanding

Choose a critical phase change and document how it should work. The matrix below illustrates the purchasing example. It is a documentation model; adapt the stages and criteria to your process.

Compare this record with existing automations and flows before proposing changes. Validate the division of responsibilities with the process team and the people maintaining Pipefy Integrations.

In a suitable test environment, check approval with confirmation, pending confirmation, rejection, and requests returned for changes. Include the possible orders in which evidence arrives, as well as repeated or delayed responses. For each scenario, define the expected destination and the person who should follow up before running the test.

After validation, keep the record accessible in the process documentation and link to it from the pipe description. Extend the model to other transitions as the team becomes able to explain and verify each rule.

Before moving on, confirm that you understand:

☐ Who makes the business decision and what evidence allows the request to advance.

☐ Which mechanism executes each move and who maintains the rule.

☐ How the process should handle waiting, revisions, and authorized exceptions.

☐ Which transition you will document and which scenarios you need to test.