Custom Sales Pipelines in Jira: Working with Multiple Jira Sales Pipelines in Mria CRM
In Mria CRM, pipelines are an explicit CRM structure that defines how deals move through stages, how progress is reviewed, and how sales data is interpreted inside Jira.
Mria CRM supports both pipeline customization (stages, order, colors, probability) and multiple pipelines because a single, fixed pipeline stops being reliable once sales activity includes more than one sales motion.
This article explains how sales teams typically handle stages and pipelines in Jira when issues represent deals and statuses represent stages, what limitations appear over time, and how Mria CRM addresses those limitations with configurable and multiple pipelines. It also includes practical guidance on when and how to use these capabilities.
How Sales Pipelines Are Commonly Implemented in Jira Without a CRM Layer
In many Jira-based setups, sales deals are represented as issues and pipeline stages are mapped to Jira workflow statuses. This approach is simple to start with and fits naturally into Jira’s model.
Example of a Sales Pipeline Implemented with Jira Issues and Workflow Statuses
Over time, teams usually converge on one shared workflow that all deals must follow. Differences between deal types are handled indirectly through custom fields, labels, components, subtasks, or comments, while the workflow itself remains largely unchanged.
This works while sales activity is limited and relatively uniform. As soon as different deal types, deal sizes, or sales motions coexist, pressure builds on the workflow.
Where Jira Workflows Reach Their Limits for Sales Pipelines
When a Jira workflow is used as the sales pipeline, the limitations are structural rather than behavioral.
First, workflows are usually shared. Once different deal types require different paths, teams either force all deals through one status sequence or split sales into multiple projects or workflows. Both options reduce clarity and increase maintenance overhead.
Second, workflow changes are expensive. Adding, renaming, or reordering stages becomes a governance task rather than a sales-process adjustment. As a result, teams tend to freeze the workflow and encode real progress elsewhere. The visible pipeline stays simple, but the actual decision points move into fields, labels, checklists, or comments.
Third, reporting stops matching review logic. Jira can calculate time in status and transitions correctly, but those numbers only reflect the workflow, not the full sales process. Funnel views and cycle length are technically accurate but incomplete, because parts of the process live outside the stage model. Teams can still produce reports, but they require segmentation and explanation to be useful.
These limitations are not caused by poor discipline. They come from using one global workflow to represent sales processes that are no longer uniform.
How Sales Pipelines Are Defined in Mria CRM
Mria CRM separates sales pipelines from Jira workflows.
In Mria CRM, a pipeline is a dedicated CRM configuration that defines:
- which stages exist
- the order in which deals move through those stages
- the probability associated with each stage
Sales Pipeline Configuration in Mria CRM
Stage probability is defined at the pipeline level and reflects the likelihood of a deal being closed when it reaches that stage. Probabilities are configurable per pipeline and can differ between pipelines, even if stage names are similar.
This allows probability to be aligned with the actual behavior of a specific sales motion rather than applied uniformly across all deals.
Deal progression through pipeline stages is managed independently of Jira issue status. This allows sales structure to evolve without forcing changes to delivery or support workflows.
Every deal belongs to exactly one pipeline, and that pipeline defines the meaning of its stages.
Customizing Pipeline Stages in Mria CRM
Each pipeline in Mria CRM can be customized independently.
For every pipeline, teams can add stages, rename them using internal terminology, reorder stages as processes evolve, assign a color to each stage, and define a probability for each stage. All of these settings apply only to the selected pipeline and do not affect other pipelines.
Stage customization allows stage meaning to be explicit and operational. Instead of relying on shared assumptions or auxiliary fields, the pipeline defines both how progress is understood during reviews and how likely a deal is to close at each stage. Probability is therefore tied to the stage definition itself rather than calculated externally or inferred from historical data.
Sales Pipeline Configuration in Mria CRM: Adding a New Stage
Stage colors are used consistently across pipeline views, dashboards, and funnels. Their practical purpose is to reduce scan time and ambiguity during reviews, especially when multiple pipelines exist, while probability provides a consistent quantitative signal that can be interpreted in the same way wherever the pipeline is used.
Multiple Sales Pipelines in Mria CRM
Mria CRM allows teams to create and maintain multiple sales pipelines within the same Jira site.
Each pipeline has its own:
- stage list
- stage order
- stage colors
- stage probabilities
Pipelines in Mria CRM are fully independent. There is no shared global stage model unless teams intentionally align them.
Configuring Multiple Sales Pipelines in Mria CRM
Multiple pipelines are typically introduced when one pipeline no longer represents a single sales process and stage meaning starts to depend on deal context.
Typical Use Cases for Multiple Pipelines in Jira
-
New business and renewals
Renewals often involve steps such as usage review or contract extension and usually follow different timing than new deals. Separating them prevents late-stage value and cycle length from being distorted.
-
Transactional and enterprise deals
Enterprise deals introduce steps like security review, legal approval, or procurement that do not exist for smaller deals. A separate pipeline allows these steps to be represented explicitly instead of being hidden inside generic stages.
-
Direct and partner-led sales
Partner deals include coordination steps that change how progress should be evaluated. A dedicated pipeline makes those steps visible without affecting direct sales reviews.
In all cases, the need for multiple pipelines arises from differences in decision points, not from preference.
How Multiple Pipelines Affect Data Interpretation by Pipeline
When pipelines are separated, reviews are typically performed per pipeline rather than across all deals.
Viewing Deals by Pipeline in Mria CRM
This keeps stage meaning consistent within a review context and reduces the need for clarification. Stage distribution and pipeline value describe one coherent process instead of an average across incompatible flows.
Dashboard with funnels in Mria CRM support filtering by pipeline, which prevents different sales motions from being merged into a single view and restores interpretability of metrics.
Dashboard Filtered by Sales Pipeline in Mria CRM
Practical Guidance on Introducing Custom Pipelines in Mria CRM
- Create a new pipeline only when the process is different, not when ownership is different.
A separate pipeline is justified when deals follow a different stage sequence, require different approval steps, or have materially different close probabilities. If deals differ only by owner, region, or team, a single pipeline is usually sufficient. - Define stages as review checkpoints, not internal activities.
A stage should answer “what is true about this deal now” rather than “what someone is doing”. If a stage cannot be verified during a review without additional explanation, it will be used inconsistently. - Set stage granularity to match how often deals are realistically updated.
If your team updates deals weekly, stages should represent weekly progress. Stages that require frequent movement tend to become stale in Jira-based sales workflows. - Use stage probability to reflect commitment, not optimism.
Probability should increase only when something irreversible has happened, such as stakeholder alignment, commercial approval, or contractual agreement. Probabilities should be set per pipeline, even when stage names look similar. - Keep consistency only where it preserves meaning.
Closed stages and their probabilities should be consistent across pipelines. Intermediate stages should not be forced to match if the underlying process differs.
The goal is not to model every step of the sales process, but to keep stage meaning stable enough that pipeline views, funnels, and reporting can be interpreted without additional explanation.
Final Words
Custom stage configuration and multiple pipeline support in Mria CRM exist to replace implicit conventions with explicit structure. Instead of forcing different sales motions into one Jira workflow or encoding differences in fields and comments, teams define how deals progress directly in the pipeline.
This keeps reviews consistent, metrics interpretable, and historical data usable as sales activity grows and diversifies inside Jira.
You can try custom pipelines in Mria CRM by installing the app from the Atlassian Marketplace:
https://marketplace.atlassian.com/apps/4108768729/mria-crm-crm-for-jira-teams
Was this helpful?
Thanks!
Anton Storozhuk _Mria Labs_
3 comments