Statuses, groups and transitions: building the pipeline
How the pipeline works in X10 CRM: status groups, allowed transitions, system codes, automatic dates, SMS triggers and stock reservation driven by status.
The pipeline is the foundation of the whole system. Statuses drive reporting, automatic SMS, stock reservations, the dates in your analytics and even which leads an operator gets to see. Reworking a pipeline on a live database is painful, so it is worth thinking it through before launch.
#Groups and statuses
The structure has two levels. A group is a large stage of the pipeline; a status is a specific state inside it.
| Level | What you define | Example |
|---|---|---|
| Status group | Name, system code, colour and display order | “In progress”, orange |
| Status | Name, system code and the group it belongs to | “No answer 1”, “No answer 2”, “Thinking” — all inside “In progress” |
#System codes
Every group and status has a Latin-letter code. Most of them are arbitrary, but a few are recognised specially by the system — and that is exactly how the automations work.
Group codes that switch on automatic dates
acceptedgroupWhen a lead enters this group, the accepted date is stamped. Put statuses such as “Confirmed” here.
completedgroupStamps the completion date. This is the successful ending: paid for, collected, received.
returnsgroupStamps the return date. Refusals and returned parcels go here.
Status codes the system relies on
newstatusrequiredThe starting status. Leads that arrive from landing pages through the API and leads imported from a file get it. If no status carries this code, new leads are created without a status and may get lost in the filters.
duplicatestatusUsed by the Excel import to mark duplicates by phone number.
#Allowed transitions
Transitions describe which status a lead may move to from which. The logic is simple but counter-intuitive, so remember the main rule:
That means the pipeline can be tightened gradually: leave everything open at first, then close the transitions where abuse starts.
- Blocking jumps over stages: a lead cannot go from “New” straight to “Paid for”, skipping confirmation and shipping.
- Protecting the endings: only someone whose role allows it can pull a lead back from “Paid for” into work.
- Honest statistics: if leads cannot skip stages, the pipeline conversion shows the real picture.
#What a status change triggers
A status is an event. Here is what happens automatically when a lead enters one:
| Automation | How it is configured |
|---|---|
| SMS to the customer | One trigger per status with a message template. The classics: “Order accepted” and “Parcel shipped, waybill…” |
| Stock reservation | Lists of statuses in which goods are reserved, finally written off, or returned to stock |
| Lifecycle dates | Stamped by the group code — accepted, completed, returns |
| Operator number masking | Substituting the number on transitions between certain statuses |
| Transitions driven by tracking | Nova Poshta statuses move the lead themselves — see Nova Poshta in the CRM |
#A sample pipeline for physical goods
A working skeleton you can take as a starting point and trim to fit.
| Group | Code | Statuses inside |
|---|---|---|
| New | new_group | New, Repeat |
| In progress | in_work | No answer 1, No answer 2, Call back, Thinking |
| Confirmed | accepted | Confirmed, Prepayment received |
| Delivery | delivery | Waybill created, In transit, Arrived at branch |
| Completed | completed | Paid for |
| Returns | returns | Customer refused, Not collected, Returned |
#Changes on a live database
- Renaming a status is safe: the leads stay where they are, only the label changes.
- Deleting a status that still holds leads is not possible — the system hides it from the lists, but the history is preserved.
- Moving a status to another group has consequences: reporting and the automatic dates for future transitions will change.
- Changing a system code is the riskiest of all. Integrations, imports and automations rely on codes, so leave them alone unless you must.
#Pipeline checklist
- A status with the
newcode exists — checked first - Groups carry the
accepted,completedandreturnscodes for automatic dates - Groups are ordered the way a lead travels, and no two colours clash
- The number of statuses stays within a sensible limit
- Transitions are closed wherever abuse is possible
- SMS triggers are set on the key statuses
- Stock reservation and return statuses are specified
- Roles have their allowed-status lists