👤 For process owners and pipe administrators
🔐 Modeling guidance; feature access depends on company subscription and permissions
🎯 For people expanding operations while keeping ownership and progress clear
A purchase request involves supplier quotes, approval and corrections. As more people take part, it becomes harder to tell who needs to act, what is missing and when the request is complete. Before adding fields or stages, review how these deliveries relate to one another.
By the end of this article, you will know how to define process boundaries, identify work that needs its own tracking and review data, ownership and dependencies before expanding operations. A scalable process remains understandable and governable as requests and changes increase.
What you will learn:
Define the outcome and process boundaries
In Pipefy, a pipe organizes a process, phases represent its stages and each card tracks one instance of work. In purchasing, a card might represent a request that needs review and approval.
Before building, complete two sentences: “This card represents...” and “This work is complete when...”. Identify who provides the inputs and who receives the final delivery.
Suppose the process ends when the purchase request is approved or canceled. Making the payment is another delivery with its own owners and conditions. Making that boundary explicit helps determine which information and activities belong in the workflow.
For a refresher, read about pipes, phases and cards, in Portuguese. For more on inputs and outputs, see how to map and model a process, in Portuguese.
Model the work that needs orchestration. When a delivery depends on information from an ERP or CRM, define the exchange required and who maintains each part of the process.
Organize phases around the work required
A phase should make the work expected at that point clear. For each stage, define what it receives, which activity takes place, who owns the work and what allows it to move forward.
In a hypothetical purchasing example, the review receives the business need and requested amount. The owner checks whether there is enough information to decide. A missing justification sends the request for correction; complete information allows it to proceed to approval according to company rules.
Agree on an expected turnaround time. If there is little history to draw on, establish a reference with the team and revisit it as you observe the operation. A deadline written in a description guides people; configuring deadline rules and alerts requires a separate decision.
The number of phases can signal that a design needs review, but it does not settle the decision on its own. Ask whether each stage represents distinct work or repeats a decision already being tracked. If colors indicate ownership, use the convention consistently and explain it in text.
To explore mapping and plan implementation around these decisions, take the Process Implementation Certification, in Portuguese, at Pipefy Academy. Access to lessons requires logging in or creating an account.
Separate deliveries that need their own tracking
Consider another pipe when the delivery changes scope, one request generates several activities with their own progress, or teams need different access. A change of owner alone may still belong to the same request.
In purchasing, three suppliers may send quotes on different dates. If each quote needs its own owner, deadline and completion, consider a process related to purchase requests. The request retains the context of the purchase.
Before separating the work, agree on the information passed between processes, when the next team takes ownership and what must be complete before the request proceeds. Creating a connection does not, on its own, define those continuity rules.
During employee onboarding, HR and IT may also have related deliveries with different access needs. Review the data each role needs to see, including through connections. Separate pipes do not automatically isolate information.
Explore the criteria in when to split a process across multiple pipes, in Portuguese.
Give process data a clear purpose
Ask whether information describes work in progress or serves as a reference for several requests. A purchase amount belongs to the request. A supplier contact may be reused across purchases.
Use a pipe to take requests through to an outcome, and consider a Database for reference records. Reusable records also need maintenance: decide who updates the data and which source should guide a lookup.
For each piece of information, identify the decision it supports and when it becomes necessary. This helps collect it at the right moment and avoid copies without a defined purpose. When two sources provide the same information, agree on which takes precedence and how to handle differences.
See examples of where to organize each type of information.
Define who controls decisions and corrections
For each critical transition, such as purchase approval, record the required condition, who authorizes the decision and which mechanism moves the work forward. If automations, flows or AI Agents take part, define each participant's role in that transition.
An integration may supply information for review, while a rule advances the request after the decision is recorded. The design should identify the event that allows progress and how to check that the necessary data is complete. Make that decision before configuration.
Plan the correction path too: who receives the pending work, what they must correct, which context must be kept and how the request returns to review. Before clearing or replacing information, consider what must remain available to explain the earlier decision.
When AI Agents take part, describe their context, inputs, action and expected output. Decide who reviews situations requiring human judgment. Add capabilities when they have a clear role in the process.
Plan participation, deadlines and communication
People participate in different ways. Some submit requests, some run the operation, some provide a decision and others maintain the process. Define what each role needs before choosing its channel and access.
A Portal can bring public forms together to make submitting requests easier. For other interactions, assess forms and Interfaces based on what people need to view or provide. Check feature availability and company permissions.
In the onboarding example, IT needs to know when to start preparing access, which information it receives and how to report completion. The agreement should identify who receives a message, what the message asks them to do and which deadline guides the next action.
Record the time zone reference and check its application in the relevant deadline settings. Define who may change rules and access too. New participants can then join under criteria the team already understands.
Document and test before expanding
Use the pipe description as a reference for its purpose, stages and process owner. Keep names consistent and record why the relevant fields, rules and connections exist. See how to document processes for easier maintenance to organize that record.
Before expanding, review expected request volume, action frequency and external dependencies. Identify who maintains each connection and how the team follows an exception. Compare execution approaches using maintenance needs and applicable consumption, without assuming fewer rules mean lower costs.
Test with fictional data in a testing context agreed by your company:
- A complete request reaches the expected decision.
- An incomplete request goes for correction and returns to review with its context preserved.
- Each role can perform its intended activity and view authorized information.
- Related deliveries retain their reference to the request and follow the agreed continuity conditions.
Ask someone else to use the documentation to explain who takes ownership of an exception and what allows it to be closed. If the answer depends on the builder's memory, complete the record before expanding. Update documentation after changes and tests.
Before moving on, confirm that you understand:
☐ What each card represents and which outcome completes the process.
☐ Which deliveries need their own progress and how they relate.
☐ Which data is reused, who controls progress and how corrections return.
☐ How to review access, deadlines and dependencies before changing the structure.
Ready to review your process boundaries? → When to split a process across multiple pipes, in Portuguese
