Two years after launching a typical online store on Bitrix, the catalog infoblock looks like this: 60 properties, 20 of which are empty in all products, 15 are string type with repeated values, and 8 have codes like PROP_123 or MY_FIELD. This is the result of organic growth without design. Our 7+ years of experience and over 100 projects show that a well-designed schema prevents chaos. The typical cost of such a design is from 50,000 rubles, saving you up to 500,000 rubles in refactoring costs. If you need order in properties — we will design a turnkey schema in 5–7 days. Adding a property in Bitrix is easy — three clicks. Removing or renaming without data loss and breaking 1C import is significantly harder.
How to Avoid Chaos in Infoblock Properties?
An ill-conceived property schema leads to problems: the faceted index does not build, 1C exchange fails, and developers waste hours deciphering PROP_47. Experience shows that saving time at the start results in weeks of refactoring. The average saving on refactoring is from 400 developer hours. Over 90% of our clients avoid property chaos after our design. We guarantee that the schema we design serves for years without rework.
How to Choose a Symbolic Code for a Property?
The symbolic code (CODE) must be Latin, unique within the infoblock, and match the field in 1C (if exchange exists). Custom property design in Bitrix ensures proper normalization and smooth migration. Practical rules:
- Only Latin letters, digits, underscores
- UPPER_CASE:
BRAND,COLOR,WEIGHT_KG - Compound names via underscore:
TECH_PROCESSOR,TECH_RAM_GB - Grouping by prefix:
SEO_H1,BADGE_NEW
| Variant | Example | Recommendation |
|---|---|---|
| UPPER_CASE, prefix | CATALOG_ARTICLE |
✅ For consistency |
| lowercase, no prefix | article |
⚠️ Acceptable but less readable |
| Random characters | PROP_47 |
❌ Forbidden — unreadable |
| Mixed case | ArticleNumber |
❌ Not recommended due to case-insensitivity |
Symbolic code cannot be changed after creation without directly accessing b_iblock_property. Therefore, proper naming at the start is critical.
Faceted Properties and Their Settings
Mandatory (IS_REQUIRED) should be set consciously. If a property is mandatory but the 1C import does not pass it — the element will not save, and the exchange will fail. Rule: mandatory is better controlled at the input form or in a business process, not at the infoblock level if data comes from external sources. Losses from import errors can be up to 100,000 rubles per incident.
Not all properties should participate in the faceted index. Division strategy into categories:
| Category | Examples | Data Type | Faceted Index |
|---|---|---|---|
| Faceted | Brand, color, size | List, HL-block | ✔️ |
| Informational | Description, composition | String, HTML | ❌ |
| System | Integration ID, flag | String, number | ❌ |
When to Use Multiple and Computed Properties?
A multiple property creates a row in b_iblock_element_property for each value. It is justified for colors, tags, compatibility. Not justified "just in case" — it increases table volume without benefit.
Sometimes a property stores rating or minimum price. If data is read often and updated rarely — storing in a property with cache is justified. Otherwise — compute in arResult. HL-block directories are 3x faster for faceted filtering than list properties.
Case from Our Practice: Audit and Restructuring of 78 Infoblock Properties
Auto parts store. Infoblock "Catalog" with 78 properties. Task: prepare for exchange with a new 1C configuration and enable faceted index.
Audit revealed:
- 18 empty properties (no filled values)
- 12 string directories (brand, model) — candidates for HL-blocks
- 5 properties with unreadable codes (
PROP_47,FIELD_2019) - 3 duplicate properties
Result after restructuring:
- 18 empty properties removed (checked for code usage)
- 12 properties migrated to 4 HL-blocks with data migration
- Symbolic codes renamed via
b_iblock_property - Final infoblock: 45 properties, 14 in faceted index
From practice: a typical property audit takes one working day, and restructuring up to 7 days depending on volume.
Stages of Property Design
- Audit of current schema (if exists) — identify empty, duplicate, and unreadable properties.
- Design new schema — determine types, codes, mandatory, grouping.
- Distribute into categories (faceted, informational, system).
- Plan HL-blocks for directories.
- Document mapping with 1C fields.
- Write migration and rollback scripts.
- Test exchange and filtering.
Example migration script for converting a list property to an HL-block
// Pseudocode: create HL-block, transfer data, delete old property $hlBlockId = createHlBlock(['NAME' => 'Brands']); foreach ($oldValues as $value) { addElementToHl($hlBlockId, ['UF_NAME' => $value]); } updatePropertyType($propertyId, 'HL', $hlBlockId); What Is Included in the Work
- Documentation: property schema with codes, types, mandatory, 1C mapping.
- Migration scripts: for refactoring existing data.
- Access rights: to infoblocks and HL-blocks for further maintenance.
- Instructions: on adding new properties in the future (code templates).
- Support: 1 month of consultations after delivery.
Timeline for Property Design
From 3 to 7 working days for a catalog with up to 100 properties. Exact estimate after audit of current structure. Contact us to discuss your project and get a consultation. Order design now — avoid refactoring costs.
Our infoblock property design for custom properties in Bitrix includes infoblock property audit and property normalization to ensure correct 1C CommerceML exchange and smooth hl-block directories setup.
CommerceML — the exchange standard that the property structure must comply with. 1C-Bitrix documentation on properties — official reference.