Automated Product Description Filling in 1C-Bitrix

You launched an online store on 1C-Bitrix. Thousands of products, but descriptions are empty or copied from a price list. Content managers spend hours searching and formatting — yet descriptions still differ in style and quality. Mistakes during copying, duplicates, outdated information.

The solution is automated population from external sources. Our solution for automatic description population in 1C-Bitrix uses product description parsing from donor sites, Icecat integration, and AI description generation. Recently, a client approached us with a catalog of 10,000 electronics products. Descriptions existed for only 20%; the rest were empty. After implementation, coverage reached 95% in two weeks. Our fallback approach ensures 3x higher stability than single-source parsing.

We design a system that collects descriptions on its own without overwriting manual edits, using a chain of sources with fallback. Integration with any supplier through a unified provider interface. We use Bitrix event handlers to trigger auto-population. Our catalog automation for 1C-Bitrix commercial catalog integrates with 1C UT exchange for data synchronization. Get a consultation for your project — we will assess the scope of work free of charge.

Implementation cost starts from 90,000 rubles, with annual savings up to 500,000 rubles — a 5x return on investment. AI generates descriptions 10x faster than manual writing, reducing costs by 60% and saving 80% of managers' time.

What Triggers Description Population?

Auto-population launches in three situations:

• When a new product is added — handling the OnAfterIBlockElementAdd event. The product is just created, fields are empty — the system goes for a description to the sources.
• On a schedule for unfilled items — a cron job finds elements with empty DETAIL_TEXT and puts them in the queue.
• On a manual request — a manager clicks 'Get Description' for a specific product in the administrative section.

How to Protect Manual Edits?

The key element is the DESCRIPTION_LOCKED property (type S, values Y/N). When a manager manually edits a description in the administrative section:

• DESCRIPTION_LOCKED = Y is set
• The auto-population system skips this element

We set the flag via the OnBeforeIBlockElementUpdate handler — we check if DETAIL_TEXT changed relative to the previous value. If yes and the change did not come from the auto-population system, we set the flag.

In the Bitrix Framework documentation, the recommended approach to change control via events is described.

Source Chain with Fallback

The description is searched sequentially: if the first source does not yield a result, we try the next one:

1. Manufacturer API by VENDOR_CODE
2. Icecat database by EAN/barcode
3. Manufacturer website parsing
4. AI generation by name and characteristics (last resort)

Each source implements a unified interface:

interface DescriptionProviderInterface { public function getDescription(string $sku): ?string; } 

The orchestrator iterates through providers in priority order. Additionally, we cache responses — if a provider fails, we use the last successful result.

Queue and Prioritization Importance

Not all products are equally important. Queue priority:

• High: products with active orders or views (data from b_sale_order_item, b_stat_session)
• Medium: new products without description
• Low: old products not viewed for more than 30 days

Implemented via a priority field in the queue table; the worker picks tasks ORDER BY priority DESC. This ensures the most important items get descriptions first.

Process

Common mistakes in auto-population:

• Overwriting manual edits: our solution with the DESCRIPTION_LOCKED flag eliminates this problem.
• Unstable sources: fallback and response caching ensure fault tolerance.
• Source mixing: priority and meta-information preservation allow tracing the description's origin.

Deliverables

• Fully implemented auto-population system with queue and priorities
• Connected sources (up to 4 in the base version)
• Manual edit protection mechanism
• Architecture and operation documentation
• Manager training (1 hour)
• Technical support for 1 month after launch