How EspoCRM multiple pipelines separate sales processes
Many organizations sell several products, serve different customer types or run partner deals alongside direct sales, and each of those motions moves through its own stages. Pipelines in EspoCRM 10 let one instance hold those processes side by side, so a team selling a subscription does not have to share a sales path with a team running implementation projects. The feature configures multiple pipelines for leads and opportunities, and for custom Base, Base Plus, Company and Person entity types. Each record's pipeline determines which stages it can move through, so the stage list a rep sees is the one that fits the deal in front of them.
Custom entity types need a Status enum field before they can take part in pipelines, so the stage design has to be settled in the Entity Manager before pipelines are configured. Teams should decide which record types carry a pipeline, which stages each pipeline needs, and who is allowed to create or move records in each one. A single pipeline is usually enough when one team sells one product through one sequence of stages and reports on a single funnel. Separate pipelines earn their place when stages, exit criteria or reporting differ materially between teams, which is a question to settle with sales leadership before build starts. Confirm the exact setup steps and stage behavior for your version against the pipelines documentation.
Pipeline design also affects reporting and access, because stage-based views and reports only stay meaningful if each pipeline's stages are named and used consistently. Before rollout, check which roles can see records from other teams' pipelines and whether the stage lists in each pipeline match how the team actually works. Changing stages after records exist is easier to plan than to undo, so a short pilot with real records is a sensible check before the full team moves over.
Which entity types support pipelines and what each needs
Leads are the entity type most teams start with, because they hold prospects before a sales decision is made. In EspoCRM 10, pipelines can be enabled for leads, so each lead is assigned to a pipeline and moves through the stages that pipeline defines. This lets a team run, for example, an inbound web enquiry process alongside a partner referral process without forcing both through one set of statuses.
- Pipeline enablement: Turn pipelines on for the Lead entity in the administration area, then confirm the option is visible in your instance before designing stages.
- Stage source: Stages come from the status field already used on leads, so review existing lead status values before you split them across pipelines.
- Assignment: Each lead carries one pipeline at a time, so decide who sets it, such as the capture form, a workflow or the sales owner.
- Existing records: Leads created before enablement need a pipeline assigned, so plan how you will set it for historical data.
- Reporting: Confirm that lead reports and filters group by pipeline before you rely on them for conversion figures.
Confirm in your own environment which lead fields and layouts your version exposes for pipeline selection before you approve the design.
Opportunities represent deals in progress, and they are where most teams want different sales processes side by side, such as new business, renewals and expansions. Pipelines on opportunities let each deal follow the stages that match its type. Because the stages belong to the pipeline, changing a deal's pipeline changes which stages it can take, so the move should be a deliberate step in your process.
- Deal types: Map each sales motion to one pipeline, and keep the number of pipelines small enough that owners can recognize their stages.
- Stage definitions: Write exit criteria for every stage so the same stage name means the same thing in each pipeline.
- Pipeline changes: Decide whether reps may move a record between pipelines, and who approves it when they do.
- Forecasting: Check how amounts and probabilities behave when a record changes pipeline, since stage-based reports depend on it.
- Permissions: Confirm which roles can edit pipeline and stage fields, because stage changes often trigger notifications or workflows.
Confirm with your vendor or in a test instance how stage changes interact with your forecast and reporting settings before you migrate live deals.
Custom entity types built on the Base and Base Plus templates can also support pipelines, but they need a Status enum field before the pipeline can define stages. Without that field, the pipeline has nothing to attach stages to. The Status field is an ordinary enum, so its options become the stages, and its layout placement determines where users see the current stage.
- Status enum: Create an enum field named for the stage set you need, and add the options in the order users should read them.
- Field type: The field must be an enum, not a varchar or free text, so the stage list stays controlled.
- Entity Manager: Add the field through the Entity Manager on the custom entity, then confirm it appears in the layouts.
- Base versus Base Plus: Confirm which template your entity uses, because the set of default fields differs and affects the design.
- Naming: Use stable option values, since renaming a label later is easier than changing stored values that reports depend on.
Confirm in your environment that the custom entity exposes the pipeline setting once the Status field exists, and test with a sample record before building further.
Custom types built on the Company and Person templates follow the same rule: they need a Status enum field before pipelines can attach stages. These templates usually represent organizations or individuals that move through relationship or account processes, such as onboarding, partnership status or client lifecycle. Because the templates bring their own default fields, check for overlap before adding a Status field, so you do not duplicate a status concept the entity already has.
- Existing status concepts: Look for fields that already track lifecycle state, and decide whether the pipeline replaces them or runs beside them.
- Stage naming: Use names that match the business process, since partners and clients often see these stages in portals or reports.
- Duplicate matching: If records are imported, plan the Status values in the import file so records land in the correct stage.
- Layouts: Place the Status field where users update it, and check it on detail and list views.
- Access: Review roles for these entities, since stage changes may expose or hide records through related workflows.
Confirm exactly which custom types and templates appear in your edition and version, then document the Status field for each one you plan to use.
Pipeline configuration options and when each fits
This table compares the main ways to lay out pipelines for leads, opportunities and custom entity types in EspoCRM 10. Read each row against how your sales and service teams hand work between stages. The main takeaway is that the stage model and the record assignment rules matter more than the number of pipelines you start with.
| Option | What it involves | Fits when | Trade-off to confirm |
|---|---|---|---|
| One shared pipeline | Leads and opportunities use the same stage list, so reporting and stage names stay uniform across records. | Sales runs one motion with a common set of stages and reporting needs one view. | Stage names may fit one motion poorly, and a stage that suits leads can mislead for opportunities. |
| Separate pipelines per entity type | Leads and opportunities each get their own pipeline with stages that match their work. | Qualification and deal closing follow clearly different steps and owners. | Each pipeline needs its own stage maintenance, and cross-entity reports need a deliberate design. |
| Several pipelines on one entity type | One entity type holds more than one pipeline, each with its own stages for a distinct sales process. | Partner, direct or renewal sales follow different stage sequences on the same record type. | Users must pick the correct pipeline, so layouts and default assignment rules need testing. |
| Status field per custom type | A custom entity type with a Status enum field defines its stages, and pipelines use that field. | You add a custom Base, Base Plus, Company or Person type that needs its own stage flow. | The Status enum must exist before pipelines work for that type, so confirm the entity type setup first. |
| Assigning a pipeline to new records | New records receive the pipeline by default or by user choice when created. | Teams want consistent routing from the first save, such as web leads entering a qualification pipeline. | Confirm the default and whether layouts show the pipeline field for users who create records. |
| Assigning a pipeline to existing records | Records created before the change are moved or left on their current stage model. | You are adding pipelines to a system that already holds active leads or opportunities. | Mapping old status values to new stages is manual work. Test with a copy of the data before changing live records. |
| Stage changes and reporting | Stages drive list views, filters and reports for each pipeline. | Managers need pipeline-level counts and conversion views. | Reports built on status values may need review after a pipeline change. Confirm with your reporting requirements. |
How to set up pipelines in EspoCRM 10
This sequence takes a running EspoCRM 10 instance from a confirmed version and entity list to tested, separate pipelines for leads, opportunities and any custom entities, with each record landing in the right stages. It ends with a sample-record test that shows each team sees the process it actually runs.
Confirm version and entity types
Start by checking the EspoCRM version in the administration area and listing every entity type that needs its own sales process, such as leads, opportunities and any custom entity. Confirm which custom entities use one of the supported entity types for pipelines (Base, Base Plus, Company or Person), because that determines whether they can take a pipeline at all. The step is done when you have a written list of entities, their types and the owning team for each. Ask the business owner to sign off the list before any configuration starts.
Define stages in status fields
For each process, define the stages as options in a status enum field, keeping the order the team actually moves records through. Custom entity types need a Status enum field before pipelines can be enabled, so create or confirm that field in the Entity Manager first. Check that each stage name is unique within its field and that terminal outcomes such as won, lost or disqualified are included. The step is complete when every process has a field whose options match the agreed stage list.
Enable pipelines for each entity type
In the Entity Manager, turn on the Pipelines feature for each entity type that needs it, then confirm the feature is active for leads, opportunities and any custom entity you listed. Keep the field and entity names consistent so that later mapping is straightforward. Verify by opening the entity's settings and checking that the pipeline option is saved and visible. If an entity does not offer the option, recheck its type against the list from step one before going further.
Configure stages for each pipeline
Create one pipeline per process and attach the status values that belong to it, so each record's pipeline determines the stages it can move through. Set the initial stage for new records and make sure terminal stages are placed where the team expects them. Where two processes share a status field, confirm that each pipeline only exposes the options it should. The check is that a test record in each pipeline shows only its own stages in the status control.
Assign records and layouts to pipelines
Assign each record to its pipeline, either by setting the pipeline field on new records or by mass updating existing ones after you have mapped them. Adjust layouts so the status field and the pipeline field appear in the places sellers and service staff work, and hide fields that belong to another process. Confirm with a user from each team that their list views and detail views show the expected pipeline. The step is done when the layout review is signed off by one user per team.
Test with sample records
Create sample records in each pipeline and move them through every stage, including the terminal outcomes, to confirm that transitions behave as the team expects. Use test users with the same roles and teams as real users so that permission gaps appear before go-live. Record the results in a short checklist that names the pipeline, the stage moves tested and any issues found. The sequence is finished when the checklist shows no open issues and the sample records are removed or clearly marked as test data.
Designing stages that different teams can share
Decide which stages belong to each pipeline before you create any, because a stage that exists in one pipeline is not automatically available in another. Start from the status values each team actually uses to judge progress, then group them into pipelines that match real sales motions, such as a partner-sourced deal and a direct enterprise sale. Shared stage names such as "Qualified" or "Closed Lost" look convenient, but they only stay comparable if the meaning behind them is identical across teams. Write a one-line definition for every stage and agree on the exit criteria with the sales leads who will be measured against them. For custom entity types, remember that each one needs a Status enum field, so plan that field's options as part of the same design exercise.
Overlapping stage names affect reporting more than most teams expect. Reports and dashboards aggregate on the underlying status value, so two pipelines that both use a stage called "Proposal" can produce a combined figure that hides very different conversion rates. Confirm with your reporting owner whether stage values should be unique per pipeline, shared across pipelines, or mapped to a common reporting label, and test that choice on a sample of records before rollout. Layouts, field-level permissions and team access also depend on stage, so a stage that makes a field read-only in one pipeline must be checked in every layout that displays it. Confirm in your own test environment how a record that changes pipeline keeps or loses its status.
Formula Script, before-save scripts, workflows and BPM logic may compare against literal status values. Renaming, removing or reordering a stage can therefore break automation silently, and the failure may only show up as a record that never advances or a notification that never fires. Treat every stage change as a change to code: list each script and workflow that reads the status field, review it against the new stage set, and test it with records in each pipeline. Keep a change log of stage definitions so that reports, automation and the people who run them can be reconciled after each update.
Common mistakes when running multiple pipelines
Multiple pipelines work only when every record, stage and report agrees on which sales process it belongs to. The mistakes below share one root cause: pipeline assignment and stage definitions are treated as cosmetic setup rather than as the data model that drives forecasting, ownership and automation. Each card names the symptom to watch for and the check that catches it before users do.
Custom types missing a Status field
Pipelines for custom entity types need a Status enum field, because stages are read from it. A custom entity created without one will not offer a stage at all, so its records cannot move through a pipeline. Before enabling pipelines for a custom type, open the Entity Manager, confirm the Status field exists with the stage values you expect, and create one test record to see the stage control appear on the detail view. Check this for each custom Base, Base Plus, Company or Person type you add.
Inconsistent stage names across pipelines
When the Lead and Opportunity pipelines use similar but different labels, such as *Qualified* in one and *Qualification* in another, every filter, dashboard and report must account for both spellings. Reports then split one real-world stage into two rows and totals quietly understate progress. Compare the option lists of each Status field side by side before go-live, and agree a shared stage vocabulary with sales leadership. Adjust labels only after you confirm which saved filters and reports reference them.
Records left without a pipeline
A record whose pipeline is empty or unset has no defined set of stages, so it appears in lists but cannot advance in a controlled way. This usually happens with records created by API calls, imports, web-to-lead capture or mass updates that skip the pipeline value. Run a list filter for records with no pipeline value after each import or integration test, and make the pipeline field required in layouts for the records that need it. Include this check in every migration rehearsal.
Unclear ownership of stage changes
If nobody has defined who may move a record between stages, stage data drifts. Sales users may skip qualification steps, while managers may change stages to match their forecasts. Decide which roles may edit the Status field through role permissions, and document the entry and exit criteria for each stage. Then review the audit history of a sample of opportunities each month to see whether stage changes match those criteria. Any automation that changes stages should be listed alongside manual changes so the owner is clear.
Reports that mix pipelines
A single report or dashboard that counts opportunities across all pipelines will sum stages that mean different things. A stage called *Proposal* in a renewal process and in a new-business process is not the same measure, so combined conversion rates are misleading. Build each pipeline's reports with a pipeline filter, and check that the total of the per-pipeline figures equals the unfiltered total. Confirm report definitions with the people who consume them before you publish them.
Questions buyers ask about EspoCRM pipelines
What drives the cost of an EspoCRM pipeline setup?
The cost depends on how many sales processes you run, how many stages each one has, and how many record types need a pipeline. Configuring a pipeline for leads or opportunities is a small piece of work on its own. The larger cost comes from deciding the stages, agreeing the exit criteria for each stage, and adjusting layouts, permissions and reports so each team sees the right fields at the right point. Custom entity types add effort because each needs a Status enum field before it can take a pipeline. Recurring costs are mainly hosting and user licenses. If you use the hosted service, the EspoCRM pricing page lists 15 US dollars per user per month on the Basic plan (minimum 3 users), with the Advanced Pack included in all cloud plans. Self-hosting the open-source edition carries no license fee, but you pay for servers and operations.
How long does a multiple pipeline setup take?
Duration depends on scope, not on the feature switch itself. Enabling pipelines for leads and opportunities in an existing instance is quick to configure, but the time goes into the sales process design that comes before it. A single team with one pipeline per entity usually needs a short design cycle and a test pass. Several teams with different stages, custom entity types, role changes and reporting needs take longer because each stage decision affects layouts, filters and who can move a record forward. A written scope should list the number of pipelines, the record types covered, the number of layouts to change and the test cases you expect. Ask for the timeline against that list, not against a generic estimate.
What does the work need from our sales and operations team?
The work needs decisions from people who run the sales process. Before configuration starts, your team should agree the stages for each pipeline, the status values that mean a stage is complete, and who may move a record between stages. Operations should confirm which fields are required at each stage and which reports managers need. Someone must also review test records in a non-production copy, because stage changes are easy to configure and hard to explain to users later. Plan for this time in your own calendar. A partner can document the design and configure the instance, but the business rules have to come from your staff.
Can our internal staff set up EspoCRM pipelines without a partner?
Yes, for a simple setup, an administrator who knows EspoCRM can enable pipelines for leads and opportunities and define stages through the status fields. The risk grows with complexity. Custom entity types need a Status enum field, and stage changes affect layouts, permissions, workflows and reports that may already exist. Mistakes often appear only when a user tries to move a record and finds the wrong options or missing fields. Internal teams should test in a copy of the instance, keep a written record of every stage definition, and confirm that the administrator has the time to maintain the setup after go-live. A partner is most useful when the design touches several teams or when internal staff cannot test changes safely.
How do pipelines affect migration of existing records?
Existing leads and opportunities carry status values from your old system, and those values rarely match the stages you design for EspoCRM. Before importing, map each legacy status to a target stage, decide what happens to records with no clear match, and confirm which pipeline each imported record should join. EspoCRM's CSV import supports Create Only, Create and Update, and Update Only modes, field mapping and duplicate matching on chosen fields. Large files can run through cron so the import does not block the interface. Test the import on a sample, check that stage values are valid, and keep a way to revert imported records if the mapping is wrong. Ask the partner how the status mapping will be validated before the full load.
What should we ask a partner to include in a written quote?
Ask for a quote that lists each pipeline, the record types it covers, the stages and exit criteria you agreed, and the layouts, roles, reports and workflows that change. Ask which items are one-time work, such as design, configuration and migration, and which recur, such as hosting, support and upgrades. Request the test plan, the acceptance criteria and the handover documentation. Confirm which environment the work runs in and who holds administrator access afterward. Ask how changes after sign-off are priced and how an EspoCRM upgrade is planned. DeployOpen works from a written scope, and a quote follows from that scope, so the more precise your list of pipelines and record types, the more accurate the quote will be.
How DeployOpen scopes and delivers pipeline setups
DeployOpen plans, builds, documents and supports EspoCRM inside infrastructure you control. For multiple pipelines, we start from how your teams sell, agree the stages and record types in writing, and then configure and test them before anything reaches production users.
How we scope
- Map each sales process to a pipeline, listing the lead and opportunity stages each one needs
- Identify which custom entity types need a Status enum field before they can use pipelines
- Confirm which teams and roles may assign records to each pipeline and who may change stages
- Agree the scope in writing as a fixed-scope engagement, with deliverables and timelines set before work starts
How we build
- Configure pipelines for leads, opportunities and any agreed custom entity types in a non-production instance
- Set stage order and status values so that layouts and filters show only the stages relevant to each pipeline
- Test pipeline assignment on sample records, including records moved between pipelines and records created by integrations
- Review changes with your administrators before they are promoted to the production instance
How we hand over
- Document the pipeline model, stage definitions, field dependencies and the permissions that control assignment
- Provide a checklist for administrators who add a new pipeline or stage later
- Walk through the configuration with your CRM administrators and record the decisions behind each pipeline
- Deliver the configuration in a form your team can review, change and keep under its own version control
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Review pipeline changes when EspoCRM versions change, including the 10.x line your instance runs
- Confirm with your team how pipeline changes interact with automation, reports and integrations before they go live
- Ask for a written quote based on the agreed scope, which sets out one-time work and any recurring retainer separately
