Shopify Admin Access: The Permissions Model Most Teams Get Wrong

Most Shopify merchants set up their team in the first week of launch and never touch the permission model again. A warehouse lead gets full admin because it was faster than figuring out the checkboxes. The freelance theme developer from two years ago still has a staff seat. The agency that redesigned the homepage in 2022 is still a collaborator, and nobody at the store remembers which agency it was. By the time the brand hits a million in annual revenue, there are eight to fifteen humans with some flavour of admin access, and at least half of them have permissions they never needed in the first place.

This is not a compliance problem until it is. The moment a customer complains that their personal data appeared in a spam campaign, or a discount code for ninety percent off floods a reseller channel, or a theme file shows up with a skimmer injected into checkout, the permission model becomes the first thing the investigation looks at. In almost every incident we see at WitsCode, the breach path was not a clever external attack. It was a legitimate login that had access it should not have had.

The three access tiers, and why the distinction matters

Shopify's access model has three tiers that look similar in the admin UI but behave very differently in terms of liability, billing, and revocation.

The store owner is a single account, bound to the billing email, and cannot be added. Ownership is transferred, not assigned. The owner is the only account that can close the store, downgrade or upgrade the plan, transfer ownership, or see full billing history. On Shopify Plus, the organization owner sits above individual store owners and can manage identity across every store in the org. The practical consequence is that the owner account should never be a shared inbox, a personal Gmail used by a former founder, or an address nobody checks. If the owner email is compromised, every recovery path to the store flows through it.

Staff accounts are individual human users, invited by email, and each one consumes a seat on the plan. Basic and Shopify plans include five staff, Advanced includes fifteen, and Plus is effectively unlimited. Staff can be granted full permissions or scoped down to specific areas such as orders, products, customers, reports, themes, apps, or settings. Staff appear in the store's user list and must be removed manually when the person leaves. Their sessions invalidate within a few minutes of removal.

Collaborators are the tier almost nobody configures correctly. A collaborator is an agency, freelancer, or developer who accesses the store through the Shopify Partner program rather than a staff seat. Collaborator access does not count against the plan's staff limit, which is why Plus merchants with a dozen agencies still have their staff list under control. More importantly, collaborator access carries a different liability model. If an individual at the agency leaves, the agency removes them from their Partner org and the store owner does not have to do anything. If the whole agency relationship ends, one click in Settings under Users revokes every login from that agency at once. Compare that to staff seats, where each person has to be tracked and removed individually.

The collaborator request code flow nobody actually uses

Open the Shopify admin, go to Settings, then Users and permissions, then scroll to the Security section at the bottom. There is a setting called Collaborator request code. It has two states. The default on older stores is "Anyone can send a collaborator request," which means any Shopify Partner in the world who knows your store URL can send you a request to collaborate, and the only defence is whether you recognise the email and remember to deny it. The correct setting is "Only people with a collaborator request code can send a collaborator request." When you enable that, Shopify generates a four-digit code that only you can see.

From there, the flow works like this. You share the four-digit code with your agency contact through a channel you trust. The agency logs into partners.shopify.com, clicks Add store, enters your shop URL and the code, and then selects the specific permissions they need for the work. You receive an email saying the agency is requesting collaborator access with the listed permissions. You review the permissions and approve or deny. The agency never sees your staff list, never uses a staff seat, and can be removed with one click.

Merchants who skip this flow and add agencies as staff instead inherit two problems at once. The agency now counts against the plan's staff limit, which becomes expensive on Shopify or Advanced plans. And when the agency relationship ends, the merchant has to manually identify and remove every individual who ever worked on the account, including people who rotated off the project months earlier and whose logins are still active.

The only reason not to use collaborator access is if the person is genuinely part of the in-house team and will be logging in for years. Contractors, agencies, freelancers, and anyone billing hourly should always come in as a collaborator.

Permissions that leak money or data when handed out by default

Shopify's permission model has around forty individual flags, and most merchants never read through them. The assumption is that Shopify would not expose something dangerous by default, which is broadly true, but several flags are individually capable of significant damage if given to the wrong person.

Customer data export is the one that should make every merchant pause. Any staff member with customers permission can download a CSV of every customer in the store, including names, email addresses, physical addresses, phone numbers, and order history. Under GDPR in the EU, CCPA in California, and similar frameworks in the UK, India, and Australia, this CSV is personally identifiable information and the store is the data controller. If a junior marketing hire exports the file to build a lookalike audience in Klaviyo and drops it into a personal Google Drive, the store has technically breached its data protection obligations even though nothing malicious happened. We recommend gating customer export behind a specific named role, reviewed quarterly, rather than bundling it with general customer view permissions.

Gift card issue is a money-printing permission. Anyone with it can create a gift card for any amount, and the gift card can be redeemed at checkout for real product. There is rarely a legitimate reason for more than two or three trusted people to have this permission, and it should almost never be granted to external contractors.

Discount creation is a similar category. A staff member with discount management can create a 100% off code and ship themselves the entire catalogue, or share the code with a reseller for a fraction of its value. Even well-meaning staff sometimes create overly generous codes that leak onto coupon sites and get abused at scale. Scope this to a marketing lead, not every marketing assistant.

Theme code edit is the permission that matters most for checkout security. A staff member or collaborator with theme edit access can inject JavaScript into the storefront, and if they inject it in the right place, that JavaScript runs for every customer entering payment details on custom checkout extensions or on non-Plus stores that still use the legacy checkout. This is the primary vector for the Magecart-style skimmer attacks that plague ecommerce platforms. Theme code access should be limited to developers you actively work with, and should be revoked the day the project ships.

App install and uninstall is the quiet one. When a staff member installs an app, that app receives OAuth tokens scoped to whatever the app requested, which is often every read and write permission on orders, customers, and products. The app is now a persistent data exfiltration path that survives the staff member leaving the company, unless someone remembers to audit the app list. Every app install is effectively a permission grant to a third party, and the decision to install should sit with someone who understands that.

The over-permissioned staff seat problem

When we audit a store for the first time, we almost always find the same pattern. There is one human who is nominally the store owner, and every other staff account has the "Full permissions" toggle enabled because it was faster than deciding which boxes to tick. The warehouse coordinator, whose actual job is fulfilling orders, has the ability to publish theme changes, install apps, and export the entire customer list. The accountant, who logs in once a month to pull a revenue report, has permission to edit product pricing and rewrite the checkout flow.

The fix is not complicated in principle. Shopify lets you toggle individual permissions per staff member, and the right model is least privilege. Fulfilment staff need orders and products, nothing else. Accountants need reports and view-only orders. Marketing staff need products, customers (without export), discounts up to a certain scope, and marketing content. Theme developers need theme access and nothing touching customer data. Customer service agents need orders with edit and refund capability but should not see financial reports.

The reason this model is hard to maintain is not technical. It is that every permission change feels like friction in the moment. The way we handle it is to frame the quarterly review as a security exercise on behalf of the team, not a trust question about any individual, and to batch reductions so no single person feels singled out.

The audit log, and why you need one even on non-Plus plans

Shopify Plus merchants have an organization-level activity log covering user actions across every store in the org, with roughly ninety days of retention and API access for longer-term archival. On non-Plus plans, the native audit capability is thinner. You can click into an individual user in Settings and see their recent login activity with IP and location, but there is no comprehensive permissioned-action log exposed in the admin UI.

For non-Plus stores that care about audit trails, the practical options are Shopify Flow workflows that log sensitive events to Slack or email when they happen, or third-party apps such as Rewind or Ablestar that add an audit layer on top of the admin. We set up Flow notifications for the handful of events that usually matter: staff added or removed, app installed, theme published, bulk customer export, and gift card issued above a threshold.

The offboarding checklist to run every single time

The most expensive mistakes in admin permissions are not the initial grants. They are the access that never gets revoked when someone leaves. When a staff member departs, a contractor's engagement ends, or an agency is replaced, the following checklist should run within the same working day.

Remove the staff user from Settings under Users and permissions. This invalidates their active sessions within a few minutes and blocks future logins. For collaborators, go to the Collaborators tab and remove the agency there. If the person was the primary contact at a partner agency and you want to keep the agency itself, confirm with the agency that the specific individual has been removed from their Partner organization as well.

Review every app installed during their tenure. Go to the Apps section, sort or filter by install date, and identify any app they installed. Apps frequently ship with OAuth connections under whoever pressed the install button, meaning the departing person's Google account, Klaviyo account, or Meta Business account might still be the authorizing identity behind integrations that look institutional. Disconnect and reconnect those integrations under shared company accounts, or uninstall the app if it is no longer in use.

Rotate custom app API credentials the person had access to. In the Apps section, under Develop apps, every custom app has an Admin API access token and, if you run custom integrations, webhook signing secrets. Regenerate these from the app's API credentials page. Any external system that authenticates with the old token will break until you paste in the new one, which is a feature, not a bug. It forces you to inventory which systems were using the credentials.

Audit Shopify Flow workflows for ones the departed person authored. Some workflows route order data to external webhooks, push customer data into Slack channels, or trigger emails from the store's domain. Pause anything the person created until you have confirmed it should still be running.

Pull recent login activity for that user for the preceding thirty days. Look for logins from unexpected countries, late-night access, and large export events. If anything looks wrong, assume credential compromise and treat it as an incident.

Rotate the storefront password if the person had access to password-protected staging environments. Update the two-factor recovery contact on the store owner account if it was their phone or email. Remove them from any connected Google or Meta ad accounts linked through Shopify's marketing channels. If they were a bank-authorised signer on Shopify Payments, notify the payments team. If they were the registrant on a connected domain, transfer it before their email goes offline.

None of these steps are individually hard. The reason they fail is that they need to run as a checklist, not as isolated decisions made days apart by different people. We maintain a shared offboarding runbook for every merchant we work with, and the offboarding is not considered complete until every line is checked off by a named person.

Where WitsCode comes in

We run an access hygiene audit for Shopify merchants, and we offer it as a one-off deliverable for stores that want a baseline before a larger engagement. The audit covers every human and collaborator with access, their current permission set, their last login, the apps they installed, and a recommended minimum permission set based on their actual role. We also ship a tailored offboarding runbook and a quarterly review cadence so the model does not drift back to defaults six months later. If the current list of who has access to your store would take you more than ten minutes to produce from memory, that is the signal to run the audit.

> Ask us for the access hygiene audit and we will return a prioritized remediation list within one business week.