WordPress editorial workflow for a comms team of twelve: the setup that actually ships
I once watched a restaurant owner delete his entire content archive in about ninety seconds.
He wasn’t reckless. He was tidying. He had a draft open that he’d decided against, and he wanted it gone, so he started clicking “Move to Trash.” What he didn’t understand was that “Move to Trash” wasn’t scoped to the thing in front of him. It was the same button that sat next to every published post on the site. Dozens of live posts went into the bin one by one: menus, event notices, the writeups he’d paid someone to produce. He kept going, because from where he sat he was cleaning up. Nothing on screen told him otherwise.
That was my fault. I’d given him one login, a single account with the keys to everything, because he was the owner and it seemed obvious that the owner should be able to do anything. The lesson cost him an afternoon of recovery and cost me a long drive home thinking about it.
Since then, every client I finish a build for gets two logins. One is a full admin account, for the rare day they genuinely need it. The other is an everyday account, limited to the things they actually do: write, edit, upload a photo. They live in the everyday account. The admin account sits in a drawer. That single change has prevented every repeat of that afternoon.
That story is about one person. This post is about what happens when you have twelve. If you are a solo blogger, the two-account habit is a nice-to-have and you can stop reading here with my blessing. But if you are running communications for an organization with ten to fifteen people all publishing to the same WordPress site, every version of that restaurant owner’s mistake is now waiting to happen twelve times over, on content other people depend on. That is the problem worth your next ten minutes.
This is the WordPress Practice case for team permission maps. The setup below is for comms teams publishing on WordPress. Solo bloggers: the two-account habit above is your complete answer.
Why default WordPress roles fail at twelve people
WordPress ships with five built-in roles (Administrator, Editor, Author, Contributor, Subscriber). People hear that and assume the work of setting up a team is mostly done. It isn’t, and here is the failure I see in practice.
Administrator gets handed out because it is the path of least resistance. Someone needs to do a thing, the thing is blocked, and the fastest way to unblock them is to make them an Administrator. Do that a few times across a year of small favours and you end up with eight people who can install plugins, change site settings, and delete every other person’s work. Most of them only ever needed to write and publish their own posts.
The opposite failure is just as common. Someone gets made an Editor because Editor sounds senior, and then they hit a wall on a task Editors cannot do, and now they are frustrated and convinced the website is broken. The site is doing exactly what its permissions say. The setup is wrong, and the setup is making the software look like the problem.
Too much access and too little: both feel like the CMS letting the team down, when almost every time it is the permissions map doing the letting down and the CMS taking the blame.
The two-account principle, scaled to a team
The fix I built for one restaurant owner scales up cleanly. Here is the shape of it for a comms team.
Everyone gets an everyday account limited to their daily work in the CMS. That is where the whole team lives, all day, every day.
Then two or three designated people also hold a separate admin account. They use it only for admin work: installing a plugin, changing a site setting, that sort of thing. They do not write posts from it. They do not check the site from it. When the admin work is done, they log out of it and go back to their everyday account like everyone else.
The point of the separation is what happens on a bad day. When someone clicks the wrong button in a tired moment, you want that to happen from a limited account that can only affect their own corner of the site. You do not want it to happen from an account that can take down the whole thing. The restaurant owner’s afternoon was survivable. With twelve people and a shared publishing history, the same mistake is not.
A role map written down nowhere is a role map that lasts until the person who set it up leaves.
A starting role map
When a client asks me what this looks like in practice, I give them something close to this. Treat it as a starting shape rather than a commandment.
| Role | What it can do | Who it fits |
|---|---|---|
| Contributor | Draft, but not publish | Freelancers, interns, anyone whose work should pass through another set of eyes before it goes live |
| Author | Publish their own posts, and nobody else’s | Staff you trust with their own beat |
| Editor | Publish and edit everyone’s content | The working level for most of a comms team: the people who run the publishing day |
| Publisher (custom role) | A narrower form of editorial control for scheduling and final approval | The one or two people who own the “is this ready to go” decision. Not in WordPress by default |
| Admin account | Infrastructure only, never writing | Two or three people. This is the drawer |
You can rename these, merge a couple, or add one to fit how your team actually works. What you cannot do and still call it a role map is give everyone Administrator. That is the absence of a role map, dressed up as convenience.
The workflow that survives turnover
A role map written down nowhere is a role map that lasts until the person who set it up leaves. The configuration is the easy part. The thing I actually deliver, the part that earns its keep over time, is the documentation around it.
That means a one-page document for each role: their account’s permissions in plain terms, and what to do when they hit a wall. That last line matters more than it looks. “Contact the admin” is a real instruction. “Click around until something works” is how the restaurant owner’s afternoon started.
It means an onboarding checklist. New staff member gets their account, reads their one-pager, does one supervised task, and signs off that they have done it. Fifteen minutes that saves a recovery job later.
And it means a calendar reminder, quarterly, to ask one question: are the right people still in the right roles? People leave. The junior who was bumped to Administrator for a one-off project two years ago has since moved on, and their account is still sitting there with full access. That is not a hypothetical. That is a security gap with a name on it.
The plugin is secondary to all of this. The documentation is the workflow, and the plugin just enforces it.
Plugins that help, and the kind to avoid
When a team needs a genuine approval flow (draft goes to an editor, editor signs off, then it publishes), PublishPress is the tool I reach for. For mapping custom capabilities onto roles, the Members plugin or User Role Editor do the job without fuss.
The plugins I steer teams away from are the all-in-one suites that try to own every part of the publishing process inside a single sprawling dashboard. They demo beautifully. The trouble shows up in eighteen months, when the person who understood how it all fit together takes another job and leaves behind a black box nobody else can read. The whole reason you are documenting roles is so the next person can pick up the system on their second day. A plugin that only its installer understands works against that goal.
A note for Canadian organizations
If your WordPress site collects anything personal (newsletter signups, contact form submissions, subscriber lists), then who can see that data is no longer just a tidiness question. Provincial privacy regulators, including the Information and Privacy Commissioner of Ontario, work from a least-privilege starting point: staff should have access to personal information only when their job actually requires it. The two-account principle and a real role map are how you meet that obligation in practice. It is the same instinct that fixed the restaurant, applied to your compliance posture instead of your archive.
When teams call me
The comms teams that reach out after their own version of the restaurant afternoon almost always say the same thing once we have fixed it: they are surprised the answer was sitting inside WordPress the whole time. They had assumed they had a platform problem and started pricing migrations. In nearly every case the platform was fine. It was waiting for someone to tell it who was allowed to do what. Drawing that map is where an audit of a shared site usually starts.