👤 For pipe administrators
🔐 Available on all plans
🎯 For those who have already created a pipe and want to ensure it’s well configured before launching to the team
Creating the pipe is the first step. Configuring it is what determines whether it will work for a team of two or thirty, whether the right data appears in the right place, and whether the process stays protected from unwanted edits.
Most adoption problems that appear weeks after launching a pipe are rooted in configurations skipped in the rush to start: generic names that confuse the team, visibility too open or too closed, cards that don’t show the right information in the kanban.
This article covers the configuration decisions that have real operational impact. You’ll leave knowing what to adjust and why.
📖 What you’ll decide here:
First: one pipe or more?
Before configuring any property, it’s worth answering the question that most impacts long-term process health: does this flow fit in a single pipe or does it need to be split?
The consensus among those who build processes professionally in Pipefy is to keep between 10 and 15 phases per pipe. Above 10, it’s worth evaluating a split. Above 15, the pipe is unwieldy and maintenance starts to be problematic.
But the number of phases is only one of the criteria. The table below shows when it makes sense to keep everything in one pipe and when splitting is necessary:
| Keep in the same pipe | Create a separate pipe |
| The process has a single scope from start to finish | The scope changes mid-flow (e.g., a request becomes a quote) |
| The same team operates all phases | Different teams need distinct permissions |
| Fewer than 10 phases | More than 10 phases: consider splitting |
| 1-to-1 relationship between the card and the request | A request generates multiple child records (1-to-N relationship) |
A common mistake is creating empty management pipes just for managerial visibility. The recommended practice is to use Pipefy Interfaces to provide a consolidated view of multiple pipes without creating parallel structures that need to be maintained.
Phase colors: a reading system, not decoration
Phase color is a visual governance resource. Used deliberately, it allows anyone to look at the kanban and understand who is responsible for each step without needing to open a card.
The recommended logic: use the same color for phases that belong to the same agent or team. Approval phases, all in the same color. Execution phases by the IT team, all in another color. Phases under the requester’s responsibility, in a third.
Example in employee onboarding:
Blue: phases under HR responsibility (Pending documentation, Documentation under review).
Orange: phases under IT responsibility (Equipment requested, Access in configuration).
Green: Completion phase (Completed).
A manager looks at the Kanban board and immediately knows which team is responsible for each task, without even opening a card.
Pipe icon and name. Workspaces with multiple pipes need quick visual differentiation. Use distinct colors between pipes from different areas and icons that enable immediate recognition, without needing to read the full name.
Card name. Pipefy calls process items "cards" by default. Renaming to "Request," "Candidate," or "Ticket" reduces friction for the operational team: the creation button and interface texts reflect the process vocabulary.
Hide-by-phase conditional: maintenance protection
A little-known but highly valued best practice among those who maintain complex processes: use a single conditional per phase to hide all fields and show only those needed for that step.
The reason isn’t aesthetic. It’s operational: without this reference conditional, the order in which conditionals are evaluated can create latency conflicts. With it, whoever needs to maintain the process in the future — even without knowing the original logic — can understand what’s being displayed in each phase without having to analyze dozens of isolated rules.
Never duplicate fields by copying an existing one. Cloning a field generates a new ID unpredictably, which breaks automations and filters that reference the original field. If you need a similar field, create it from scratch with a name designed around the ID that will be generated.
About field names: don’t number fields ("1. Name," "2. Job title"). If the order changes, the numbers fall out of sync and the team starts ignoring the numbering. Use descriptive names that make sense regardless of position.
Visibility and security: settings that shouldn’t be left for later
Three security settings must be activated before launching any pipe to the team. These are decisions that become harder to correct once the process is in production with real data:
Private pipe by default. A public pipe appears for all company members and can be accessed by anyone. Start private and add members deliberately. It’s easier to open access than to restrict it later.
Card deletion restricted to administrators. A card accidentally deleted has no native recovery. Restricting deletion to admins from the start prevents data loss from operational error.
Editing restricted to the card’s assignee. Pipefy has a setting in the pipe options that allows restricting field editing to the card’s designated assignee. For processes with multiple members, this restriction reduces edits outside the expected flow and maintains data integrity.
Visibility and permissions are separate decisions. Changing the pipe from public to private doesn’t automatically remove those who already have access. Check the member list after making the change.
What to configure now and what can wait
Configure before launching:
- Architecture decision: one pipe or multiple (scope, teams, number of phases)
- Color of each phase by responsibility
- Pipe icon and name; card name
- Visibility: private
- Security: deletion restricted to admins, editing restricted to the assignee
Can wait until the pipe is in use:
- Hide-by-phase conditional (configure after all fields are created)
- Custom roles (only create if default roles don’t work after real use)
- Pipe clone to replicate across other teams
Before launching to the team, confirm:
☐ The process scope fits in a single pipe
☐ Each phase has a color representing its responsible agent
☐ Pipe is configured as private
☐ Card deletion restricted to administrators
☐ Field editing restricted to the card’s assignee
☐ Card name uses the process vocabulary, not the generic default
