How do Shopify teams and agencies decide what can go straight to production and what needs additional approval?
I’d like to understand the actual operating model, not just the general principle.
For example, would your rules be different for:
fixing a typo;
updating a product description;
changing SEO fields;
replacing product images;
editing metafields;
changing collection membership;
changing product status;
changing a price by 5%;
changing a price by 30%;
publishing a large batch across hundreds of products?
Do those rules also depend on who is making the change?
For example, can a senior operator publish something that a junior team member, freelancer, client user, app, or AI workflow would need to escalate?
Do you use fixed rules based on something like:
change type + risk/size + operator role
or is approval still decided case by case?
I’m especially interested in agency setups with multiple client stores. How do you keep those boundaries clear when each client has different risk tolerances and approval requirements?
If you have one, I’d also be interested in seeing a practical example: a matrix, SOP, RACI, Shopify Flow setup, approval app, or simply how the process works when something goes wrong.
We stopped sorting by change type and started sorting by whether the change leaves Shopify. A typo in a product description stays inside the admin and is one edit to revert. Flipping product status to active pushes that product into every sales channel it is published to, so it can be sitting in a Google or Meta feed within the hour, and no undo button pulls it back out. Collection membership behaves the same way when the collection feeds a channel or an email segment.
The second thing we look at is whether Shopify keeps a before value for you. Theme work is low risk because you can duplicate the live theme and publish the copy back if it goes wrong. Prices and inventory have no history in the admin, so a bulk editor run across 400 products is genuinely one way unless somebody exported a CSV first. Our rule ended up being that any bulk edit touching more than roughly 20 records needs an export first, no matter how small the change is or who is doing it.
Operator role matters less for us than permissions do. Freelancers and client users get products and themes but not Settings, not payments, not shipping profiles, so the escalation is enforced by what the account can physically open rather than by a rule someone has to remember at 6pm on a Friday. The gap is apps. An app with write_products can do everything a senior operator can and it never asks anyone, so we review the scope list at install time and treat that as the real approval step.
On Plus you at least get a store activity log to reconstruct who did what afterwards. Below Plus that visibility is thin, which is another argument for pushing risk into permissions up front instead of into process.
For multiple clients, one default matrix plus a two or three line exceptions list per store worked far better than a matrix per client. Nobody reads a different SOP for every account.
How do you handle the app side of this? That is the actor a RACI never seems to cover.
Hey @CommerceGov, to build on lumine’s framework: our app rule is request-only installs, no agency-initiated installs on a client store without a specific ask, and we review the exact scope list shown at install (write_products, write_orders, etc). Anything touching orders or customer data gets the same sign-off as a Settings change. Worth knowing on that front: Shopify forces a fresh consent screen whenever an app’s scopes expand later, so scope creep after install isn’t a silent risk, you get a second checkpoint for free.
Adding to the who-can-publish part of your question: the org chart is not the full list of operators. Bulk editor runs, feeds, scheduled jobs and AI workflows all push changes to production, and none of them files for approval. In practice the riskiest publisher is usually one of those, not the junior freelancer.
We stopped tying rules to who makes the change and tied them to the cost of getting back instead. A typo is one edit to reverse, nobody should approve it. A price change across hundreds of products has no native history in the admin, so the approval step there is really the moment someone creates the way back: export the affected rows or take a snapshot, then publish. Once the way back exists, the 5% vs 30% distinction stops being interesting, both are one restore away.
So the matrix collapses to two tiers, not ten. Changes the platform can undo natively, like publishing a duplicated theme back, ship straight away. Everything else waits for a before-copy, no matter who or what is publishing.
Disclosure: I work on StoreVault, a backup and restore app for Shopify, which is how I ended up seeing the aftermath of no-way-back publishes weekly. The gate above works fine with a plain CSV export, no app needed.
We usually split it by reversibility, blast radius, and who can actually cause damage, not just by the label of the change.
A typo fix or a product description edit can usually go straight through if the person touching it is trusted, because it’s easy to spot and easy to roll back.
Price changes, product status, collection membership, and anything that affects a lot of SKUs are where I’d put a hard stop, because one bad click can change revenue and be pretty easy to miss.
I’d also treat SEO fields and metafields as approval-needed.
For role-based rules, I’d keep it simple: senior operator can publish low-risk edits, junior staff can draft but not publish on anything that changes price, visibility, or merchandising.