Reviewed November 9, 2026
Staff Permissions: The Five Roles That Keep a New Hire From Refunding the Store
Grant permissions by job, not by person. A fulfillment hire needs orders and inventory, not refunds or discounts. A support hire needs orders and refunds, capped by approval. A marketing hire needs discounts and products, not settings or payouts. The permission screen is where the line gets drawn, and the default of granting everything is how a new hire refunds the store by accident.
A new hire starts Monday. Someone grants them staff access, ticks the boxes quickly, and by Friday a customer has a refund the hire issued by mistake, or a discount code that was never approved is live on the store. Nobody acted maliciously. The permissions were just broader than the job.
Shopify separates permissions for a reason: orders, refunds, products, discounts, settings and payouts are different powers, and different jobs need different subsets. The setup takes ten minutes. The mistake it prevents takes weeks to untangle.
The five roles that cover most stores
Fulfillment needs orders and inventory, and nothing else. The hire can see orders, mark them fulfilled, print labels and adjust stock. They cannot refund, cannot create discounts, cannot touch settings. A fulfillment hire with refund access is a fulfillment hire who can undo the store's revenue, and there is no reason for them to have that power.
Support needs orders and refunds, with a limit. The support hire can look up an order, issue a refund, and answer the customer, but the refund limit should be set by policy, not by permission. Small refunds are theirs to issue. Large refunds go to a manager. The permission gives them the ability. The policy gives them the boundary.
Marketing needs discounts and products, not settings. The marketing hire can create a discount code, edit a product description, and publish a collection. They cannot change tax settings, payout details or staff permissions. A marketing hire with settings access is a marketing hire who can change the store's tax configuration while trying to fix a typo.
Finance needs payouts and reports, not products. The finance hire can see payouts, export reports and reconcile the books. They cannot edit products, issue refunds or change the theme. Separation of duties is not bureaucracy. It is the rule that the person who moves the money cannot also create the order that justifies moving it.
The owner keeps everything, and keeps the list short. Two people with full access is enough for most stores. Five people with full access is five people who can each break the store, and the audit trail will not tell you which one did it first.
The permissions that get forgotten
The refund permission is the one that gets granted by accident. It sits next to the orders permission, and a quick tick of the orders box often catches the refund box with it. Check it explicitly for every new hire, because the cost of the mistake is the refund itself, and the refund is real money out the door.
The discount permission is the second. A hire who can create discounts can create a 90% off code, and a code that leaks to a deal site will be used hundreds of times before anyone notices. Discount creation should belong to the people who run campaigns, not to everyone who works the store.
The settings permission is the third, and the most dangerous. Settings covers taxes, shipping zones, payment gateways and staff permissions themselves. A hire with settings access can grant themselves more access, change the tax configuration, or disable a payment gateway. Settings belongs to the owner and one trusted manager, nobody else.
Setting it up without the friction
Create the role before the hire starts, not after. Write down what each job needs, configure the permissions for the role, and grant the role on day one. A hire who starts with the right permissions never experiences the friction of asking for access, because the access they need is already there.
Review the list quarterly. People change jobs, and permissions do not change with them. A hire who moved from fulfillment to support still has the fulfillment permissions unless someone removes them, and a hire who left still has access unless someone removes the account. The quarterly review is the cleanup that prevents the accumulation.
Remove access the day someone leaves. Not the end of the week, not when someone remembers. The same day. A former employee with staff access is a security problem, and the cost of removing them late is the incident you will have to explain.
Related reading
For the background behind “Staff Permissions: The Five Roles That Keep a New Hire From Refunding the Store”, these earlier guides help: Shopify POS for a First Shop: Location, Device, and the PIN Problem, Shipping Zones and Rates: The Setup Most Stores Get Wrong, and Shopify Markets: One Store, Many Currencies, and the Settings That Decide.
Frequently asked questions
Can a staff member issue refunds without full admin access?
Yes, if the refund permission is granted. Refunds are a separate permission from orders, so a hire can have order access without refund access. Grant refunds only to the roles that need them, and set a policy limit on the size of refund a support hire can issue alone.
What happens if I grant all permissions to every hire?
Every hire can do everything, including refunding orders, creating discounts, changing tax settings and granting themselves more access. The store has no separation of duties, and a mistake by any one person can affect revenue, taxes or payouts. Grant by job, not by person.
How do I stop a former employee from accessing the store?
Remove their staff account the day they leave, from Settings, Users and permissions. Do not just change the password or remove their role. A deactivated account cannot log in, and the removal should happen the same day, not at the end of the week.
Should the marketing hire have access to settings?
No. Marketing needs discounts and products, not settings. Settings covers taxes, shipping zones, payment gateways and staff permissions. A hire with settings access can change the tax configuration or disable a payment gateway while trying to fix something else.