How to structure your process phases correctly

You already have a pipe up and running. The phases are there, perhaps exactly as they came in the template, perhaps with some adjustments you made for your context. The next step is understanding whether each phase is doing the work it should.

A well-structured phase isn’t a matter of aesthetics or preference. It’s what determines whether Pipefy can truly help you: automate transitions, measure cycle time, show where the process slows down, and notify the right people at the right time. All of this depends on phases that represent real process states, not generic categories that group responsibilities of different people.

This article gives you the practical criteria to evaluate your existing phases and decide with confidence when to separate, when to merge, and when what you have is already right.

📖 What you’ll understand here:

What a phase actually does

In Pipefy, a phase isn’t just a named column. It’s a statement about the process state: "this card is here, and that means something specific — someone specific needs to do something specific before it advances."

When a phase fulfills this role, it becomes a control point. The manager looks at the kanban and knows exactly what’s happening with each request. The responsible person knows what needs to be done. An automation knows when to trigger.

When a phase doesn’t fulfill this role — when it’s too generic, when it groups different people’s responsibilities, when it has no clear exit criterion — it still appears in the kanban, but the real process happens outside it: in emails, in comments, in hallway conversations. The pipe becomes a decorative dashboard.

The two criteria that define a well-structured phase

There’s a simple question to evaluate any phase in your pipe:

"Who is responsible for this phase — and what needs to happen for the card to leave here?"

If you can answer this question clearly, the phase is well-structured. If the answer is vague, multiple, or uncertain, the phase has room to evolve.

Criterion 1 — Clear owner. Each phase must have a defined person or role who acts on the card while it’s there. It doesn’t need to be a single named person — it can be "any IT team member" or "the employee’s manager." What it can’t be is "it depends" or "everyone." When responsibility is diffuse, the card gets stuck because no one feels it’s their problem to solve.

Criterion 2 — Defined exit criterion. There must be an objective condition indicating when the card is ready to advance. It can be a completed checklist, a field filled with a specific value, a date reached, or a recorded approval. When the exit criterion doesn’t exist, the card advances on intuition — and this makes both automation and measurement impossible.

When to separate a step into its own phase

The decision to create a new phase should be guided by the two criteria above — not by the desire to detail the process as much as possible. More phases ≠ more control. Right phases = more control.

Separate into its own phase when:

• Responsibility changes. This is the most important rule. When work passes from one person or area to another, that handoff deserves a phase. In onboarding, the moment HR finishes collecting documents and IT needs to start configuring access is a handoff — and it’s exactly where there’s a separate phase in the template. Without this separation, IT doesn’t know when it’s time to act.
• The exit criterion is different. If two steps have distinct completion conditions, they belong in different phases. "Documents collected" and "access configured" are completely different process states — each with its own owner, deadline, and verification criteria. Grouping them in an "In progress" phase makes both invisible.
• You need to measure time separately. If knowing how long IT takes to configure access is useful information for your process, this step needs to be a phase — because Pipefy only measures time within phases. What doesn’t have a phase has no metric.
• You need an automation trigger at this point. Automations trigger on phase events: "card entered X," "card left Y," "card stayed in Z for more than N days." If you want to send an automatic notification to the manager when access is ready, you need an "Access configured" phase to create that trigger.

When not to separate — and why less can be more

The opposite error of having phases that are too generic is having phases that are too specific. A pipe with ten or twelve phases looks detailed but tends to be difficult to operate and impossible to automate coherently.

Don’t create a separate phase when:

• They are actions within the same responsibility. If the same responsible person executes two sequential actions without passing the card to someone else, those actions can be checklist items within a single phase. In onboarding, "introduce the company" and "introduce the workplace" are two checklist items in First day, not two different phases.
• The step is very brief or always instantaneous. If a step takes less than a few minutes and happens without human intervention — like the automatic sending of a welcome email — it doesn’t need a phase. An automation handles it without needing to create an intermediate state in the process.
• You’re modeling exceptions, not the rule. Don’t build phases for cases that rarely occur. If 5% of onboardings have an extra legal approval step, that step can be handled with a conditional field or an optional phase — not as a permanent phase every card will go through.

Quick reference: when to separate and when not to

The onboarding template as a practical reference

The onboarding template applies these criteria in a quite direct way. The table below shows each phase with its owner and exit criterion — the reasoning that justifies the template structure:

What you won't find in the template: a phase for 'sending the welcome email' (it's an automation), a phase for 'HR registration approval' (it's a field within Planning), a phase for 'returning equipment in case of termination' (it's an exception, not the process rule).

How to evaluate your pipe’s phases now

With the criteria in hand, the pipe review is straightforward. For each phase, answer the four questions below:

 Phase review checklist:

1. Who is responsible for this phase?
2. What needs to happen for the card to leave here?
3. Is this phase different from the previous one in owner or exit criterion?
4. Will you want to measure time or create an automation from this phase?

At the end of this exercise, most pipes converge to three to seven operational phases. Not by rule, but because that’s the number that typically emerges when you apply the two criteria to a real process.

FAQ

Is there an ideal number of phases?

There’s no rule, but there’s an observable pattern: processes with three to seven well-defined phases are the easiest to operate, automate, and measure. Below three, the process tends to be under-represented. Above seven, the operation becomes heavy and automations become difficult to maintain. If your pipe is outside this range, it’s worth applying the criteria to see what can be merged or separated.

Can I have optional phases — that some cards go through and others don’t?

Yes. Pipefy allows creating automations that move cards directly from one phase to another, skipping intermediate steps, based on field conditions. If 80% of onboardings don’t need a "Legal approval" phase, you can keep it in the pipe and create an automation that automatically skips that phase for cases that don’t need it.

What if my process has parallel steps — things that happen at the same time?

Phases in Pipefy are sequential — a card is in one phase at a time. For parallel steps, the most common solution is to use checklists within a phase to represent simultaneous actions, or create connected pipes when the parallel steps belong to different teams. The article about automations between pipes covers this pattern.

When does it make sense to have different phases for different onboarding types?

If Full-time and Contractor workflows have completely distinct steps with different owners, separate pipes by type are usually easier to operate. If the differences are only in the fields and documents — but the steps are the same —, a single pipe with conditional fields and automations by contract type works well.

Can I reorganize phases after the pipe already has cards?

Yes. Renaming and reordering phases doesn’t affect existing cards. Deleting a phase with cards inside, on the other hand, permanently deletes the cards — so the recommended practice is to move the cards to another phase before deleting.

Well-structured phases are the foundation of everything that comes after in Pipefy: automations that trigger at the right time, dashboards that show where the process slows down, notifications that reach the right person. You don't need to get it all right the first time — the pipe is editable and will evolve along with the process. What matters now is that each phase of your pipe has a clear owner and a defined exit criterion. With this, the next step — configuring the right fields in each phase — becomes much more direct.