Lead-state categories
A lead state in RocketLead has three things: a name (what the operator and the customer see), a color, and a category (hidden, but used by analytics).
As of the global-lead-state cutover (June 2026) lead states are org-global. You define one set for the whole organization, then assign states to the pools that should show them. The same state is one record everywhere — renaming or recoloring it propagates to every pool, every board, and every automation that references it. (This replaced the old per-pool model, where each Lead Pool owned an independent copy of its states.)
You can freely name lead states whatever you want. You cannot, however, invent new categories — the set of categories is fixed at the platform level, and they’re what makes the analytics meaningful.
Two layers: the global set and the per-pool assignment
Section titled “Two layers: the global set and the per-pool assignment”| Layer | Where | What it controls |
|---|---|---|
| Global set | Lead-Pools → Konfiguration → Lead-Status (“Lead-Status-Vorlage”) | The states that exist for the org: name, color, category, the canonical default, and the canonical order. Source of truth. |
| Per-pool assignment | A pool’s settings → Lead-Status | Which global states are visible in that pool, their order in that pool, and that pool’s default. Mapping only — it never copies the state. |
Assigning (mapping) a state to a pool controls visibility, not resolvability: a lead or automation can hold a global state that isn’t mapped to its pool and it still resolves — it just won’t render as a board column there until you assign it.
The categories
Section titled “The categories”The platform enum has four values: new, inProgress, completed, notCompleted. In day-to-day operator language we call them:
| Category enum | Operator name | Meaning |
|---|---|---|
new | New (Offen) | The default starting state. Every lead lands here unless the trigger sets a state explicitly. |
inProgress | In progress (In Bearbeitung) | The lead is being worked. Trial-class scheduled, callbacks pending, anything in motion. |
completed | Won (Gewonnen) | The lead converted — they signed up, paid, became a member. Final state. |
notCompleted | Not won (Nicht gewonnen) | The lead didn’t convert. Final state. Several distinct sub-reasons (no-show, no interest, price, unreachable) all map here for analytics. |
A single category may correspond to many named states. “No interest”, “Price too high”, “Multiple no-shows”, “Wrong target audience” all roll up to Not won in reports. The customer sees the granular reason on the lead; you see the analytics aggregate.
Defining the global set
Section titled “Defining the global set”Console → Lead-Pools → Konfiguration → Lead-Status. The defaults are usually fine — change them when:
- The customer uses specific naming you want to preserve (e.g. “Probetraining vereinbart” instead of the default).
- The customer wants additional named states inside a category (e.g. a “Wiedervorlage” state under In progress for callback queues).
For each state:
| Field | Notes |
|---|---|
| Name | What appears in the console. Editing it updates the state everywhere at once. |
| Category | One of the four above. This is the only hidden-but-important field. |
| Color | Cosmetic; pick consistently per category if you can. Recoloring propagates everywhere. |
| Default | The canonical default — used to seed the default of newly created pools. Exactly one state can be canonical default. |
| Order | The canonical order — used to seed a new pool’s column order. |
Assigning states to a pool
Section titled “Assigning states to a pool”Open a pool → its settings → Lead-Status. Here you:
- Assign (map) which global states appear in this pool — pick from the org set via “Status zuweisen …”.
- Reorder them for this pool — the per-pool order is what drives this pool’s board columns.
- Set this pool’s default — the state new leads in this pool get. Each pool has its own default (seeded from the canonical default, but independently changeable).
- Unassign (unmap) a state — it disappears from this pool’s board but the global state itself stays intact and can be re-assigned anytime. Existing leads still holding it keep it.
This is why two pools can show different subsets of the same shared set, in different orders, with different defaults — without ever duplicating a state.
Merging duplicate states
Section titled “Merging duplicate states”Because anyone can add a state, orgs accumulate near-duplicates (“PT vereinbart” vs. “Probetraining vereinbart”). Use Status zusammenführen in the global editor to reconcile them: pick a source (dissolved) and a target (kept); every reference — leads, forms, automations — is repointed to the target and the source is deleted. The action is org-wide and cannot be undone.
Why categories exist
Section titled “Why categories exist”Analytics charts (conversion rate, time-to-close, funnel drop-off) only make sense if states roll up to comparable buckets. Two customers naming their states “Sign-up complete” vs. “Member” should both count as Won in cross-org reporting. The hidden category is what makes that possible.
A state’s name or color change is safe and propagates by ID, but a category change can shift analytics retroactively — audit it before recategorizing a state that already has history.
What’s next
Section titled “What’s next”- A single global set means setting a state in a multi-location automation no longer needs a separate node per pool.
- Set up phone & website formatting so emails render correctly.
- Move on to schema and fields once the lead state set looks right.