Shopify collaborator access: what to ask before you say yes

Collaborator requests arrive with urgency: “just need access to fix the theme,” “agency needs Products and Apps,” “VA needs Orders.” Access is not a courtesy — it is a security and ops decision. Asking a short set of questions before you approve protects customers, payouts, and your future self.

This checklist works for Shopify collaborator codes and for staff accounts you create yourself.

Collaborator account or staff account?

Shopify gives you two ways to let someone else in. A staff account is one you create inside your own admin; it uses one of the staff seats on your plan and it is the right choice for employees and anyone you manage directly. A collaborator account is requested by a Shopify Partner (an agency, developer or freelancer with a Partner account) and does not use a staff seat; you approve the request from your admin, and you can require a collaborator request code so nobody can ask for access without you handing over the code first. Both kinds get the same granular permissions, and both can be removed in a minute. Turn the request code on today if it is not already on; it stops cold requests and makes every approval a deliberate decision.

Ask what problem they are solving

If the answer is vague (“improve the store”), pause. Good answers name a surface: homepage section, checkout upsell bug, Merchant Center feed mapping, Xero invoice mismatch, or a fulfilment workflow. Scope drives permissions. Unlimited admin “for convenience” is how audits start.

Ask which permissions — and for how long

Map requested permissions to the task. Theme work does not need Orders, Customers or Settings. Catalogue tidy-ups do not need Orders or the ability to change payments and shipping. An inventory helper does not need Themes, Settings or Customers. If a permission is not needed for the paragraph of scope you were given, leave it off; it can be added in a minute if a real need turns up.

Time-box access: two weeks for a project, ongoing for an operator retainer with a review date. Put the end date in the calendar when you approve the request.

Permissions mapped to common jobs

Job they are doing	Usually needs	Should not need
Theme or design work	Themes; online store pages, navigation and blog	Orders, Customers, Settings, installing apps
Catalogue tidy-up, product copy	Products, collections, files and media	Orders, Settings, Themes
Order and fulfilment help	Orders and draft orders; the locations they ship from	Refunds without a gate; Settings; payments
Marketing, email, feeds	Marketing, Discounts, and the specific app or sales channel	Customer exports unless the task needs them; Settings
Bookkeeping and reporting	Reports and analytics; view-only access to orders and payouts	Anything that edits the storefront; managing payments

Shopify’s permission list is granular enough that “a bit of everything” is never the right answer. If a request does not fit one row of this table, ask for the paragraph of scope first and build the permission list from that.

Ask who employs them and how you offboard

Is this a named person at an agency, a freelancer, or a marketplace VA account shared by a team? Shared logins are a red flag. You want a name, a company, and a single responsible email. Offboarding: who confirms when the project ends, and who removes the collaborator the same day?

For NZ and AU merchants hiring offshore help, also ask where work is done and whether screenshots of customer PII are stored. You remain accountable under NZ privacy expectations for customer data in your store.

Ask how changes will be proposed and approved

Anyone with Themes, Apps, Products, or Settings can change live buyer experience. Require a channel for proposals (email, ticket, shared doc) and a rule: no live push without written approval for material changes. That is the same gate Backroom Ops uses — propose → approve → execute + log.

If they use AI tooling inside the admin, the gate still applies. Tools draft; people approve.

Ask for a change log habit

Even a simple weekly note — what changed, where, why — beats archaeology in theme history six months later. For theme work, prefer development themes and preview links over editing the live theme directly.

Permissions that should almost always stay with you

• Manage payment settings / view payout details beyond what support needs
• Store ownership itself: only the owner can transfer it, so keep the owner login with you and protect it with two-step authentication
• Staff and collaborator management (or keep it dual-controlled)
• External payment provider API keys and bank logins (never share)

Operators and agencies who ask for less access are usually safer partners than those who ask for everything “to save time.”

If someone already has too much access

Most stores we look at have at least one account that should not be there: a developer from a theme project two years ago, a former staff member, a shared “admin@” login that three people know the password to. Fix it the same afternoon. Go through every staff and collaborator account, write one line next to each saying what it is for, and remove anyone without a line. For the ones who stay, cut permissions back to the table above. Turn on two-step authentication for every remaining login and require it for staff, and change the owner password if it was ever shared. Then set a calendar reminder to repeat the pass every quarter. None of this needs an app, and it is the best security return on an hour of your time that a store owner can get.

Before you paste the collaborator code

1. Problem and deliverable written in one paragraph
2. Permission list matched to that paragraph
3. End date or review date
4. Approval channel for live changes
5. Offboarding owner named

Related reading: how daily ops differ from agency builds in AI Shopify Operator vs VA vs Agency.

FAQ

If you want an operator who defaults to least privilege and approval gates, book a free diagnostic — we will tell you what access we actually need for your first week.