👤 For all users
🔐 Available on all plans
🎯 For those who have already structured their phases and want to ensure they are well named, described, and ordered
Naming phases seems like a cosmetic decision. In practice, it’s one of the decisions that most affects operations. Ambiguous names create confusion about where to place a card. Phases without descriptions leave the team without deadline and responsibility references. Orderless sequencing makes reports difficult and automations confusing to maintain.
The shift that resolves most problems is simple: a phase name should describe the state of the card at that moment, not the action happening in it. And the phase description is where SLA, responsibility, and operational guidance are persistently documented.
📖 What you’ll learn here:
The most common mistake: phases that describe actions, not states
When someone creates a pipe for the first time, the natural tendency is to name phases like tasks: "Analyze," "Approve," "Send," "Finalize." It seems logical because that’s how we describe work in meetings.
The problem is that a phase in the kanban doesn’t represent what someone is doing. It represents where the card is. And "where the card is" is always a state, not an action.
When the phase is called "Approve budget," it’s unclear whether the card is waiting for approval, being analyzed, or already approved. When it’s called "Awaiting approval," there’s no ambiguity: the card is sitting there until someone makes a decision.
| Action-oriented (avoid) | State-oriented (use) |
| Request received | Under review |
| Approve budget | Awaiting approval |
| Send documents | Documentation pending |
| Configure access | Access in configuration |
| Finalize onboarding | Completed |
Quick test: read the phase name out loud and complete the phrase "The card is...". If it completes naturally, the name is state-oriented. If it sounds strange, it’s probably an action disguised as a phase.
Criteria for naming phases consistently
Beyond state orientation, three criteria keep naming consistent throughout the pipe:
Clarity about responsibility. The phase name should implicitly indicate who acts or who waits. "Awaiting manager approval" is more informative than "Approval" because it makes clear the next step isn’t the operator’s. The team knows without opening the card.
Consistency of tense. Mixing "Under review" with "Documents sent" and "Approve" within the same pipe creates visual noise. Choose a standard and stick to it. The standard matters more than which standard.
Uniqueness. Each phase must have a name that doesn’t confuse with any other in the same pipe. If you feel the need to add "final" or "new" to differentiate, they’re probably the same phase or one of them doesn’t need to exist.
Phase names appear in reports, filters, and automations. A phase renamed after automations are active requires manual review of all rules that reference that name. Decide the naming standard before creating automations.
Phase description: where SLA and responsibility are documented
Each phase has a description field that most teams ignore. That’s a mistake: the phase description is the only place where SLA, owner, and operational guidance are persistently recorded, visible to anyone who opens the pipe, including those who join the team later.
The standard recommended by the Pipefy specialists team defines three elements for each phase description:
| Element | What to record | Example (phase: Documentation pending) |
| SLA | Expected deadline for this step | SLA: 2 business days |
| Owner | Who operates or approves in this phase | Owner: HR Analyst |
| Brief guidance | What must be done or verified | Request the employee to send their ID, Tax ID, and proof of address via the form. |
A well-described phase eliminates the need for parallel documentation. Whoever opens the pipe and hovers over the phase immediately sees: the expected deadline, who is responsible, and what needs to be done before advancing the card.
Full example for the "Documentation under review" phase of onboarding:
SLA: 1 business day.
Owner: HR Analyst.
Verify that all documents were submitted correctly. If any are missing or illegible, move the card to Pending adjustment and notify the employee.
Phase descriptions with SLA have a positive side effect: they force the team to define real time expectations for each step before launching the process. Teams that have never defined SLA use this moment as their first conversation about what a reasonable deadline is.
How many phases a pipe should have
There’s no fixed ideal number, but there’s a clear criterion: each phase must represent a distinct state that changes who is responsible, what is waiting, or what information needs to be collected.
The consensus among those who build processes professionally in Pipefy is to keep between 10 and 15 phases. Above 10, it’s worth evaluating splitting the process. Above 15, maintenance starts to become problematic.
The sign that there are too many phases: the team starts skipping phases, moving cards two or three stages at a time, or creating cards directly in mid-process phases.
The sign that there are too few phases: cards get stuck for a long time in a single phase without being able to understand which sub-step they’re in or who is responsible. This usually appears as a phase called "In progress" that accumulates everything.
Archive and cancellation phases have a specific role: they are final destinations for cards that have left the normal flow. Visually separate what’s in execution from what has been completed, archived, or canceled.
Logical ordering: from triage to completion
The order of phases must reflect the real sequence of process decisions. Two criteria that work in practice:
Responsibility changes from column to column. When the card advances to the next phase, who acts changes. If two consecutive phases have the same responsible person doing the same type of work, the ordering may be fragmenting a step that should be continuous.
From triage to execution to completion. Most processes start with an entry, go through analysis or execution steps, and end in a final state. This left-to-right flow is what the team should be able to read without explanation.
In employee onboarding, the functional order:
- Request received: process entry, card created by the form
- Documentation pending: awaiting submission by the new employee — SLA: 3 business days
- Documentation under review: HR verifying what was submitted — SLA: 1 business day
- Equipment requested: IT triggered to prepare the setup — SLA: 2 business days
- Access in configuration: IT configuring systems and permissions — SLA: 1 business day
- Completed: employee integrated and process concluded.
Each phase has a state-oriented name, an implicit owner in the name, and a defined SLA. Anyone who opens the pipe understands the flow without needing to ask.
Before publishing the pipe, confirm:
☐ Each phase describes the state of the card, not the action happening in it
☐ The tense pattern is consistent across all phases
☐ No phase has a name that could be confused with another
☐ Each phase has a description with SLA, owner, and brief guidance
☐ Phases with the same owner and no distinct automation have been consolidated
☐ The left-to-right order reflects the real process sequence
☐ There is a clear completion phase separate from the operational phases
