Setting up deals in Bitrix24 CRM

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages
Latest works
  • image_website-b2b-advance_0.png
    B2B ADVANCE company website development
    1173
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Website development for FIXPER company
    811
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    564
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    745
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    655
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    976

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