User roles & permissions
Two roles — admin and editor — and an optional per-editor allow-list restricting which collections they can touch. Enough for a small team without a full permissions matrix to configure.
Where to find it
Users in the sidebar, visible to admins only.
Roles
| Role | Can do |
|---|---|
| admin | Everything — users, settings, API keys, schema changes, every collection, every entry status including drafts. Always unrestricted; you can't limit an admin's collection access. |
| reviewer | Like an editor, but can always publish and schedule — also while the review workflow is on. Also subject to the per-collection allow-list. |
| editor | Content work — create/edit/publish entries in whichever collections they're allowed to see. No access to Users, Settings, or schema structure changes. |
Change a user's role from the dropdown in the Users list (editor, reviewer, admin).
Review workflow
Turn on Settings → API → Review before publishing. From then on, editors can't publish or schedule: the editor offers Submit for review instead, and the entry gets the status In review (not public, like a draft). Admins and reviewers see Approve & publish and Request changes (sends it back to draft). The Entries list has an In review filter, the sidebar tooltips count them, and the activity log records submitted for review, approved and changes requested.
- The rule is enforced on the server for every route that publishes (editor, status buttons, bulk publish, scheduling, CSV import) — not just hidden in the UI.
- An
in_reviewwebhook event (review) fires on submission, and, if "notify on publish" email is configured, the notification address gets a "review requested" mail. - Limit: the gate controls moving an entry into published/scheduled. An editor can still edit an entry that is already live (it stays live). Restrict collections per editor if that isn't what you want.
Restricting an editor to specific collections
Click Collections next to an editor to open the permissions modal: a checkbox per collection. Leave everything checked (or don't touch it at all) and that editor is unrestricted — the default for a new editor account. Uncheck some and they lose access to exactly those collections: list views, entries, drafts, exports, all of it.
What "no access" actually means
An editor without access to a collection gets a 403 from every entry-level route for it — list, read, write, delete, comments, edit-locks, singleton pages, the terminal/CSV export, search and the dashboard's recent-entries and calendar widgets. Drafts and unpublished content in a restricted collection don't leak through any of those surfaces, not just the obvious "Entries" page.