Designing Multi-Pipeline CRM Architecture in Bitrix24

Designing Multi-Pipeline CRM Architecture in Bitrix24

One funnel for all sales types is a compromise that only works while the company is small. As soon as fundamentally different processes emerge — wholesale shipments and retail orders, project-based sales and service contracts, direct clients and partner channels — a single funnel becomes a dumping ground: stages don't fit half the deals, analytics loses meaning, and managers work "however they see fit."

Multi-pipelines in Bitrix24 are an architectural decision, not just "another tab."

Multi-Pipeline Architecture

In Bitrix24, multi-pipelines are implemented through the pipelines mechanism (crm_category). Each pipeline is a spatially isolated set of stages. Technically:

• Pipelines are stored in the b_crm_category table
• Each pipeline's stages are in b_crm_status with ENTITY_ID = DEAL_STAGE_{categoryId}
• A deal belongs to a specific pipeline via the CATEGORY_ID field in b_crm_deal

Important platform limitations:

• Moving a deal from one pipeline to another is only possible via the API (crm.deal.update with a CATEGORY_ID change) or a dedicated interface — ordinary drag-and-drop does not work.
• Custom fields are created for the entire "Deal" entity, not for a specific pipeline. Hiding a field for one pipeline only is not possible through the standard interface — only through role-based card configuration.
• Automation (robots) is configured separately for each pipeline.

When Multi-Pipelines Are Needed

Multi-pipelines are justified when:

1. Different manager teams work with different client types — each team needs its own analytics.
2. Different sales cycles — short-term deals (1–3 days) and long-term projects (3–12 months) should not be mixed in one report.
3. Different sets of required fields — one deal type needs legal details and a contract, another only a name and amount.
4. Different lead sources with incompatible qualification logic.

Multi-pipelines are not needed if the difference between deal types is covered by a custom "Type" field and minor stage variations.

Design: From Business Processes to Architecture

Step 1. Inventory of sales types. Together with management, record all deal types in the company. For each type: who manages it, what is the cycle, how it fundamentally differs from others.

Step 2. Criteria for separation. Not every difference warrants a separate funnel. Ask: if these deal types were mixed in one funnel, what exactly would break? If the answer is only visual inconvenience, a filter field is enough. If the answer is that the stages and automation are fundamentally different — a separate funnel is needed.

Step 3. Architecture for cross-pipeline transitions. Business processes often involve a deal moving from one pipeline to another: qualified lead → standard deal → service contract after closure. This must be designed explicitly: via automation (crm.deal.add in another pipeline upon closing the current deal) or via a manual transfer with a documented process.

Step 4. Shared and specific fields. Build a matrix: which fields are needed in all pipelines, which only in specific ones. "Universal" fields are created once. Pipeline-specific fields are created and hidden in others via role-based configurations.

Step 5. Separate automation. Robots and triggers are configured per pipeline separately. This allows different notification and task scenarios for different funnels — and that is precisely the architectural rationale for the separation.

Case Study: Three Pipelines for a Distribution Company

Client — a wholesale distributor of household chemicals. Three sales channels: retail chains (supply contracts), HoReCa (hotels, restaurants), online retailers (aggregators).

Initial situation: one "Deals" funnel with 6 stages. The manager could not understand why conversion was "normal" but revenue was not growing: contracts with retail chains (long cycle, large ticket) were mixed with fast HoReCa deals (3–7 day cycle, average ticket 10 times smaller).

"Retail Chains" pipeline (8 stages, cycle 30–90 days): Negotiations → Matrix approved → Commercial terms → Contract under review → Contract signed → First delivery → Regular deliveries → Termination

"HoReCa" pipeline (5 stages, cycle 3–14 days): Inquiry → Proposal sent → Trial delivery → Regular order → Client lost

"Marketplaces" pipeline (6 stages): Inquiry → Questionnaire completed → Documents submitted → Listing created → First orders → Active partner

For the "Retail Chains" pipeline, an automatic task "Approve pricing with the commercial director" was configured at the "Commercial terms" stage. For "HoReCa" — a reminder to the manager 2 days after sending the proposal without a response.

After implementation the manager saw, for the first time, separate conversion rates by channel: retail chains — 18% from negotiations to contract, HoReCa — 42%. It became clear where to direct efforts.

Common Design Mistakes

Too many pipelines. More than 6–8 pipelines are already difficult to manage. If there are many pipelines, some should be considered as smart processes instead.

Pipelines without owners. Each pipeline must have a responsible manager who monitors the relevance of stages and automation.

Forgot about reporting. Standard Bitrix24 reports can aggregate data across multiple pipelines, but non-standard breakdowns will require custom reports via crm.deal.list or BI tools.

Timeline

Designing a multi-pipeline architecture (2–3 pipelines) — 8–15 business days: interviews, architecture diagram, sign-off, implementation of each pipeline, automation, testing, and team training.