How Shopify teams and agencies structure approval when a change can affect more than one field or product?
For example, a request like “update the pricing and positioning for this collection” might involve:
product titles;
descriptions;
prices;
metafields;
images;
collection membership;
SEO fields.
When that work reaches review, what are you actually approving?
Do you treat approval as:
one field at a time;
the whole product;
a batch of products;
a CSV/import;
a task or ticket;
one business change that may span several products and fields?
I’m also curious what happens when only part of the change is acceptable.
If the description is approved but the price is not, do you split the change, send the whole thing back for review, or handle those decisions separately?
For agencies working across multiple client stores, what level of approval has proven granular enough to maintain control without making the review process too slow?
I think the right level of approval depends on how much the requested change can affect downstream parts of the store. For a simple text or image update, approving individual fields makes sense, but once pricing, product data, collection membership, and SEO fields are changing together, I’d review the change as one unit.
For larger batches, I’d also separate the approval into two stages: first confirm that the intended business change is correct, then verify the affected products and fields before publishing. That gives agencies a useful audit trail without requiring someone to manually approve every individual field.
I’d be especially careful with changes that can affect multiple products or collections. A small-looking update can have a much wider impact when those relationships are involved.
The unit that holds up in practice is the one Shopify writes atomically, because that is the only boundary where a rejection leaves you in a clean state.
productUpdate carries title, description, SEO fields and status in a single call, so those really are one unit. Variant prices go through productVariantsBulkUpdate, a separate call. Collection membership is collectionAddProducts or collectionRemoveProducts, separate again. Metafields are metafieldsSet. So “update the pricing and positioning for this collection” is four or five writes, and nothing in the platform rolls them back together. Approve it as one blob, have the price call fail validation after the copy call already landed, and the store is now sitting in a state nobody approved and nobody wrote down.
Which is why the “description yes, price no” case is not really a policy question. The price is already a separate write. Approve the copy, send it, leave the price mutation unsent. The genuinely expensive case is the opposite one, where the approval was a single yes and only half of it landed.
What worked for us was approving at the business change level for the human decision and storing the diff at field level for the record. The reviewer reads one story instead of forty checkboxes, but what gets kept is per field, per product, tagged with the mutation it belongs to. That is what lets you answer three weeks later why product 812 has the new copy and the old price, without anyone having to remember.
Are you reviewing off a diff of the pending writes, or off a written description of the intended change? That difference decides whether partial approval is even possible, before any of the granularity questions matter.
From our experience, it is better to approve the business change and not every fields. We define the scope up front, products affected, fields affected, what we want to do, then we go through the entire batch prior to publishing.
We split the approved and the rejected if there is a partial rejection instead of returning everything. For monumental changes a clear task record, what fields, what products, etc. also makes audits easier.
The important point is to have a uniform approval boundary that corresponds to the business risk, instead of adding approval overhead on every field.
The unit I would pick is the one you can undo in one move, because approval without a matching undo is a wish, not a control. lumine’s point about atomic writes sets the lower bound: nothing smaller than one mutation can be approved or reverted cleanly. The upper bound is what a reviewer can hold in their head, and the “description yes, price no” case is where the two disagree - the human wants one story, the platform wants five calls.
What closes the gap for us is approving a diff against the live store at publish time, not the request as written. The request says “reposition this collection”; the diff says these 40 products, these fields, old value, new value. The reviewer reads the story and approves the diff, and the diff is what gets kept - so weeks later lumine’s product 812 has a record of who approved which value, and a partial “no” is lines struck out of the diff rather than a ticket bounced back.
Same shape on the way back: on the restore side of StoreVault, which I build, a rollback is a plan listing every field it will touch, approved before anything is written, and the pre-write state is kept so the rollback itself can be undone. Approval unit equals undo unit; the rest is bookkeeping.