Bitrix24 Custom Fields
This article describes working with Bitrix24 custom fields in LightLead.
Discovering Custom Fields
Custom fields are loaded from CF_ or UF_CRM_. Custom fields in Bitrix24 use the CF_ prefix (new format) or UF_CRM_ (legacy format). LightLead reads both types during discovery. Renaming a field does not change its identifier, so matching is preserved.
Field Matching
LightLead uses the field identifier (field_id or field_code) for matching. This provides:
Rename resilience: matching is preserved when a field's name is changed in the CRM
Uniqueness: each field is identified unambiguously
Cross-account isolation: fields from different accounts do not overlap
Custom Field Types
| Field Type | Support | Usage |
|---|---|---|
| Text | Full | Grouping, filtering |
| Number | Full | Metrics, range filtering |
| Date | Full | Filtering by period |
| Select | Full | Grouping, filtering |
| Multi-select | Partial | Filtering by inclusion |
| Checkbox | Full | Filtering (yes/no) |
| Phone | Full | Grouping, filtering |
| Full | Grouping, filtering | |
| File | Not supported | — |
| Image | Not supported | — |
Impact on Saved Reports
Important considerations when changing custom fields:
Renaming a field: reports continue to work, the name updates automatically
Changing a field's type: may cause errors in reports that use the field as a metric
Deleting a field: reports using this field will show an error, the field is marked as unavailable
Adding a field: the new field becomes available after the next discovery run
Recommendations
Plan your custom field structure in advance
Avoid changing the type of an existing field unless necessary
Before deleting a field, check which reports use it
Use meaningful field names for easier searching in the interface