A supplier file arrives overnight. Most rows look normal, a handful have missing identifiers, and one price column has changed its decimal format. A pipeline that only checks whether the file can be opened will happily turn a data problem into a storefront problem.
Working on Magento catalogs has made me treat imports as production software. The important output is a trustworthy change to the catalog, with enough evidence to explain what happened when a merchant asks about a missing product.
Separate receiving data from publishing it
I prefer a staging area between the source file and the live catalog. Receiving a file should create an import run with a source name, arrival time, checksum, and schema version. That gives the team an identifiable object to investigate without rerunning a supplier download.
The next stage normalizes values into a canonical representation. Currency, decimal separators, measurement units, and availability labels deserve explicit rules. A blank stock field must have a defined meaning: unknown, unchanged, or zero. Those meanings should never be chosen accidentally by a type conversion.
Only after normalization should the pipeline compare the proposed values with the current product state. This makes it possible to show a change report before applying an unusually large update.
Make validation match the business operation
A syntactically valid number can still be a dangerous price. A valid SKU can still identify the wrong variant. My validation rules therefore cover several different questions.
- Identity: can this row be matched to exactly one product or variant?
- Structure: are required fields present and correctly typed?
- Meaning: are currency, units, and availability values recognized?
- Change size: is the proposed update within the range the business expects?
- Relationships: do parent products, categories, and variant attributes exist?
These rules also need an action. An invalid image URL may leave the previous image in place. An ambiguous product identifier should prevent that row from changing anything. A suspicious price collapse may require review of the entire affected product family.
Quarantine the right unit of work
Rejecting one bad row can be better than rejecting thousands of unrelated valid rows. However, row-level isolation is not always safe. A configurable product and its variants may need to move together, so the unit of validation should be the product family.
A quarantine record should contain the source row, normalized values, rule that failed, and a readable explanation. “Validation failed” creates another investigation. “Currency is missing for supplier price 49.95” gives someone a repair task.
The same rule applies to missing rows. Their absence should not automatically delete products unless the feed contract explicitly says it is a complete snapshot. Partial feeds and incremental feeds are common enough that deletion must be deliberate.
Design for a second run
A safe import can be repeated. I use stable external identifiers and compare normalized values before writing. Replaying an unchanged source should produce no unexpected catalog changes, and a failed run should resume from recorded progress.
After applying updates, I verify a sample through the storefront or product API. A database write does not prove that indexing, caching, and downstream feeds have caught up. The run report should distinguish accepted rows, changed products, rejected groups, and work still waiting downstream.
Adobe Commerce documents a validation step in its native import workflow. I treat that as one checkpoint inside a broader process. Supplier contracts, anomaly detection, and recovery still belong to the integration.
The operational question I want the import report to answer is simple: which products changed, why did they change, and how do we recover the previous state if the source was wrong?
Updated 25 September 2026.