The Shopify permissions your SOPs should name

The short answer

Write the permission names. Shopify's store permissions are granular. Almost any procedure can name exactly what it needs. A procedure that says "needs admin access" instead does two harmful things at once. It fails to tell the reader what to request. And it tells whoever grants access that the safest move is to grant everything.

This matters most on the procedures where being wrong costs money. Those are also the ones most likely to be run by the newest person on the team.

A refund is three permissions

Take the most common procedure in a support team's library. Shopify does not have a refund permission. It has several. Which one you need depends on where the money is going.

So an agent who can refund to a card cannot necessarily issue store credit. An agent set up for both still cannot cancel an order unless somebody granted that separately. Shopify's refund documentation is explicit here. You need to be the store owner, or hold the Orders permission matching the payment method you are refunding to.

The over-refund case is worth knowing before you meet it. Say an order was already refunded to store credit. The customer now wants the money back on their card. Shopify locks the original payment method on the refund screen until somebody holds that optional permission. It also limits the whole manoeuvre to orders processed through Shopify Payments. An agent hitting a locked field with no idea why is the most common version of this problem.

Permissions that switch others on

Shopify resolves dependencies for you. That is convenient, and it is also how access quietly widens. When you assign a permission that requires others, the required ones are selected automatically. Deselect a required permission later and everything depending on it deselects too.

Five worth knowing, because each one grants more than the name suggests:

Selecting a category header is the bigger jump. Shopify notes that a top-level permission selects everything in that category. It also selects any required permissions in other categories. That is how someone set up to manage inventory ends up able to view products, files and rather more besides.

Some permissions are not required, but without them the task silently half-works. Shopify gives its own example. A blogger role has Themes and Blogs granted but no Files permissions. That user can pick existing images but cannot upload a new one. Nothing errors. The work just cannot be finished, and the person blames themselves.

What you cannot narrow

Store permissions work at the level of the whole store. Within one store you cannot restrict a user to particular orders, products or customers. However much your procedure would like you to.

Shopify names two exceptions to that, and both are worth knowing:

• App and channel permissions can be granted for specific apps and channels rather than all of them. If you tick specific ones, the user cannot install or delete apps, and any app you install later needs the role updated before they can reach it.
• Companies > Restrict permissions to assigned company locations, for B2B. This limits the admin to the Orders, Draft orders, Customers and Companies attached to the locations that user is assigned. Everything else in the admin stays unfiltered, and some totals such as amount spent still show the figure across all locations.

That second exception has a sharp edge for documentation. A B2B procedure written by someone with unrestricted access describes a different admin from the one its reader sees. The difference is invisible to the author. If a role is location-restricted, the procedure needs writing, or at least checking, by somebody holding that role.

The ones Shopify flags as sensitive

Shopify marks a handful of permissions as sensitive in its own documentation. Treat that label as a list. These are the permissions your SOP should require a named approver for, rather than something an owner grants in passing.

Customers > Erase personal data sits in the same family even without the label. A procedure touching any of these should name an approver in the document. Do not rely on the person remembering that this one feels like it needs a second pair of eyes.

POS is a separate system

If you sell in person, the permission you need is not in the list above. Shopify manages Point of Sale access through organization roles, not store permissions. A staff member fully set up for refunds in the admin may have no POS access at all.

Returns and refunds on the POS app need the Return and exchange orders permission. The in-store process is genuinely different from the admin one. A refund SOP that covers only the online path should say so in its first line. Otherwise a retail employee discovers the gap with a customer in front of them.

The prerequisite line

All of this collapses into one line at the top of a procedure. Name the permissions exactly as Shopify writes them. The reader is going to search the admin for that string.

For a refund procedure, the prerequisite line reads something like this. Requires Orders > View, Orders > Refund to original payment method, and Orders > Return. Add Orders > Refund to store credit if your policy allows it. Add Orders > Over-refund orders previously refunded to store credit only if agents handle that case rather than escalating it.

Three tests for whether the line is doing its job:

1. A new person can copy it into a message asking for access, and whoever grants it knows exactly what to tick.
2. Nothing in it says admin, full access, or the name of a person who has the right setup.
3. It names what happens when the access is missing, so somebody hitting a greyed-out button knows they have an access problem rather than a procedure problem.

That third test is the one people skip. It is also the one that saves an afternoon. A locked refund field and a broken procedure look identical from the outside.

The seven-day trap

One operational detail belongs in every onboarding procedure and appears in almost none of them. A Shopify invitation to create a staff login expires after seven days. Miss that window and there is no resend. You remove the user and add them again to generate a new invitation.

This catches teams who set up access a week before someone starts. That is otherwise exactly the right instinct. Note it in the procedure, and send the invitation close to the start date rather than as early as possible.

How this goes stale

Permission names are more stable than screenshots. That is the main argument for writing them down rather than photographing the screen. They are not fixed, though, and they change in a way that produces no error message anywhere.

Three triggers worth a review, none of them a calendar date:

• A permission you name stops existing or gets renamed. The prerequisite line becomes unsearchable, and the reader assumes they are looking in the wrong place.
• A role changes shape. Someone adds a permission to a role to unblock one task, and the documented prerequisite quietly understates what that role can now do.
• You start selling through a new surface. POS, B2B and app-specific access each sit outside the store permission list, so a procedure written for the admin alone is incomplete the day the new channel opens.

The cheapest check costs nothing. Have the next new starter follow the prerequisite line before they follow the procedure. If they can request access, get it granted, and reach the first step without asking a question, the line is correct. If they cannot, you have found the drift before it found a customer.

Start with the procedure that moves the most money. Open Shopify's permissions page beside it and work out what the task genuinely requires. Replace whatever the document says about access with the actual names. It takes about twenty minutes per procedure. It is also the only part of an SOP somebody can act on before reading the rest.