Which Product Data Source Should Win When Systems Disagree?

Why one master system is often the wrong answer

Calling one database the single source of truth sounds tidy, but product records combine facts created for different purposes. A supplier may know a component's measured dimensions. An ERP may control internal item codes, costs and stock. Shopify may contain reviewed customer-facing titles, images and sales copy. None of those systems is automatically authoritative for every field.

A blanket priority rule creates avoidable damage. If the latest supplier file always wins, a blank description can erase approved copy. If Shopify always wins, an old weight can survive after engineering corrects it. If the ERP always wins, abbreviated operational text can replace useful storefront language.

Product intelligence should therefore define ownership at attribute level. It creates consistent product knowledge by separating identity, descriptive facts, commercial values, operational values, relationships and evidence, then applying a suitable rule to each group.

Classify the field before choosing its authority

Start by grouping fields according to the decision they support. Identity fields answer which record this is. Specification fields describe measurable facts. Commercial fields cover prices and purchasing terms. Operational fields cover stock, status and fulfilment. Merchandising fields explain the product to a customer. Relationship fields connect variants, replacements, compatible machines and categories.

Write an owner, permitted sources, refresh method and review threshold for each field. An internal product ID may be immutable and owned by the merchant. A GTIN may come from a verified brand or GS1 record. Available stock may be owned by the inventory system. A Shopify title may be maintained by the ecommerce team but grounded in approved identity and specification data.

The result is an authority matrix, not a vague claim that one platform is the master. It should also state what happens when the nominated source is missing, stale or contradicted by stronger evidence.

Resolve identity before comparing values

A conflict is meaningful only after the records are known to describe the same product and variant. Match on stable identifiers rather than titles, row positions or filenames. Keep the supplier item number, internal item ID and destination IDs such as Shopify product and variant IDs as separate values with explicit relationships.

GS1 states that a GTIN uniquely identifies a trade item that may be priced, ordered or invoiced. Where a valid GTIN exists, it can support identity, but it does not replace the merchant's internal ID or a platform-specific record ID. Different variants and pack levels may require different trade-item identities.

Do not force a match merely because two descriptions are similar. A 600 mm bucket and a 24 inch bucket may appear equivalent after unit conversion but differ in pin dimensions, capacity or application. Uncertain matches belong in a review queue rather than an automatic merge.

Prefer evidence and ownership over the newest timestamp

Last updated is useful context, not proof of correctness. A new spreadsheet can repeat an old error, while a previously approved engineering measurement remains valid. Store the source, observation or effective date, method, confidence and approval state behind important values.

W3C PROV-O provides a model for representing provenance across different systems and contexts. In practical catalogue work, that means a reviewer can see which supplier document, internal record or authorised person produced a value and what process transformed it.

Set evidence requirements according to customer risk. A colour-name normalisation may need a simple approved mapping. A load rating, compatibility claim or regulated attribute needs stronger source evidence and explicit review. If the evidence is insufficient, retain the last approved value or hold publication; do not guess.

Treat blanks, corrections and intentional overrides differently

A blank can mean not supplied, not applicable, intentionally removed or unknown. Those states must not be collapsed into one empty cell. Define whether each incoming blank leaves the existing value unchanged, clears it after approval or creates an exception.

Separate a source correction from a merchant override. If a supplier corrects a material from steel to aluminium, the proposed change should cite that evidence. If the ecommerce team shortens a title for customers, record it as a channel-specific presentation value rather than changing the underlying product identity.

Store overrides with an owner, reason and review date. Otherwise the next import cannot distinguish a deliberate decision from stale data and may repeatedly overwrite it.

Use clear conflict outcomes instead of silent overwrites

Every comparison should end in a named outcome: accept, keep, normalise, combine, review or reject. Accept a value when it comes from the authorised source and passes validation. Keep the existing value when the incoming source has no authority. Normalise equivalent units or terminology without changing meaning. Combine only fields whose model explicitly allows multiple values.

Route a conflict to review when authoritative sources disagree, when a high-risk claim changes, or when identity is uncertain. Reject a record when required identifiers are invalid or the proposed value breaks an agreed rule. The run summary should count each outcome rather than reporting a file as successful simply because it was read.

Keep field-level reasons visible to the reviewer. ‘Shopify retained because supplier is not authorised for title’ is actionable; ‘conflict found’ is not.

Build a preview that explains the proposed decision

Before writing to any connected system, show the current value, proposed value, field owner, source evidence, rule applied and affected destinations. Group low-risk normalisations separately from changes that alter customer meaning.

A reviewer should be able to approve or reject individual fields without accepting an entire supplier row. If a corrected dimension is approved but a marketing claim is unsupported, the workflow can publish the fact and hold the claim.

The Government Data Quality Framework recommends a structured, proactive and evidence-based approach to understanding and improving data. A field-level preview turns that principle into a repeatable operational control instead of relying on someone to spot differences in two spreadsheets.

1. Identify the product and variant using stable source and destination IDs.
2. Classify each incoming field and find its authority rule.
3. Validate format, units, allowed values and evidence.
4. Compare with the current approved value and assign a conflict outcome.
5. Present material differences for field-level review.
6. Write approved changes, read them back and retain the result.

Publish complete Shopify state only from an authorised model

Shopify documents productSet for synchronising product data from an authoritative external database. For options and variants, it treats the input as complete state and removes entries that are omitted. Other omitted product fields remain unchanged, while included empty values can clear them. That makes authority, payload scope and blank-field behaviour especially important before a batch runs.

Build the outbound Shopify payload from the approved product model, not directly from one supplier row. Retain the authorised store, Shopify product ID and variant IDs so a renamed product is updated rather than duplicated. Limit the payload to the agreed scope and preview list-type changes carefully.

After the write, read the record back and check the public page. Confirm that the title, variants, specifications, images, status and customer-facing copy still describe the same product. A successful API response does not prove the page is coherent.

Keep ERP and commerce responsibilities explicit

A connected NetSuite or Sage 200 record may own operational and commercial values while Shopify presents approved sales information. Document that boundary instead of allowing both sides to edit the same field without a rule. Bidirectional integration does not require bidirectional ownership of every attribute.

When a user edits a governed value in a downstream system, decide whether the change is rejected, returned to the owning workflow for approval or recorded as a channel-specific override. Never let two scheduled jobs alternate the same value indefinitely.

Monitor stale connections and partial failures. If stock updated but a product relationship did not, the exception should remain open with the affected IDs and destination. Do not replace a known value with an empty fallback because one system was temporarily unavailable.

A concrete example: three systems disagree about one excavator idler

Imagine a supplier file labels an idler as model IR-450, gives its weight as 38 kg and lists compatibility with two excavator models. NetSuite holds internal item 10482, a cost and 12 units in stock. Shopify product 812345 uses the reviewed title ‘Excavator Idler for ZX135’ and shows 36 kg from an older catalogue. A second supplier sheet says 39 kg but has no measurement evidence.

The identity mapping confirms that all records refer to the same trade item and retains each system's ID. NetSuite continues to own stock and cost. The approved supplier drawing owns dimensions and weight, so 38 kg is proposed with its document reference. The unsupported 39 kg value is rejected. Compatibility is held for review because it affects suitability, while the Shopify title remains a channel-owned presentation value unless the reviewed fitment decision changes it.

The reviewer approves the evidenced weight and one confirmed application but rejects the second. The workflow updates the governed record, then sends approved changes to the authorised Shopify, NetSuite and Sage 200 connections according to their field ownership. It reads back each destination and records one held compatibility exception rather than calling the whole item complete.

Design for rollback and repeatable decisions

Keep the previous approved value, the proposed value, the source snapshot, the rule version and the approval record. If a source is later withdrawn or a mapping rule proves wrong, the team can identify affected products and restore the last trusted state without reconstructing it from memory.

Make reruns idempotent: the same inputs and rules should produce the same decisions without creating duplicate products, variants or conflict tickets. Preserve stable destination IDs and use per-record status so a retry processes failed work without repeating successful writes.

Review the authority matrix when responsibilities change. A new PIM, ERP migration or supplier contract can alter ownership, but that change should be explicit, versioned and tested before production data starts moving.

Test the rules with difficult cases, not only clean records

Create regression cases for missing GTINs, reused supplier codes, conflicting dimensions, unit conversion, a legitimate channel override, a blank value, a discontinued variant, duplicate matches, stale evidence and an unavailable destination. State the expected field-level outcome before running the test.

Include integration failures: an expired Shopify connection, wrong store, missing NetSuite item, invalid Sage 200 reference and a partial batch. Confirm that the system cannot silently switch to title matching or mark unverified destinations as updated.

Measure conflicts resolved with evidence, incorrect overwrites prevented, records held for identity review, stale overrides found, successful read-backs and time from approved correction to verified publication. Speed matters only after the decisions are trustworthy.