Designing the CRM Entity Structure in Bitrix24

Designing the CRM Entity Structure in Bitrix24

One of the most frequent questions during a Bitrix24 implementation: "Why do we need leads if there are deals?" Or the reverse: "Let's just save everything as contacts — why overcomplicate things?" The wrong answer at the start of a project results in a CRM full of duplicates six months later, managers who don't know where to find a client's history, and reports that don't work as expected.

Designing the CRM entity structure is an architectural decision that sets all subsequent rules for working with the system.

Entity Map of Bitrix24 CRM

Bitrix24 provides the following set of built-in entities:

• Lead (crm_lead, table b_crm_lead) — an unqualified interest, a potential client before their value has been verified.
• Contact (crm_contact, b_crm_contact) — an individual person with whom communication is conducted.
• Company (crm_company, b_crm_company) — a legal entity or organization.
• Deal (crm_deal, b_crm_deal) — a specific sale or project with an amount and a funnel.
• Invoice (crm_invoice) — a commercial document linked to a deal or contact.
• Quote (crm_quote) — a commercial proposal prior to invoice issuance.
• Smart Processes (crm_dynamic_*) — custom entities with an arbitrary field structure and funnel.

Key Architectural Questions

Are leads enabled or disabled?

This is the first and most important choice. In Bitrix24, you can work in "classic" mode (leads → deals) or in "simple" mode (deals from the start, leads disabled). Leads are needed when:

• There is a high volume of incoming inquiries that require qualification before the sale begins
• Different teams handle qualification and sales
• Separate analytics on inquiry sources before conversion is required

If the company is small and every incoming request is immediately qualified — leads add an unnecessary extra step with no benefit.

When are smart processes needed?

Smart processes (introduced in Bitrix24 in late 2021) are configurable entities. Technically, they are stored in b_crm_dynamic_{type_id} — a separate table per type. They are used when:

• An entity with its own funnel is needed, but it isn't a "sale" (e.g., "Service Request," "Complaint," "Project")
• Standard deal fields don't cover the required logic
• Separate analytics are needed, not mixed with deals

It's important to understand the limitations: smart processes don't support certain features available in deals (for example, the product catalog in older versions). Before choosing — verify the Bitrix24 version and the list of limitations.

Relationships between entities.

A contact can be linked to a company (M:1 relationship). A deal can be linked to a contact and/or a company. A lead, when converted, creates a contact, company, and/or deal. These relationships are stored in b_crm_entity_link.

When designing the structure, decisions must be made: is linking a deal to a contact mandatory? Can a deal exist without a company? What happens when a contact is deleted — are related deals also deleted?

Case Study: CRM Structure for a Service Center

Client — a chain of electronics repair service centers, 5 cities, 30 employees. Initial structure: everything in deals, one funnel "Repair," fields jumbled together — device serial number, model, fault description, parts cost, labor cost, promised return date.

Problem: a deal would be closed, but the client would come back — a new deal was created with no link to the history. A year in, the CRM contained 3,200 "Ivanovs" with no way to understand how many times each had visited.

Designed structure:

Contact — an individual (the client). Mandatory. Stores the history of all visits.

Smart Process "Device" — each piece of equipment that has ever been brought in for repair. Fields: serial number, model, brand, year of purchase. Linked to the contact. One contact — multiple devices.

Deal "Repair" — a specific repair case. Linked to the contact and to the "Device" smart process. Fields: fault description, diagnosis, labor cost, parts cost, warranty status.

Result: the repair history for a device is visible on a single screen. Repeat visits from a client are linked through the contact. A "most frequently repaired devices" report emerged — which turned out to be a genuine insight for the parts procurement team.

Custom Fields vs. Smart Processes

A common mistake: adding 20–30 custom fields to a standard deal instead of creating a separate entity. Symptoms: the deal card becomes a four-screen-scroll form, managers fill in a third of the fields, analytics don't work.

Rule: if a group of fields describes a separate object (not the sale itself) — consider a smart process. If the fields supplement the sale — keep them in the deal, but group them by tabs.

Timeline

Designing the CRM entity structure for a typical B2B business takes 4–8 days: interviews, analysis, relationship schema design, approvals, basic structure implementation, and documentation. Complex structures with multiple smart processes and non-standard relationships take 2–4 weeks.