👤 For process owners and pipe administrators
🔐 Modeling guidance; features depend on your plan and account permissions
🎯 For anyone organizing related deliverables while keeping track of the whole process
A purchase request is underway, but one supplier has sent a quotation, another has yet to reply, and a third needs to revise its proposal. Whoever owns the request needs to understand these differences before deciding what happens next. Similar questions arise when employee onboarding brings together HR and IT activities with separate deliverables and access needs.
By the end of this article, you will be able to decide which stages belong together, which deliverables need their own workflow, and what to define to keep the processes working together.
📖 What you will understand here:
Start with what each card represents
In Pipefy, a pipe organizes a workflow. Phases represent its stages, and a card is the request or work item tracked through that flow. Before deciding how many pipes you need, describe what each card represents from start to finish.
For a purchase request, assessing the need and approving the request may be stages of the same work item. The person responsible changes, but the request remains the object being tracked.
Now imagine the request requires three supplier quotations. Suppliers respond at different times, may need clarification, and each proposal needs attention. This raises a different question: does each quotation need its own owner, progress tracking, and completion criteria?
If it does, consider a quotations workflow linked to the requests workflow. The purchase request remains the reference for the overall need, while each quotation represents a related deliverable.
Before creating another pipe, complete two sentences: “This card represents...” and “This work is complete when...”. If your answers change depending on the activity, consider whether you are tracking different deliverables together.
Recognize the signs that separation may help
Three situations can help you identify when another pipe could make the work easier to understand. Assess each one against what the team needs to deliver.
The scope of the deliverable has changed
An approved request may lead to work with a different goal, different information, and a different definition of completion. In that case, assess the new work as a process in its own right.
In purchasing, deciding what to buy and tracking payment are related deliverables, but they answer different questions. Completing the request assessment does not mean the payment has been completed.
One request creates several deliverables
A relationship of one to many occurs when a request creates several activities of the same type, each with its own progress. A request linked to several quotations is one example.
Representing each quotation as a card lets the team track responses individually. The original request retains the context that brings the work together. Explore orchestration between connected pipes, in Portuguese, to understand that relationship further.
Teams need different access
HR and IT can participate in the same onboarding journey without needing the same information. If the IT activity has its own deliverable and different access requirements, consider a separate workflow and define what information the team needs to perform the work.
When separating pipes, review the connections too. Connection fields grant access to data in connected pipes and cards. Before sharing information, check what each user role can view; separation alone does not guarantee isolation.
- Learn more: read what a connection field is to assess information sharing between processes.
Identify when to keep the same pipe
A change of owner may simply mean the work is moving to the next stage. If assessment and approval still concern the same request, with a continuous deliverable and suitable access, keeping one pipe may make the work easier to follow.
A large number of phases is also a reason to review the design. Before separating the work, ask whether every phase represents necessary work, whether some repeat the same activity, and whether the card still tracks the same request.
Use this comparison as a starting point:
| Situation | Decision to assess |
|---|---|
| Assessment and approval of the same request | Keep the stages in one pipe if continuity and access meet operational needs. |
| One request needs several quotations | Separate quotations when each needs its own tracking and completion. |
| Teams with different deliverables and access needs | Consider separate pipes and review information shared through connections. |
| A workflow with many phases | Review the stages and scope before deciding to split. |
A different deadline or owner helps describe how work happens, but does not require another pipe. Separation should clarify what each deliverable represents and who is responsible for it.
If you need a refresher on processes, permissions, and connections before reviewing your design, continue with Pipefy Academy's Process Manager Certification.
Plan the handoff between processes
Once you identify a deliverable that needs its own workflow, define how it relates to the original request. Make that decision before configuring the handoff.
For the quotations example, agree with your team on:
- When each quotation starts. Define the event that authorizes opening the work with a supplier.
- What information must accompany the work. Identify the request, what needs to be quoted, and what the receiving team needs to act.
- Who owns the follow up. Each deliverable needs a clear owner.
- When the request can move forward. Decide whether every response is required or whether another business criterion applies.
- How changes are handled. Agree on what happens when the request is canceled, a quotation is replaced, or work is returned for changes.
Recording these decisions gives both teams a shared understanding of the handoff. It also distinguishes completing one quotation from completing the entire request.
A connection links the work items. Updates between them need defined rules. Before relying on one card's completion or cancellation to update the others, check the relevant configuration.
If the handoff involves creating cards automatically, the pipes must be connected first. Required information for the destination must also be available when the card is created. Refer to the checks for automations that create connected cards when you reach implementation.
Keep the full picture and review the design
Giving each deliverable its own workflow still requires a view of the whole process. Document each pipe's purpose, the relationships between work items, the information shared, and who maintains the handoff rules.
If the need is only a management view, consider an Interface that brings together relevant information from several pipes. Creating a pipe just to repeat statuses adds another place to maintain. First distinguish the work that needs doing from the view needed to monitor it.
For processes that are already connected, the Map helps you inspect their relationships before making changes. The Community introduces this capability in Map: faster opening and connection volume visibility, available in Portuguese.
Before changing the live operation, check the proposed design with fictional data in a test environment. Include a request with one deliverable, another with several, a case with missing information, and a cancellation. Check access for every role involved too.
At any point, you should be able to answer: what remains to be done, who needs to act, and which deliverable allows the process to move forward?
Before moving on, confirm that you understand:
☐ A phase represents a stage; another pipe can represent a deliverable with its own workflow.
☐ A change in scope, a relationship of one to many, and different access needs help you assess separation.
☐ A change of owner or a large number of phases does not, on its own, determine whether to separate.
☐ Handoffs need defined information, ownership, and completion criteria.
☐ You can choose a real request and map what belongs together and what needs its own tracking.
Ready to plan how information moves between deliverables? → Automations between pipes: connecting processes, in Portuguese.
