Join the LadVen OS testing programRequest a demo
Skip to main content

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.

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 and a description. 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.

What you configure in a pipeline​

Pipeline configuration is split into areas. Below is the management meaning of each one.

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).

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.

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.
note

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.