Configuring Deals in Bitrix24 CRM
A deal in Bitrix24 is the central CRM entity for managing sales. But out of the box, the deal pipeline is set up for an abstract "universal" process that does not fit any specific business. Configuring deals to match the real sales cycle is not customization for its own sake — it is a prerequisite for accurate analytics and correct automation behavior.
Pipelines and Deal Stages
Bitrix24 supports multiple deal pipelines (directions) — each with its own set of stages. This allows you to separate B2B and B2C sales, different product lines, or different regions.
Configuration: CRM → Deals → "⚙" button next to the pipeline → "Configure pipeline".
Stages. Each stage has:
- A name (visible to the manager).
- A system identifier (
STAGE_ID) — used in robots and the API. - A type: Successful, Failed, Regular.
- Closing probability (0–100%) — affects revenue forecasting.
- A color — for visual separation on the Kanban board.
The successful stage (e.g., "Closed. Paid") and failed stages (e.g., "Declined", "No answer") are terminal. A deal in these stages cannot move forward.
Common mistake: too many stages. 15 stages instead of 5–7 — managers cannot tell the difference between them, stop updating, and analytics loses meaning. Optimal: 5–8 stages, each with a clear transition criterion.
Custom Deal Fields
CRM → Settings → Custom Fields → Deals → "Add field".
Field types:
- String, number, date, list (reference), checkbox, link.
- Binding to an employee, to another CRM entity.
- File.
Custom fields receive a system name of UF_CRM_*_XXXXX. They are available in robots as variables, in report filters, and in the API.
Important: do not create fields "just in case". Every unfilled required field creates friction for the manager. Five to seven well-thought-out fields are better than thirty half-empty ones.
Required Fields and Validation
In the deal card settings (CRM → Settings → Deal card) you define:
- Which fields are required.
- Under what condition (always / on stage change / on close).
"Required on stage change" mode — the manager cannot move the deal to the next stage without filling in the necessary fields. This guarantees data quality.
The setting is separate for each stage: on the "Proposal sent" stage the "Proposal amount" field is required, on the "Negotiations" stage — the "Meeting date" field.
Robots and Triggers on Deals
Automation is configured via CRM → Deals → Robots (the "Robots" icon in the relevant pipeline).
Robots are tied to stages: when a deal reaches stage X, action Y is executed.
Typical robots:
- Task for the responsible person — create a task for the manager on stage transition.
- Notification — to the manager's or supervisor's chat.
- Change responsible — automatically under a condition.
- Launch business process — for complex logic.
- Send email/SMS — to the client when the deal transitions to a specific stage.
- Change fields — automatically set the source, tag, custom field.
Triggers — reverse logic: event → stage change. For example: the client opened an email → the deal moves to the "Showed interest" stage. Or: the client paid an invoice → stage "Paid".
Deal Relationships with Other Entities
A deal in Bitrix24 is linked to:
- A contact (individual) — field
CONTACT_ID. - A company — field
COMPANY_ID. - A lead — if the deal was converted from a lead.
- Other deals — via custom fields of type "CRM binding".
The deal card shows the full activity history: calls, emails, meetings, chats from open lines — all from b_crm_activity filtered by OWNER_ID.
Deal Access Rights
Configuration: CRM → Settings → Access Rights → Deals.
Basic matrix: role → operation (view / create / edit / delete) → scope (own / department / all).
Typical configuration for a sales department:
- Manager sees only their own deals.
- Department head — deals of the entire department.
- Commercial director — all company deals.
Without access rights configured — all managers can see each other's deals, creating privacy issues and client "poaching".
| Setting | Key decision |
|---|---|
| Pipelines | One per sales type, not per manager |
| Stages | 5–8 maximum, clear transition criteria |
| Required fields | Bind to stages, not to all at once |
| Robots | At least one action per stage |
| Access rights | Manager sees only their own |







