Giving Staff Access to WooCommerce Orders Without Making Them Admins
September 26, 2026

Giving Staff Access to WooCommerce Orders Without Making Them Admins
The day you stop packing every order yourself, you hit a question nobody warns you about. Someone needs to see the orders. WooCommerce has one obvious answer, which is to create a WordPress account for them. And that answer is larger than the question.
The person taping boxes needs to know what goes in the box. Everything else you hand over is surface you did not mean to give away.
What the built-in roles actually grant
WooCommerce ships with Shop Manager, and it is genuinely useful for a manager. It is a poor fit for a picker.
A Shop Manager reaches wp-admin. From there: every order with its full billing and shipping details, your entire customer list, the whole catalogue with cost-adjacent data like stock and pricing, coupons, and the reports that show your revenue. They can edit products, change prices, and modify customer records.
None of that is a bug. That is what the role is for. The problem is that "can see what to put in a box" and "can edit my prices and read my customer list" are the same checkbox.
Customer is the other extreme and covers nothing. Editor and Author are content roles that have nothing to do with orders. So merchants generally end up doing one of three things, and all three have a cost.
They create a Shop Manager anyway and rely on trust. Which is fine right up until the account is shared, reused on another site with the same password, or left active after the person leaves.
They install a role editor plugin and hand-carve a custom role. This works, and it is more fragile than it looks: capabilities interact, a WooCommerce or plugin update can add a capability your custom role silently inherits or lacks, and six months later nobody remembers exactly what that role was supposed to allow. Worse, it is hard to verify. You cannot easily prove what a role cannot do.
They share their own login. Extremely common, and it means the store's audit trail is a single name, and offboarding means changing your own password.
The four questions that actually decide this
Rather than comparing plugins, answer these.
Does this person need wp-admin at all? For picking, stock counts and customer service replies, usually not. If the answer is no, then every solution that starts by creating a WordPress user is solving the problem sideways.
What happens the day they leave? Seasonal staff leave. If offboarding means remembering to delete a WordPress account that has been dormant for four months, you will eventually have forgotten accounts with back-office access. Accounts that belong to the tool doing the job are easier to reason about, because there is only one place to look.
Can they see customer data they do not need? A picker needs an address on a label. They do not need the purchase history of every customer you have. This is not paranoia about your staff, it is data minimisation, and under GDPR it is the default position rather than an advanced one.
Would you notice a mistake? Not malice, a mistake. Someone clicking into a product to check a reference and saving a change without meaning to. The best protection is that the screen they use does not contain that button.
Separate accounts, separate surface
The approach that sidesteps most of this is to stop mapping warehouse roles onto WordPress roles.
If the picking tool has its own accounts, then the person who packs is not a user of your site. They cannot reach wp-admin because they have no WordPress identity at all. Their permissions are not capabilities layered onto a CMS, they are a short list of screens: picking, stock, after-sales, figures. You tick what they open.
It also makes the mental model honest. "Marie packs orders" becomes an account that can do exactly that, rather than a Shop Manager you are quietly hoping stays in her lane.
There is a real trade-off and it deserves saying plainly: a second account system is a second thing to secure. It has to rate-limit repeated login attempts, keep its session cookie on your own domain, and check permissions on the server for every request rather than hiding buttons in the interface. If you evaluate a tool in this category, those are the three things to ask about, and a vendor who answers vaguely is telling you something.
What this looks like in practice
Order Prep Pro takes this position: the people who pick have accounts that belong to the app, not to WordPress.
Each account opens only what you tick. Picking for whoever packs, after-sales for whoever answers customers, the figures for you. The licence covers the store, not the people, so you create as many accounts as you need instead of rationing them, which is what leads to shared logins in the first place.
The app is also installable on a phone from the browser, so onboarding someone means sending a link and creating an account, not enrolling a device or explaining what not to click in wp-admin. And each person picks their own language among 72, which matters more than it sounds when your team does not share a first language.
One detail worth knowing because it is where these systems usually leak: push notifications carry no order number and no customer name. The device is told that something is ready to pick, and the details only exist inside the app behind a login. A notification on a lock screen is visible to whoever is holding the phone, so the safe design is for it to say nothing useful.
The short version
Making someone an admin, or a Shop Manager, to let them pack boxes is the default because it is the only button WooCommerce offers. It is not the right size for the job.
Ask whether the task genuinely needs wp-admin. Most warehouse tasks do not. Then pick the tool whose permissions match the job rather than the tool that forces you to carve up a CMS role and hope.
If you are setting this up for a busy season rather than permanently, the offboarding question gets sharper, and we went into it separately in running a seasonal team without breaking your store.