Auto-filling descriptions in 1С-Битрикс: where the data chain breaks
The chain "supplier — price list or export — catalog — product card" consists of four transitions, and at each one part of the data is lost.
It manifests externally in the same way: empty product descriptions for half the catalog, the price updated but the text left over from the previous delivery. Below — where exactly it breaks and why import alone does not solve the problem.
The first break is on the source side. At the supplier, the description lives in a free-form note, in a separate file, or does not exist at all: in the price list, one column is allocated for it, which fits a stub of a few dozen characters.
Importing descriptions from the price list will transfer this stub correctly — the selection rule will work, and the site will get text that there is nothing to index.
Here, it is not import that helps, but assembling the description from structured attributes: brand, model, purpose, package contents.
The second break is catalog exchange with 1С. The export provides products and a separate package of offers; if only the price part is configured, the product card gets the price and stock, while text properties arrive empty.
A common cause is that properties are tied to the offers block rather than to the product, or the field mapping does not cover custom properties.
The third break is manual filling of product cards.
A manager transfers text from an email or specification while there are dozens of items; with hundreds, the process falls behind deliveries, and after the very first price list update, descriptions diverge from price and availability. Then pages fall into "thin content", items lose visibility, and edits pile up in a queue.
Auto-filling descriptions in 1С-Битрикс makes sense to build as a pipeline with checks at each transition: field mapping, text assembly rules, validation before writing, and manual exception handling. We explain how this is arranged and what each section covers.
What a managed data flow from external sources provides
The data flow from external sources is built as a pipeline with explicit rules at each step.
A supplier's price list, a manufacturer's export, or a characteristics table is brought to a unified structure, items are matched by SKU and barcode, after which the description template for the category is filled with property values and written to the information block 1С-Битрикс.
If the match fails or a field arrives empty, the product is not published silently — it goes to an exception queue with the reason indicated.
The effect of catalog automation is measured by three numbers. The time for a description to appear for a new item is reduced from two to three days of manual work to minutes — the product enters the catalog in the same run as it enters the source.
The share of cards published without content team edits reaches 80-90%; the rest are deliberate exceptions, not missed defects.
Card completeness is maintained not by editor discipline but by mandatory properties and pre-write checks: empty characteristics, mismatched units of measurement, and duplicate SKUs are filtered out before publication.
The amount of manual work for the content team is reduced to handling exceptions and editing templates instead of typing text for each item.
The speed of item output is set by the exchange schedule: incremental export touches only changed records, so updating a catalog with tens of thousands of items does not require a full rewrite.
Our engineers configure matching rules, description templates, and a run log — when the supplier's export format changes, the flow does not silently fall apart but shows exactly what failed to match.
Auto-filling methods: one-time exchange, schedule, events
Choosing a mode is a choice between data freshness and predictable load on the catalog. A one-time price list import covers the start or a major assortment rebuild, batch exchange covers regular synchronization in large portions, and events cover point edits. Below is a comparison by conditions of use and by the limitations each mode imposes.
| Mode | When it fits | Limitations |
|---|---|---|
| One-time price list import | Initial catalog filling, supplier change, one-time assortment rebuild | Manual edits after loading are lost if the source is not marked; a repeated run must not duplicate cards |
| Batch catalog exchange | Mass update of descriptions and characteristics in portions | Long transactions and locks during writing — need a portion size and a pause between batches |
| Scheduled exchange | Prices, stock, descriptions from external sources — once an hour or daily | Data always has a delay; if a window fails, a catch-up of the missed exchange is needed |
| Event-driven exchange | Reaction to a change in a product card, warehouse, or order | Depends on external service availability; a queue and retry on failure are mandatory |
Limitations common to all modes
Filling must not overwrite text that a content manager has edited, so both the source and the specific card field are marked. Mass writing goes in portions with logging — otherwise a failure in the middle leaves the catalog in an intermediate state.
Rebuilding the search index is planned separately: its load adds to the exchange, and on a weak server it delays catalog response.
Implementation procedure: from source analysis to handover
Implementation of auto-filling begins not with code but with an inventory: which sources actually provide texts — exports from the accounting system, supplier cards, content team tables — in what form they arrive and how often they change.
Then we design matching rules and a validation loop so that the first import does not overwrite manually verified descriptions or create duplicates.
- Data source audit. We compile a list of sources, assess the completeness and relevance of fields, and note overlaps and contradictions between them. We record the owner of each source and the update frequency.
- Product matching rules. We choose a key — SKU, barcode, or a combination of properties — and describe behavior for new items without a key, duplicates, and discontinued items. The rule must not allow merging two different cards into one.
- Exchange scheme and source priorities. We map source fields to the card description and properties, set the priority order if a product is described in several places, and define text normalization rules: markup, abbreviations, units of measurement.
- Exchange setup. The exchange runs on a schedule and in portions, with an operations log and a repeat run without duplicates; after a connection loss, processing continues from the stopping point, not from the beginning.
- Test catalog loop. We deploy a copy of the catalog with the real structure and properties and run the full volume: measure processing time, check a sample of cards, look for broken links and empty fields.
- Exchange acceptance and handover. We reconcile a control sample before and after, check rollback to previous descriptions, agree on a monitoring regulation, and hand over documentation with instructions for the content team.
What we hand over: configurations, schemes, regulations
Implementation is not complete when the exchange has worked once, but when the client can restart, check, and fix it without us. Therefore, at acceptance we hand over a set of artifacts: a working configuration, schemes, and instructions for the on-duty administrator.
Each document is tied to a specific node — where the source is located, what starts the exchange, how an unsuccessful edit is rolled back.
- Data exchange scheme — the path from an external source through an intermediate layer to information blocks and trade offers, with control points at each step.
- Field mapping — a table "source → property → transformation rule": types, requiredness, behavior on an empty value.
- Exchange configurations and settings — export of agents, handlers, access rights, and schedule to deploy a stand from scratch.
- Error handling regulations — which source responses are critical, who receives a notification, how to restart only the failed part without repeating the entire export.
- Exchange documentation — file formats, limits on volume and response time, requirements for encoding and delimiters.
- Backups of settings — versions of configuration and matching rules with dates, to roll back a disputed edit in one step.
- On-duty administrator instructions — how to check the completeness of descriptions on a sample of products, where to look in case of discrepancy, and when to call us.
Case study: a catalog with tens of thousands of items without manual editing
A catalog of 40,000+ items was assembled from supplier exports: some came with ready descriptions, some — only with a name, SKU, and characteristics.
A card without a description does not pass moderation on marketplaces and is poorly indexed, so managers added text manually — 8-10 minutes per item, and a fresh delivery sat unsold until it was processed.
We built an auto-filling pipeline on the side of the information blocks 1С-Битрикс: a parsing module brings exports to a unified structure, rules tie the text template to a section and set of properties, and the finished description is checked for duplicates, minimum length, and correctness of characteristics.
The deduplication key by a set of significant properties — a repeated exchange overwrites only changed cards, not the entire catalog.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Share of cards without a description | 38% | 2% |
| Time from export to item on sale | 3-5 days | the next exchange cycle, within a day |
| Support requests about empty descriptions | up to 60 per month | isolated |
| Load on the catalog during exchange | storefront slowdown | portioned writing, storefront is not blocked |
The remaining 2% are items for which the supplier simply has no data: we mark them in the report so that the manager can see exactly what requires manual input, rather than searching the entire catalog.
How does scheduled exchange differ from event-driven exchange?
Short answer: these are two different trade-offs between the delay in description appearance and load predictability. Batch scheduled exchange gives an even schedule and is easy to debug, while event-driven exchange gives minimal delay but requires reliable notification delivery.
In scheduled exchange, the scheduler — agents in 1С-Битрикс — launches a task at a set interval, which selects changed products by timestamp or description checksum and processes them in portions.
The delay equals the period plus the pass time: with tens of thousands of items and a portion of a couple hundred records, one cycle takes minutes, so the actual update arrives with a delay of tens of minutes. But the load on the catalog is predictable, and the heavy pass is moved to a night window.
Event-driven mode works the other way around: when a card is edited, the source publishes a notification, the handler picks it up from the queue and updates the description almost immediately — the delay is measured in seconds.
The price is infrastructure: a queue, retries, idempotency checks, and a log, otherwise a lost notification will leave a product without a description. Plus peaks: a mass import causes a burst of events, and the catalog is protected by limiting parallel writes.
In practice, a hybrid is chosen: events handle operational edits, and a rare scheduled reconciliation picks up what was lost in the queue. The decision on the mode comes down to two questions — how often the data changes and how many simultaneous writes the database can handle.
If descriptions are updated once a day, the schedule is sufficient, and it is easier to maintain: disabling the task stops the flow with a single operation.
Technical doubts: what is asked before launch
Before launching auto-filling, the same set of questions is asked: what will happen to manually written texts, how will cards with incomplete source data behave, and what will happen to the catalog if the exchange fails. We answer point by point.
Will manual descriptions be overwritten?
No, if priority is set: a field with manual text is marked with a lock flag, and loading does not touch it — only empty or automatic values are updated. The change log for a card shows what and when was overwritten and allows returning the previous version.
The source provides incomplete data — what will end up on the site?
The description is assembled from a template from properties and is checked for required fields, duplicates, and contradictions. If there is not enough data, the card is not published but goes to a manual revision queue indicating exactly what is missing.
Can only part of the catalog be covered?
Yes. The selection is defined by a rule — section, supplier, property value. Exceptions are also described by a rule and persist between runs: on the next exchange, the same set will remain outside automation.
How is the exchange protected from failures and excessive rights?
Writing goes in portions and in a transaction: if the connection breaks, what was loaded is saved, a retry completes the remainder, and an empty value from the source does not overwrite existing text.
The account for the exchange receives only the necessary rights, and changes are recorded in the log.
Let's discuss the task and come back with a work plan
An exact estimate of exchange implementation cannot be given based on the single phrase "we need to fill product descriptions" — everything is determined by the structure of your catalog.
The same supplier export behaves differently in two stores: in some, characteristics are in information block properties, in others in trade offers, and in others part of the texts is written manually and cannot be lost. Therefore, the engineers' analysis of the task begins with your data, not with an average template.
What is useful to send before the call:
- a sample export from an external source — a real file, even if for one day;
- a field map: which product properties are filled automatically and which remain manual;
- enrichment rules: what we take from the source as is, what we assemble from a template from characteristics;
- the expected frequency and volume of updates — how many items per run and how often it runs;
- access to a test loop or catalog copy to check the exchange without risk to the production site.
On the call, we clarify discrepancies in the data, matching rules with trade offers, what to do with empty fields from the supplier, how to log overwriting, and on what sample we will run the exchange before launch.
In response, we send an implementation estimate and a catalog work plan: stages, what we do at each, what will be needed from your side, and in what order the result comes out.
Describe the auto-filling task — we will come back with an estimate, plan, and distribution of stages.