Designing Custom iblock Properties for 1C-Bitrix
Two years after a typical Bitrix online store launches, the catalog iblock looks like this: 60 properties, of which 20 have no value for any product, 15 are strings with repeating values, and 8 have names like PROP_123 or MY_FIELD. This is the result of organic growth without design. Adding a property in Bitrix is easy — three clicks. Removing or renaming one without losing data or breaking the 1C import is significantly harder.
Namespace and Naming Conventions
The property's symbolic code (CODE) should reflect its meaning, be unique within the iblock, and match the identifier in the 1C exchange package (if one exists). Practical rules:
- Latin characters, digits, and underscores only
- Upper case:
BRAND,COLOR,WEIGHT_KG - Compound names with underscores:
TECH_PROCESSOR,TECH_RAM_GB - Prefix-based grouping for thematic blocks:
SEO_H1,SEO_DESCRIPTION,BADGE_NEW,BADGE_SALE
Once a property is created, its symbolic code cannot be changed through the standard UI — only via a direct update to b_iblock_property. This makes correct naming at the outset critical.
Required vs. Optional Properties
Marking a property as required (IS_REQUIRED) must be a deliberate decision. If a property is required at the Bitrix level but the 1C import does not pass its value, the element will not be saved and the sync will fail with an error. Rule: it is better to enforce required fields at the form input or business process validation level, not at the iblock level, when data comes from an external system.
Properties for the Facet Filter
Not all properties need to participate in the facet index. The facet is built for "List" and "Reference" type properties — adding unnecessary properties to the index increases rebuild time and the size of the b_iblock_{ID}_index table.
Strategy: properties are divided into three categories:
- Facet — used in the user-facing filter (brand, color, size, material). Type: List or Reference (HL-block). Added to the facet index.
- Informational — displayed on the product card, not used in filtering (technology description, composition, instructions). Type: String, HTML/Text, File.
- System — used programmatically (flags, integration identifiers). Type: String or Number. Not added to the facet.
Multiple Properties: When Yes, When No
A multiple property creates one row in b_iblock_element_property for each value. This is justified for:
- Colors (a product comes in multiple colors)
- Tags (an article belongs to multiple topics)
- Compatible models (a spare part fits multiple devices)
It is not justified when a property has a single value and multiplicity was added "just in case" — this increases b_iblock_element_property volume without benefit.
Aggregate Properties and Computed Values
Sometimes computed data is stored in iblock properties: product rating, review count, "minimum price across trade offers." This works technically, but creates a synchronization task: when a new review is added, the RATING property must be updated via an event handler. The alternative is to compute the value at query time via the component's arResult without storing it in a property. The choice depends on read vs. write frequency: if data is read 10,000 times per day and updated 20 times — storing in a property with caching is justified.
Case Study: Auditing and Restructuring 78 iblock Properties
An auto parts store. A "Catalog" iblock with 78 properties. Goal: prepare for a new 1C configuration exchange and enable the facet index.
The audit revealed:
- 18 properties had no filled values at any point
- 12 string reference properties (make, model, manufacturer) — candidates for HL-blocks
- 5 properties with unreadable codes (
PROP_47,FIELD_2019) — impossible to map to 1C fields without additional investigation - 3 duplicate properties with different codes but identical meaning
After restructuring:
- 18 empty properties deleted (after confirming they were unused in code)
- 12 properties migrated to 4 HL-blocks
- Data migrated to HL-blocks, old string properties cleared
- Symbolic codes renamed via direct updates to
b_iblock_property - Final iblock: 45 properties, 14 of them in the facet index
What Property Design Work Includes
- Audit of existing properties (for refactoring)
- Designing the property schema with types, codes, and settings
- Categorizing properties: facet / informational / system
- Planning HL-blocks for reference properties
- Documenting the mapping between iblock properties and 1C fields
- Writing migration scripts (for refactoring)
Timeline: 3–7 working days for a catalog with up to 100 properties.