👤 For pipe admins and process owners
🔐 Automations are available on all plans, with plan specific usage limits
🎯 For people preparing a change to a rule their team already relies on
Your purchasing team needs to change who reviews higher value requests while new requests keep arriving. Updating the routing also means considering the information reviewers need and the communications that follow. Understanding how the rule fits into the process is part of preparing the change.
By the end of this article, you will know how to define the change, record the current rule and identify the evidence needed to decide whether it is ready for use. Start with the expected outcome and the paths that must stay the same.
What you will learn:
Define the outcome before editing the rule
An automation connects an event to an action. The event starts the execution, such as a field update; the action is what should happen, such as moving a card. Conditions, when used, determine which cases the rule applies to.
Before editing, describe both the current and intended behavior. Suppose the purchasing process owner requires an additional review only for requests above R$ 5,000. In this example, a request for R$ 5,000 stays on its usual path, while one for R$ 5,001 goes to the additional review. Agree on that boundary before changing the condition.
Check with the process owner whether the business criterion is changing or the configuration needs to match an existing criterion. That distinction determines what to change and what to preserve. For the documented event and action logic and administrator access requirements, see how to create automations.
Map what happens before and after the action
Consider the request arriving at the rule and the work that follows. Which information must be present? Who receives the card? Does another rule send a message, update information or start work in a connected process?
In the purchasing example, a request could reach the additional review without the information the reviewer needs. Correct routing alone does not demonstrate that the process is ready to work as intended.
Review the data required for movement. The Help Center explains which fields and dependencies to check when moving cards. You can also read about the Move Card test and its scope, in Portuguese. Together, these references help distinguish the card requirements from the outcome the team needs.
A useful review question: if this action completes correctly, will the next person have the information needed to continue the work?
Record the current rule and define the change
Keep a written reference before editing. Use the documentation your team already maintains to record:
- The automation name and location, including its pipe and phases.
- The current event, conditions and action.
- The reason for the change and the intended behavior.
- The paths that must stay the same.
- The date and the people responsible for editing and validation.
This record helps compare the intended outcome with what you observe. It also explains the decision to whoever maintains the process next. It is a team documentation practice.
If preparing an alternative from the existing rule is useful, Pipefy lets you duplicate an automation and creates the copy disabled. First decide which rule should be active and why. The copy does not demonstrate the alternative behavior, and two equivalent active rules may act on the same scenario. Duplication is a preparation option rather than a required step for every edit. See the automation management guide, in Portuguese for the procedure.
Choose evidence that demonstrates the result
For the Move Card action, Test Action evaluates movement without moving the card or changing its data. The result helps assess that action against the pipe configuration. It does not, by itself, demonstrate the triggering event, every business criterion or subsequent communications.
Define your scenarios before validation. The table follows the hypothetical purchasing example. The amounts represent a team decision rather than a standard Pipefy rule.
| Scenario | Expected outcome | What to check |
|---|---|---|
| Request for R$ 5,001 | Goes to the additional review. | Routing and information needed for the review. |
| Requests for R$ 5,000 and R$ 4,999 | Stay on the usual path. | Whether the condition respects the agreed boundary. |
| Request with no amount | Receives the handling agreed with the process owner. | What that handling should be before validation. |
| Movement requires mandatory information | Card movement requirements are met. | Required information and the applicable test result. |
| A communication follows approval | Recipient and sending time match the agreement. | The subsequent effect beyond the movement test. |
Add the observed result and a decision for each scenario to your record. For example, if the movement test passes but there is no evidence that the R$ 5,000 boundary was respected, validation of the criterion is still pending.
Account for the scope of each test. The validation without movement described here applies to Test Action for Move Card. Do not assume the same behavior for email sending or other actions. If a check could produce real effects that the team has not yet controlled, agree on how to validate it with the process owner before putting the change into use.
Build on the rule logic: if you need to revisit events and actions before defining scenarios, continue with the Pipefy Process Automation Certification.
Agree on timing and what to monitor
The change is ready to proceed when relevant scenarios have enough supporting evidence and the team knows what to monitor. Agree on who will edit the rule, who will confirm the result and when the change will happen. Keep the decision open if an essential check is still missing.
Consider requests already in progress. Before making a rule inactive, identify the work that depends on it and how the team will handle those cases during the change. Do not assume that editing the rule will make existing cards go through the workflow again.
Define a concrete signal for stopping the change. In the example, that might be a request for R$ 5,000 reaching the review reserved for higher amounts. If you find a discrepancy, separate two decisions: correcting the rule behavior and addressing requests already affected. Disabling an automation does not undo messages, card movements or updates that have already happened.
Before moving on, confirm that you understand:
☐ The intended outcome and the paths that must stay the same are defined.
☐ The current rule and its dependencies are recorded.
☐ Each test has a known scope and corresponding evidence.
☐ People are responsible for the change, monitoring and the decision to stop.
Choose a real change and prepare this record before editing. If the change involves movement, use the next article to assess how that action test contributes to your review.
Ready to assess card movement? → Explore the Move Card test before publishing, in Portuguese.
