Custom fields are the most common way to 'break' a CRM without noticing. Adding a field takes five minutes. But after a year, the system accumulates 80 fields—half never filled, a third duplicate each other, and one critical field was created as 'string' instead of 'list'—now analytics shows 40 variants of spelling 'Moscow'.
Designing from scratch or refactoring chaos—the difference in CRM performance is 2x. Properly designed fields reduce information search time by 40% and eliminate report errors. We have been designing fields for 5 years, our team has audited over 50 CRM systems. Experience shows: proper design reduces integration time with 1C by 30% and eliminates reporting errors. Every extra field is an extra JOIN in queries to b_uts_crm_deal. Optimizing the structure speeds up the deal card by 25%. Audit starts at $500 and yields 200% ROI within 6 months. Request an audit and get order in your CRM.
Why Field Design Is Critical for CRM?
In Bitrix24, custom fields are created via the main module (class CUserTypeManager) and stored in two tables:
- Field description —
b_user_field:ENTITY_ID(e.g.,CRM_LEAD,CRM_DEAL,CRM_CONTACT,CRM_COMPANY,CRM_SMART_*),FIELD_NAME(with prefixUF_CRM_),USER_TYPE_ID. - Field values —
b_uts_crm_lead,b_uts_crm_deal,b_uts_crm_contact,b_uts_crm_company— one row per record.
Fields of type enumeration store values separately in b_user_field_enum. This is important during migration: you cannot copy a numeric value from a list field between environments—IDs differ.
Which Field Types to Choose and When?
| Type | USER_TYPE_ID | When to Use |
|---|---|---|
| String | string |
Free text: name, comment |
| Integer | integer |
Quantity, ID, number |
| Double | double |
Amount, percentage, weight |
| List | enumeration |
Fixed set of values—statuses, types, categories |
| Date | date |
Date without time |
| Date+Time | datetime |
Date with time |
| Boolean | boolean |
Binary flag |
| File | file |
Documents, images |
| Employee binding | employee |
Responsible, curator |
| CRM entity binding | crm |
Link to deal, contact, company |
| Money | money |
Amounts with currency |
Choosing 'string' instead of 'list' is the most common mistake. If the value comes from a finite set—it's a list. Always.
| Anti-pattern | Solution |
|---|---|
| Text field 'Reason for loss' | Replace with list + comment |
| Custom status duplicating funnel stages | Redesign funnel |
| Field for computed data (amount with VAT) | Remove, compute in reports |
| Too many list values (>15) | Split into categories or use a reference |
Common mistakes when creating custom fields
- Using 'string' type for data with a limited set of values—instead of a list.
- Creating fields with the same meaning by different employees (duplicates).
- Naming fields without the
UF_CRM_prefix—violates Bitrix conventions. - Too many values in a list (>15)—the list becomes inconvenient.
How We Design Fields: Process
- Inventory. On live projects, we often find 50–100 fields per entity. Some created by different people, some duplicate standard ones, some unused.
- Requirements gathering. For each department, we capture what is needed in the card and what matters for reports.
- List value normalization. 5–12 values is the working range. If more—two-level list or smart process.
- Naming.
UF_CRM_DEAL_REASON_LOSSinstead ofUF_CRM_1234567—critical for REST API and diagnostics. - Order and mandatory fields. Required fields, stages, card blocks.
Field design reduces integration time by 2x compared to chaotic structure—our practice confirms this.
What Our Work Includes
- Audit of all custom fields on the entity
- Design of a new structure considering business processes
- Data migration from old fields to new ones
- API and integration documentation
- Employee training on new fields
- Access to a dedicated project manager
- 30 days of post-implementation support
Case: Audit and Refactoring of Fields for a Manufacturing Company
Our client—a metal structures plant. 47 custom fields in the deal, created over 3 years. Task: bring order before ERP integration.
The audit revealed:
- 11 fields of type 'string' containing enumerations (metal type, strength class, supply region)
- 7 fields never filled (all NULL)
- 4 fields duplicate each other ('Order volume' and 'Tonnage')
- 2 fields with date stored as string
Result of refactoring: 47 → 28 fields. String fields converted to enumeration, data migrated via API. Duplicates merged. Unused fields removed after export to archive.
After normalization, ERP integration took half the time—clean field mapping instead of parsing arbitrary text.
Timeline
Audit and design for one entity—2–4 days. For the entire CRM (lead, deal, contact, company)—8–14 days including data migration and approvals.
Order field design and forget about reporting problems. Get a consultation through the form on the website.