Knowledge hub · supplier workflow
How Supplier Product Data Onboarding Works
Supplier data onboarding is the process of turning incoming supplier product information into data the catalog can reliably use.
Onboarding begins when a supplier file, feed or export arrives and ends when the records are mapped, validated, normalized and ready for the company product-data workflow.
The challenge is that each supplier may provide different fields, labels, units and levels of completeness.
Canonicalization fabric
Intake
01Validation
02Mapping
03Normalization
04Enrichment
05Approval
06Supplier data problems
Supplier data is rarely consistent across vendors
One supplier may provide rich attributes and another only a title and part number. Categories can follow different hierarchies. Units and terminology may vary. Some files contain useful information only inside descriptions.
SCHEMA DRIFTDifferent column names and schemasThe same business concept arrives under different labels.INCOMPLETEMissing identifiers or attributesSome feeds identify the product but lack required technical data.TAXONOMY CLASHDifferent categories for the same product typeSupplier groups do not necessarily match company taxonomy.UNIT DRIFTMixed units and value formatsComparable values arrive in different representations.CONFLICTDuplicate or conflicting recordsTwo supplier rows can describe the same product differently.UNSTRUCTUREDUseful facts trapped in descriptionsTechnical data arrives inside prose instead of structured fields.Intake
Start by understanding what the supplier actually sends
The intake step records file format, column structure, identifiers, category fields, update frequency and any known supplier-specific conventions.
This makes the mapping process repeatable instead of rebuilding it from scratch for every delivery.
file_formatCSV / Excel / feed exportDelivery format and workbook structure.identifiersMPN / EAN / supplier codeSignals used to identify the product.category_fieldsSupplier hierarchy labelsSource taxonomy used for mapping.update_frequencySupplier-agreed cadenceOnly what is actually agreed or implemented.column_structureHeader names and orderKNOWNidentifiersProduct identity signalsKNOWNcategory_fieldsSupplier hierarchyMAPPEDconventionsSupplier-specific quirksDOCUMENTEDValidation
Validate the feed before enrichment or publication
Structural validation checks whether required columns exist and whether values use acceptable formats. Product-level validation can flag missing identifiers, duplicate records or fields that cannot be mapped.
Does the file itself hold together?
Required columns exist
Values use acceptable formats
Header structure matches the intake profile
Does each record hold together?
Missing identifiers are flagged
Duplicate records are detected
Fields that cannot be mapped are surfaced
HELD RECORDInvalid or unmappable
VISIBLE FOR REVIEW
Mapping
Map supplier fields into the canonical product schema
Supplier “Part No.” may map to MPN, “OD” may map to Outer diameter and a supplier category may map to a canonical product family.
Mapping separates supplier-specific language from the structure used internally by the company.
Supplier columnBinding routeCanonical field
"Part No."
mpn
"OD"
outer_diameter_mm
"Werkstoff"
material
"Group 4 / Bearings"
family = Ball bearings
"Notes"
unmapped — review
outer_diameter_mmCANONICAL VALUE"42 mm"42"4.2 cm"42"1.65 in"41.91"approx. 42"ROUTED FOR REVIEWNormalization
Normalize units, terminology and values after fields have been mapped
The objective is that products from different suppliers use the same representation for comparable information.
Unit conversion and terminology mapping should follow explicit rules and route ambiguous values for review.
Enrichment and approval
Fill important gaps, then define when a product is ready to enter the catalog
If the supplier record can identify the product but lacks required technical fields, an enrichment workflow can research or extract additional information.
Enrichment should target the canonical schema so the result improves the product record instead of creating another supplier-specific format.
REQUIREDPASSEDRESOLVEDREVIEWED
APPLICABLE CONDITIONS
HOLD
CATALOG GATE
Category and risk specific
Continuous updates
Onboarding is an ongoing data pipeline, not a one-time import
Suppliers add products, change descriptions and update specifications. The workflow therefore needs a repeatable way to process new records and detect changes without recreating the mapping each time.
SUPPLIER PROFILEStable onboarding contract
Mapping and conventions persist across deliveries.Example
One supplier feed before and after onboarding
A useful example includes the original columns, mapping decisions, normalized values, missing fields enriched and the clean output record.
Replace the illustration with a real supplier feed on publication.
supplier_titleFan impeller AC820825manufacturer_refAC820825supplier_categorySeeding equipment partTechnical attribute not supplied—canonical_product_nameKverneland AC820825 Fan ImpellercompatibilityOptima / Optima HDcategoryPneumatic Seeding System Parts → Fan Impellersvalidation_stateSupported values accepted · unresolved weight conflict heldChecklist
A practical supplier onboarding checklist
Ten steps from first delivery to a repeatable update process.
- 01Identify file/feed format and update cadence.
INTAKE - 02Confirm primary product identifiers.
INTAKE - 03Map supplier columns to canonical fields.
MAPPING - 04Map supplier categories to taxonomy.
MAPPING - 05Validate required fields and formats.
VALIDATION - 06Normalize units and controlled values.
NORMALIZATION - 07Enrich priority missing attributes where supported.
ENRICHMENT - 08Review conflicts and ambiguous mappings.
REVIEW - 09Approve output rules.
APPROVAL - 10Define how future supplier updates are processed.
UPDATES
Supplier handoff
See how supplier feeds become validated, catalog-ready records
Bring a representative supplier delivery, the target product schema and the fields that matter most. That is enough to define a practical onboarding test.
01Representative delivery
02Identifiers
03Target schema
04Required fields
Practical onboarding test