DATA · ERP · OPERATIONS · 20 JANUARY 2026 · 7 MIN READ
Product data governance: who is allowed to change what
Nobody owns “products”. Somebody owns price, somebody else owns the SKU, and the argument about who owns the description is the one that breaks your catalogue.
Ownership is per field, not per product. Asking who owns product data produces a turf war; asking who owns price, who owns the SKU and who owns the description produces answers, because each of those has an obvious system of record and an obvious accountable person. The rule that follows is the whole of product data governance: every field has exactly one system that writes it and one team accountable for it, and every other system reads. Where two systems both write the same field, you do not have a governance model — you have a race, and whichever one ran last is your catalogue.
IN SHORT
- Govern fields, not records: price, cost, SKU, stock, title, imagery and compliance copy each have a different natural owner.
- Every field needs one writing system and one accountable team; two systems writing the same field is the defect, not the sync being unreliable.
- Shopify’s staff permissions already separate “Create and edit” products from “Edit price” and “Edit cost”, so the commercial split can be enforced without any custom tooling.
- Metafield definitions carry a type, validation rules and access settings, which turns a free-text field into one that rejects bad values before they reach the storefront.
- A metafield without a definition is an untyped string that cannot be edited in the admin, which is how undocumented data ends up editable only by the app that wrote it.
- Most mid-market stores asking for a PIM have a governance problem, and a PIM installed over an unresolved one just adds a fourth opinion about the price.
Nobody owns “products”
The meeting where this goes wrong is the one where somebody asks whether merchandising or operations owns the product catalogue. Both teams have a real claim, neither will concede, and the compromise reached in the room — “we’ll coordinate” — is not a control. Six months later a promotion runs at the wrong price because the ERP overwrote a manual change nobody logged.
Break the record into fields and the argument dissolves, because the fields have different natures:
- Commercial — price, compare-at price, cost, currency and market-specific pricing. Finance or trading owns these, and they are the fields where an unauthorised change costs money immediately.
- Supply — SKU, barcode, supplier reference, pack size, weight and dimensions. Operations owns these, and they are the fields every downstream system joins on, so a change is a breaking change.
- Availability — stock quantity per location. This has one honest owner, which is whichever system counts physical units, and it is almost never Shopify.
- Merchandising — title, description, imagery, collection membership, tags, SEO fields. Marketing owns these and should be able to change them without a ticket, because the cost of a bad description is much lower than the cost of a slow one.
- Compliance — ingredients, certifications, hazard information, country of origin, regulated claims. Whoever signs off legally owns these, and they are the fields where “it was easier to just type it in” eventually becomes a problem with a regulator rather than a problem with a website.
Write down the system of record before you touch permissions
Governance starts as a list, not as a tool. For every field on the list above, name the system that writes it and the direction data moves. Most catalogues resolve to something like: the ERP writes SKU, cost and supply attributes; the warehouse system writes stock; Shopify writes merchandising; price is the contested one and needs a decision rather than a default.
Price is contested because both answers are defensible. If the ERP is where trading terms, margin rules and cost changes live, price belongs there and Shopify displays it. If promotions are run by a marketing team at campaign speed and the ERP is a monthly rhythm, fighting that with a sync is a losing position — put price in Shopify and let the ERP read it back for reporting. What you cannot do is leave it unanswered, because unanswered means both, and both means the last write wins.
The test for a finished list is simple: pick any field and any person, and you should be able to say where they would change it. If the answer is “depends”, that field is not governed yet.
Shopify ships more of the enforcement than people use
The common assumption is that enforcing this needs custom tooling. Much of it does not.
Staff permissions are already granular in the right places. Shopify’s documented store permissions separate *Create and edit* for products — which covers creating, editing, importing, publishing and archiving products and collections — from *Edit price* and *Edit cost*, which are their own permissions, and from *View cost*, which controls whether someone can see cost at all. *Export* and *Delete* are separate again. That is the commercial split most governance documents describe, available as checkboxes. A merchandiser who can rewrite every description on the site but cannot change a price is a supported configuration, not a custom build.
Metafield definitions turn custom fields into governed ones. A metafield definition is a schema: it fixes the data type, carries validation rules such as maximum length, allowed choices or a regular expression, and sets access — who may read and write the definition and its values across the admin, the storefront and the customer account context. Fields without a definition stay as untyped strings with no validation, and the documentation is explicit that they cannot be edited through the Shopify admin at all.
That last detail explains a pattern worth recognising. If your store has data that only an app can change, and nobody can find where to edit it, it is very often an undefined metafield. App-owned metafields in the reserved $app namespace are deliberate — only the app modifies the definition, merchants can read it, and the app has to set access.admin to merchant_read_write for values to be editable in the admin. Merchant-owned metafields in your own namespace are editable by you and by every installed app. Knowing which kind you are looking at tells you whether the field is locked by design or locked by accident.
The integration is where the policy is enforced or lost
Once ownership is decided, an integration either encodes it or quietly undoes it. Three things to specify, none of which are technical decisions dressed up as business ones:
- Direction, per field. Not per entity. “We sync products with the ERP” is not a specification. “The ERP writes cost, SKU and weight; Shopify writes title, description and images; neither writes the other’s fields” is.
- What happens to an unauthorised change. Someone will edit an ERP-owned field in Shopify, because the admin lets them and they were in a hurry. The integration should either overwrite it on the next run — which is fine, provided everyone knows that is the rule — or flag it. What it must not do is silently keep both values in different systems.
- Who is told. A field that changes without the accountable team knowing is a governance failure even when the value is correct. A daily digest of price and cost changes, by whom, is cheap to build and catches more than any approval workflow anybody will actually use.
Before you buy a PIM
A PIM is the reflexive answer to this problem and frequently the wrong one at mid-market scale. A PIM is excellent at what it is for: many channels, many locales, many contributors, and enrichment workflows with genuine approval stages. It is a poor fix for a single storefront where two teams have never agreed who sets the price, because it does not make that decision for you — it adds a fourth system with an opinion about it, and now the sync has three legs instead of two.
The honest sequence is: write the field ownership list, set the staff permissions to match, define your metafields so the structured data is typed and validated, and specify integration direction per field. That work is measured in days and it is prerequisite to a PIM anyway — you cannot configure one without having made the same decisions. If you finish it and the constraint is genuinely that you are enriching thousands of products across six locales and four channels, buy the PIM, and you will implement it faster for having done the thinking.
The stores that regret a PIM purchase are the ones that bought it to avoid a conversation. The conversation was the deliverable.
The one-page version
If you do nothing else from this post, produce this document. One row per field, four columns, and get it agreed in a meeting where the accountable people are present.
- The field — named precisely, including which variant-level or market-level version you mean.
- The system of record — exactly one, and if the answer is two, the meeting is not finished.
- Who may change it — a role, not a person, mapped to a Shopify permission or a role in the owning system.
- How it reaches Shopify — direct entry, integration, bulk import, or an app, with what happens when it conflicts.
Questions this raises
Who should own product data in an ecommerce business?
No single team should own all of it. Assign ownership field by field: finance or trading for price and cost, operations for SKU, barcode and supply attributes, the system that counts units for stock, marketing for titles, descriptions and imagery, and whoever signs off legally for compliance fields. One accountable team and one writing system per field.
Should price live in Shopify or in the ERP?
Whichever one your business actually changes it in. If trading terms, cost and margin rules live in the ERP, price belongs there and Shopify displays it. If promotions run at campaign speed against a monthly ERP rhythm, put price in Shopify and let the ERP read it for reporting. The wrong answer is both, which is what you have by default if nobody decides.
Can I stop staff changing prices in Shopify without stopping them editing products?
Yes. Shopify’s store permissions list *Edit price* and *Edit cost* separately from *Create and edit* for products, and *View cost* separately again. You can give a merchandiser full control of product content while leaving price and cost to finance, with no custom development.
What stops someone entering bad data in a custom field?
A metafield definition. It fixes the type, applies validation rules — maximum length, allowed choices, a regular expression, a minimum or maximum value — and sets access for the admin, the storefront and the customer account context. Without a definition, a metafield is an untyped string with no validation, and the documentation states it cannot be edited in the Shopify admin at all.
Do we need a PIM?
Only if the constraint is genuinely scale: many channels, many locales, many contributors and real approval workflows. If the constraint is that two teams disagree about who sets the price, a PIM adds a system without settling the argument. Do the field ownership work first — you need it to configure a PIM regardless, and quite often it turns out to be the whole fix.
How do we find out who changed something?
Shopify records staff activity, but the more useful control is a change digest from your own integration: a daily list of which price, cost and stock fields moved and which system moved them, sent to the teams accountable for those fields. It is far cheaper than an approval workflow and people actually read it.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.