Pipelines and stages
A pipeline describes how you work a customer through the process: from an incoming interest to an outcome. It defines which fields are filled in on a deal, which stages the work moves through, who has access, and which automated rules apply. A well-built pipeline makes the process clear; a poorly built one turns the CRM into an arbitrary list.
Pipelines are managed in the Pipelines section (/crm/pipelines). Configuring a pipeline is the job of the process admin or the department lead, not a manager's day-to-day action.
The catalog is available at /crm/pipelines, and a specific pipeline can be opened at /crm/pipelines/:pipelineId. The content and actions depend on your permissions.
When you need a separate pipeline
Create a separate pipeline when the processes genuinely differ in the order of work, the stages, or the fields: a sale, a service request, a legal case, recruiting, partner work. If two processes go through the same stages and fill in the same fields, they do not need different pipelines.
Do not multiply pipelines for every special case: the more there are, the harder it is to keep the process unified and to compare results.
Pipeline list
The list shows each pipeline's name, description, state (active or archived), and creation date, along with the entry point into its configuration. Search and a filter by state are available.
Creating a new pipeline requires a name; the description is optional. If your role does not have the right to create one, the button is disabled and shows the reason - pipeline configuration is done by someone who has the right to do it.
When creating a pipeline, choose a stage preset: Sales (the default), Service, or No stages. The form previews the stages before you save; No stages means you add them manually. Presets also define terminal outcomes: Won/Lost for Sales and Resolved/Rejected for Service. The preview is the set of stages that will be created.
What you configure in a pipeline
Pipeline configuration is split into areas. Below is the management meaning of each one.
Pipeline purpose. The first settings view defines what happens to an inquiry after the work is agreed. Choose one mutually exclusive branch: keep the inquiry in CRM, move it to an order, move it to an agreement, or accept service requests. The service branch also requires a request kind and links the inquiry to the client's paid entitlement. Without write permission, the choices are read-only and cannot be saved. Orders, agreements, fulfillment and acceptance belong in Operations, not in the CRM opportunity register.
Fields and groups
Here you define which data is filled in on a deal. Fields are combined into groups (data-entry stages, meaningful blocks) that you can add, rename, hide, delete, and reorder.
A field has a type (text, number, date, list of values, employee, link), a name, a hint, a required flag, and a sensitivity level: public, internal, PII, or secret. The sensitivity level matters for privacy: fields with personal data and secrets must not appear in public screenshots and are not accessible to everyone.
System fields cannot be deleted - they are the basic frame of a deal. Some fields can be shown on external forms and in the client portal; decide this deliberately so that nothing unnecessary leaks outside.
A minimal set of required fields is the mark of a good pipeline. If creating a deal requires filling in a dozen fields, managers will start entering token values, and the data will lose its meaning.
Stages and their meaning
Stages define the flow of work. Each stage has not only a name but also a role:
- a working stage - active work is in progress;
- a waiting stage - work is paused while waiting for an event;
- a closing stage - the outcome is recorded.
For closing stages you configure the outcome (Won or Lost), a mandatory close reason may be required, and the stage itself can be made read-only once entered - so that a closed deal is not changed after the fact. In addition, a stage has a due-date control mode (normal, pause, stop).
Before archiving a stage, the portal checks its deal count. An empty stage is archived without an extra confirmation. If deals are found, or the count is unknown because the check failed, a warning explains that deals are not deleted: they remain in the pipeline but disappear from the board; move them first if they should stay visible. Cancel leaves the stage unchanged, and restoring an archived stage does not ask for this confirmation. A failed count check is not evidence that the stage is empty.
A good set of stages is short and clear: if the team does not understand what a stage means, it will move deals around at random.
Access
Here you define who can see the pipeline and what they can do. Permissions are set for employees and managers by levels: inherit, read, write, manage, or no access; you can set additional rules and permissions for individual stages. Changing permissions requires stating a reason - this is so that access changes have a history.
The external access model (client portal) and contact visibility are configured separately: either all of a company's contacts or only the assigned ones.
Assignment
Assignment rules answer the question of who becomes the owner of a new deal. A rule has a scope (stage), a priority, and a strategy: round-robin or a fixed list of employees. This helps avoid losing incoming deals and distributes the workload fairly.
The assignment tab supports a more precise scope than a stage alone: a rule can be limited to all channels, the chat widget, or telephony, and to a workspace, pipeline, and stage. Each rule has an enabled flag and a priority; when rules overlap, the higher-priority rules are evaluated first. Targets can be individual employees, departments, workgroups/projects, or workspaces. The strategy is either round-robin or a fixed list.
For a telephony scope, also choose the stage for a new call, the availability requirement (all, online only, or available only), and whether to keep the answering employee. The pipeline telephony policy separately controls ring timeout, routing mode (sequential, parallel, or balanced), hold music, the voice robot, and the missed-call reply queue. These settings do not turn a CRM rule into a universal SIP transfer; check the telephony provider's limits.
Automation
A pipeline and its stages can have automation rules: what happens when a deal is created, when a stage is entered, or when a field is changed. Automation is described in more detail in a separate scenario; here it is important to remember that every rule should have a clear meaning and an owner.
Field sensitivity and data privacy
A field's sensitivity level is not a formality - it protects client data. It determines who sees the value and where it may end up.
- Public - working data of the process, visible to participants with access to the pipeline.
- Internal - for internal work; not meant to be shown to the client or on external forms.
- PII - names, phone numbers, emails, and people's details; access is restricted, and on the deal card such a field may be shown as "Hidden by access policy" to anyone without access.
- Secret - especially sensitive data; shown only to those who are genuinely entitled to it.
Practical rules:
- mark PII and secrets with the correct level right when you create the field, not later;
- do not expose PII and secret fields on external forms and in the client portal without a clear need;
- remember that exports (for example, a contact export) must not contain data that cannot be shared outside;
- if a field is shown as "Hidden by access policy", that is an expected access restriction, not an error.
A correctly assigned sensitivity lets you run the full client process without creating a risk of leaking personal data.
States you may see
- configuration or permissions are loading;
- the tab has no permission to view or change it;
- changes are being saved;
- there are no stages or rules yet;
- a confirmation is requested before deleting or archiving;
- changing access requires stating a reason.
The pipeline configuration screen is not yet localized for all interface languages: in some languages it is shown in English. This is a known product limitation. It does not affect the content of this article, but localized screenshots of pipeline configuration are not published until it is fixed.
Good practices
- Create a pipeline for a genuinely different process, not for a special case.
- Keep required fields to a minimum; require a field only where the deal cannot proceed without it.
- Make stages short and clear in their names.
- Tag personal and secret fields with the correct sensitivity level.
- For closing stages, configure the outcome and the close reason.
- Assign an owner for the pipeline and for the assignment and automation rules.
- When changing access, state a clear reason.
Common mistakes
Multiplying pipelines for every case. The process stops being unified, and results become impossible to compare.
Making too many fields required. Managers enter token values, and the data loses its value.
Creating unclear stages. Deals move around at random, and the board stops reflecting reality.
Exposing unnecessary fields outside. Something that should not be visible ends up on an external form or in the client portal.
Changing access without a reason or an owner. The history of permission changes is lost, and it becomes impossible to make sense of the permissions later.
How to check the result
- the set of fields is minimal and a field is required only where needed;
- stages are short, and each one's role and meaning are clear;
- closing stages have the outcome and close reason configured;
- personal and secret fields are tagged correctly and do not leak outside without necessity;
- permissions on the pipeline and stages match the roles, and the assignment and automation rules have an owner.
Business scenarios
- Sales pipeline with tasks and documents
- Sales team task management
- The business grew — and control slipped away
- All scenarios
Related sections