Turnkey Design of Custom Fields for Bitrix24 CRM

Designing Bitrix24 custom fields: where record-keeping breaks down

A deal card lives longer than the policy under which it was created. First, a Warehouse comment field appears, then Warehouse comment (new), then someone adds delivery time as a string — and one entity already has three fields about the same thing.

Duplicates in deal cards are not a manager's error but a consequence of fields being added for an immediate task without designing the structure in advance.

At the same time, the reference list diverges: values are entered manually — Romashka LLC, LLC Romashka, romashka, three records instead of one.

An overgrown value reference list stops working as a filter: you cannot group a report by it, and an export by business line produces numbers that do not match the spreadsheets managers keep on their machines.

Manual data entry cements the discrepancy. As long as a field is not linked to a reference list and is not validated at the card level, deals are closed with empty mandatory attributes — and record-keeping rests on the responsible person's memory rather than on the system.

Designing Bitrix24 custom fields starts not with creating fields but with a data model: which entities exist in sales, which attributes are mandatory at each stage, where a reference list is needed and where a calculated value is needed.

Then come field types, bindings, edit permissions, and completion rules. Below we look at how this is arranged and why a spontaneous set of fields almost always ends with reporting that does not reconcile.

What a unified attribute schema in deal cards provides

A unified attribute schema is not a set of fields in a card but a catalog: each attribute has a defined type, allowed-value reference list, mandatory status, completion rule, and edit permissions.

When such a schema is designed before the database is filled, a request goes from first contact to deal closure without manual 'adjustments' — the employee fills in only what actually depends on the client.

Automation relies on predictable fields: if status, source, and category are selected from a reference list rather than written in free text, business rules trigger at the moment a record changes, not after a manual check.

The share of manual operations falls — typical steps such as changing a stage, creating a task, or calculating a closing deadline are handled automatically, and request processing speed is determined by the process policy, not by employee workload.

Data integrity in reports rests on all cards being described by the same attributes.

Reconciliation of samples by pipelines, responsible persons, and periods no longer depends on who filled in a field and how — analytics is built on a single source rather than on manual reconciliation of exports.

A whole class of errors disappears: duplicate counterparties, different designations of the same value, fields filled in 'by eye' and lost when the responsible person changes.

Speed grows not by intensifying work but because data does not have to be rechecked and manually completed.

In Bitrix24, such a schema maps to custom fields, reference lists, and cards of standard entities — but the project only makes sense when attributes are derived from real deal routes, not assembled 'inspired by' the current interface.

Options for implementing reference lists: comparing approaches

A reference list in Bitrix24 can be assembled in four ways, and the choice among them is determined not by the developer's habit but by who owns the data, how often it changes, and whether links to other entities are needed. Below is when each option is appropriate and where it starts hitting limitations.

In practice, options are combined: a reference list in a Smart Process plus exchange with an accounting system. We fix the schema before creating fields — changing the approach after deals have accumulated affects cards, reports, and integrations.

Work order: from analyzing cards to the process policy

Fields in cards almost never live on their own: they participate in the pipeline, end up in reports, access rights, robots, and exchange with the accounting system. Therefore the work order is strict — first record the portal's current state, then change it. Below is what this looks like on a Bitrix24 custom field design project.

1. Card audit. We export the structure of leads, deals, contacts, and Smart Processes: field list, types, duplicates, empty and outdated fields.

   Separately, we check that a field is used in reports, robots, email templates, and distribution rules — hidden dependencies are found at this step, not after migration.

2. Field and relationship schema. We compile a table: field code, type, mandatory status, fill source, binding to the pipeline, and roles with read and write permission. We approve it before setup begins so that edits follow one document rather than a chat thread.

3. Test environment. We move the schema to a portal copy and test everything that must not be touched in production: field composition, the card, robots, exports.

4. Testing on real-world scenarios. We run real paths: manual card creation, import from a spreadsheet, exchange with the accounting system, pipeline report, access restriction for a department. A discrepancy in report numbers is a signal to return to step 2.

5. Migration of settings. We deploy the schema on the working portal and migrate values from old fields to new ones while preserving history. The sequence is arranged so employees can work during the migration.

6. Operating policy. We hand over a document: which fields can be changed, which require approval, who is responsible for reference lists, and how to roll back an unsuccessful change. The policy closes the issue that usually causes card structure to sprawl.

What we hand over: configurations, schemas, instructions

After custom fields are launched, the client is left not only with a working configuration but also with a package by which the CRM can be developed and maintained without us.

We hand over settings, schemas, policies, and the change procedure — in a scope sufficient for a new administrator or contractor to figure it out without messaging the authors. Below is the handover scope, which is also the acceptance checklist.

What is included in the package

• Configured fields and permissions — a list of all created fields with type, mandatory status, default values, and binding to stages and roles. It separately marks which fields are system and which are ours: this removes the question 'can it be touched'.
• Field relationship schema — how fields depend on each other, which entities they are linked to, where autofill and recalculation trigger, and what feeds reports.
• Access policy — a 'role — field — action' matrix: read, write, edit. With a rationale for why some fields are hidden at certain stages and pipeline sections.
• Employee instructions — a guide to filling in fields and handling typical situations: a field does not fill in, a value was pulled in incorrectly, an employee went on vacation and the data is not moving.
• Change log — what changed in the field structure, when, and with whose approval; what risk this posed to reports; and how to roll back the edit.
• Expansion policy — the procedure for adding a new field: which checks to pass so as not to break existing relationships, exports, and samples.
• Export map — which fields go to external systems and reporting, with frequency and responsible person indicated.

The package sits next to the configuration and is updated with it: a field change is not considered implemented until it is reflected in the schema and the log. We conduct acceptance using this same list — you verify each item on your side rather than taking our word for it.

Case study: how manual entry was removed from sales department cards

The sales department worked in a card where a deal had 34 fields, and managers filled in more than half of them manually. One request took about 11 minutes, and every fifth one was returned for rework — the data in the card did not match the contract.

We examine an implementation case study where we redesigned custom fields in Bitrix24 for the real sales process.

What was changed

First, we went through the pipeline and wrote down which data is actually needed at each step. Of the 34 fields, we kept 12 mandatory ones and collapsed the rest into blocks by stage.

Details are pulled from the linked record, source and responsible person are set on creation, and calculated values are computed by formulas instead of manual entry.

Fields were divided into mandatory and reference ones, and availability was configured by roles and stages. A manager sees only what is needed at the current step, and validations prevent moving a deal with unfilled critical data.

Before and after metrics

• Fields in the card: 34 → 12; filling time decreased almost threefold.
• Request processing time: from 11 minutes to 4.
• Share of manual operations: from 58% to 19%.
• Requests returned for rework: from 21% to 5%.

A couple of months later, the team abandoned the parallel spreadsheet for tracking — the data in the card became sufficient both for reporting and for quality control of managers' work.

What to do if your own attributes have already been created in Bitrix24?

Already-created attributes are not an obstacle but source data for design. We take an inventory: where each field actually works — in cards, robots, business processes, reports, exports, and external integrations.

This shows which attributes duplicate each other, which were created for a one-off task and have long been empty, and which carry calculations and the pipeline.

We resolve value conflicts with a priority rule: for each attribute, we assign a master source — a new field, an old one, or an external system.

Fields with the same meaning are merged into one, and discrepancies are not overwritten silently but logged in a reconciliation journal and reviewed selectively rather than by wholesale replacement 'by eye'.

Migration without stopping the department is built on parallel reading. New fields are created alongside old ones, migration proceeds in batches on a schedule, and during the transition period the card receives values from both sources. The manager works as usual; deals do not freeze and do not wait for a maintenance window.

Accumulated history is migrated together with the current value: the editor, time, and nature of the change are preserved in the deal feed so that reporting and review of disputed deals rely on prior records. We do not delete old fields immediately — we archive them and hide them from the interface.

Reconciliation closes the transition. If there are no discrepancies, the old attributes remain only for audit; if there are, we refine the priority rule and repeat the migration for disputed records. The schema is updated without data loss and without stopping the department.

Common technical doubts before starting work

The fastest way to extend a deal card is to add your own field. But a field does not live on its own: it has access rights, exchange behavior, weight in reports, and requirements for department discipline. Below are five doubts people come with before starting work.

We address each before design begins: fields are created together with the access matrix, exchange schema, and report testing on a Bitrix24 copy, not after launch.

Will there be two fields with the same meaning?

Duplicates are the main cause of discrepancies: half the department fills in one field, half fills in another. Before starting, we compile a field map, merge matches, and mark outdated ones as archived. Values are pulled from a reference list — the source remains single.

Will the new field go to 1C and come back?

By default, no: exchange follows a mapping schema into which only agreed fields are included. We define the value type, mandatory status, and export direction in advance. Otherwise the field is filled in the card but remains empty in the accounting system.

Will the field break existing reports and the pipeline?

A mandatory field changes the rules for moving a deal to a stage, and with them the pipeline. Therefore we add new fields as optional, test them on a portal copy, and only then include them in the process. Open deals are not blocked.

Will the workload on the department increase?

It increases if you fill things in manually and unnecessarily. We configure default values, substitution from related entities, and autofill when a deal is created. We leave mandatory only those fields without which a deal does not move.

Let's discuss the task and come back with an estimate and plan

The conversation starts not with an estimate but with your current field schema.

The more detail you provide about what already exists in the cards and how data lives now, the faster we will come back with a scope estimate and implementation plan — without 'by eye' edits already in progress.

What to capture on your side in advance:

• List of entities and cards where new fields are needed: deals, contacts, companies, invoices — marking which fields already exist and which are missing.
• How fields work now: where they are filled manually, what is pulled from the accounting system or external services, and which reports and processes depend on them.
• Completion and validation rules: mandatory status, allowed values, relationships between fields, which roles see the value, and which roles change it.
• Data migration requirements: whether historical values need to be carried over, old fields preserved for reporting, and a rollback to the previous schema on error.
• Acceptance criteria: which scenarios must work, on which data set we test, and what we consider the result of each stage.
• Access and constraints: deployment windows, load requirements, who on your side is responsible for requirements and confirms acceptance.
• Team composition: who leads design, who writes code, who remains on support after launch, and how many people are involved on each side.

Using this input, we compile a stage-by-stage implementation plan and record who on the team is responsible for each. Describe the task — we will come back with an estimate, timeline, and agreed acceptance criteria.