Roles and Permissions
What each CMS account can do, and what to ask for when it can't
Every CMS account carries exactly one of three roles: admin, publisher or editor. The role decides which items appear in your sidebar and what a save is allowed to do. New accounts start as editors.
The three roles
| Role | What it covers | Who it fits |
|---|---|---|
| Editor | Creates and edits every kind of content, and saves drafts. No publishing, deleting or readiness sign-off. | Anyone writing content that somebody else reviews before it goes live |
| Publisher | Everything an editor does, plus publishing, deleting and the operational lists: Redirects and Form Submissions. | The person accountable for what's on the public site |
| Admin | Everything, plus Users, roles and Site Settings. | The few people who manage accounts and site-wide settings |
Hidden, not locked
A collection you can't use isn't grayed out. It's absent from the sidebar entirely, and there's no message explaining why. If a colleague describes a menu item you don't have, that's your role rather than a fault with the CMS or something you've broken.
Site Settings is the exception. It stays in the sidebar for everyone, and only an admin can save a change to it.
Capabilities by role
| Where | Editor | Publisher | Admin |
|---|---|---|---|
| Pages, Posts, Events, Campaigns | Create, edit, save drafts | Adds publish, delete | Same as publisher |
| Media, Dining Centers, Volunteer Roles, Affiliations | Create, edit, upload | Adds delete | Same as publisher |
| Navigation | Edit | Edit | Edit |
| Redirects | Hidden | Create, edit, delete | Same as publisher |
| Form Submissions | Hidden | Read, update, delete | Same as publisher |
| Users and roles | Own profile only | Own profile only | Full |
| Site Settings | Read-only | Read-only | Edit |
Deleting sits with publishers throughout, including media. An editor who needs a photo or a page removed asks a publisher.
The publish gate
An editor can open anything in the content list and save it. The block comes at the moment the save would put something new in front of the public, and it arrives as an error on the save rather than a disabled button:
Editors can save drafts; a publisher or admin publishes.
Pages, Posts, Events and Campaigns all work the same way. Saving a draft works whether or not a published version already exists.
An editor can take published content back to draft. Payload records "save a draft of this published document" and "unpublish it" identically, so a rule blocking that direction would block the one move editors exist to make. Deleting stays with publishers, and the published version stays in the version history, so an editor can take something down but can't lose it.
Pages also carry a Readiness field, which tracks editorial progress and never affects what's public. Editors can move it as far as Ready for review. Marking it Signed off is rejected with:
Only a publisher or admin can sign off readiness.
Readiness says how finished a page is. Status says whether visitors can see it. A page can be signed off and still unpublished.
Restricted fields
A handful of fields are restricted on their own, inside documents that publishers and editors can otherwise edit.
- Embed Code on the Donation Embed, Integration Embed and Newsletter blocks, and on the Blackbaud, Constant Contact and Double the Donation entries in Site Settings. These hold third-party code, so they sit with the developer rather than with admin. The rest of each block stays editable: a publisher can change the heading and surrounding copy without touching the vendor snippet.
- Role on a user account. Admins set roles; nobody can promote themselves.
WordPress roles
These names don't mean what they mean in WordPress.
- Editor is the furthest from its WordPress meaning. A WordPress Editor publishes anything on the site. An editor here publishes nothing, which puts them closer to a WordPress Contributor — minus the limit to their own posts, since an editor here can edit anyone's work.
- Publisher has no WordPress equivalent. It's roughly a WordPress Editor plus the redirects and form submissions, minus the settings.
- Admin is the closest match, and still narrower than a WordPress Administrator. There are no plugins, themes or user capabilities to configure.
Somebody described as an editor on the legacy site needs a publisher account here to do the same job.
The developer account
A fourth role sits above these three, held by whoever maintains the site. It adds a few controls that don't belong in everyday site management: embed code, environment configuration, diagnostics and audit trails. Everything needed to run the site sits with admin, so a full admin account can be handed over without handing over the controls that can break rendering.
Asking for more access
Roles are changed by an admin, in Users, on the account itself.
Ask for the role that matches the work rather than the title. Somebody who orders a mailer with a short address printed on it needs a publisher account, because that's where Redirects lives. Somebody who writes the news post and hands it off doesn't.
If you don't know who holds an admin account, ask the developer.
None of this is fixed
The three roles are a starting arrangement, chosen before anyone had used the CMS in anger. What each one reaches can be changed, and a new role can be added.
If the split turns out not to match how the team works — someone who should publish news but not pages, a role that handles redirects without being able to delete a page — that's a change to ask for rather than to work around. It's developer work rather than something an admin can do from Users, and it's usually small.
For what publishers do with the Redirects list, see Redirects.