Org and team management runs on roles, not shared logins

Why content teams need role-based access

A shared login answers one question: can this person get in. It says nothing about what they should be able to do once inside. A writer who only needs to publish blog posts does not need the ability to delete the organization or rotate billing details. But without roles, every teammate gets that ability by default. The mismatch compounds fast once a team grows past three people, and faster still when the same headless CMS feeds several frontends with different owners.

The gap shows up at the identity layer too. A 2025 enterprise SaaS security report found 71% of CRM logins and 47% of file-sharing logins still happen without SSO. (Source: LayerX 2025 Enterprise AI and SaaS Data Security Report) That gap means access control often has to happen inside the app itself, since the identity layer alone is not enforcing it consistently.

Role separation is a market of its own, not a footnote to authentication. The global role-based access control market was valued at $8.3 billion in 2022. (Source) It is projected to reach $24.3 billion by 2032, an 11.8% CAGR. (Source) Teams are buying tools that treat roles as a first-class concept. A login screen with one admin checkbox no longer clears the bar.

Content teams feel this early. A marketing writer, a finance lead, and a founder all need the same org, but not the same actions. The writer publishes. The finance lead reads an invoice and never touches a template. The founder has to be able to remove either of them at 2pm on a bad Tuesday. One shared login collapses those needs into one account, so the org either over-grants access to stay practical or blocks people from doing their job.

Role-based access also changes what an incident looks like. Without roles, a compromised login is a full org compromise — content, members, and billing all at once. With roles, a compromised admin account still can't touch billing, and a compromised billing account still can't publish or delete content. The blast radius of one bad login shrinks to whatever that one role can reach.

Revisions already give teams a partial audit trail. Roles narrow it further, by limiting who could have caused a change at all. Chasing an unexpected edit? Everyone on a billing-only role is ruled out before you start.

Common CMS roles and what they do

Most content management systems ship the same five roles: administrator, editor, author, contributor, and subscriber. The names carry real meaning, and they're worth knowing before you map your own team onto whatever a given platform calls them.

The line that matters most sits between editor and author. An editor is the quality gate and can publish anyone's work. An author writes and ships their own and nothing else. Contributor is a step below that again: drafts go in, a human with publish rights takes them out. Subscriber is usually a reader account rather than a staff one, which is why it appears on a blog with member content and nowhere else.

This shape is WordPress's, and it spread because everything built after it copied the vocabulary. It also shows its age in three places. Billing isn't separated, so whoever pays the invoice needs an admin account. There's no environment scoping, so a staging change and a production change are the same permission. And owner and administrator are one role, which means an org can be left with nobody who can't be removed.

Draftbase splits it differently, and the mapping isn't one to one. Five org roles: owner, admin, editor, billing, and viewer. Editor covers entries and media, which is closer to the classic author-plus-publish than to the WordPress editor. Author and contributor have no direct equivalent, since Draftbase doesn't restrict an editor to their own entries. Billing and viewer exist because the two jobs the WordPress five can't express, paying and read-only review, come up on every team.

How Draftbase implements team management

Team management in Draftbase rests on two separate checks. A request is scoped to an org first, then checked against the role of the member making it. Neither check depends on the other. That independence is what keeps billing separate from content, and platform staff tooling out of the org-role system entirely.

What each role reaches, in one pass:

• Owner and admin reach everything an org has: template schemas, entries, media, members, API keys, webhooks, and org settings.
• Editor reaches content and nothing structural. Create, update, delete, publish, schedule, and roll back entries, plus media upload and tagging. Templates, members, and settings stay closed.
• Billing reaches billing endpoints only. No templates, no entries, no members.
• Viewer reads. Templates and entries are visible, every write is refused.

A membership can also be pinned to one environment. Leave it unset and the member works across every environment in the org. Set it to staging and that's the only one they can touch, which is how a contractor gets useful access without a path to production.

Org roles and platform staff access are enforced by two different checks. One reads a membership row scoped to the org in the request. The other reads a flag on the user account and never looks at org membership. The staff-only side also has no API-key fallback. The org-role check accepts a session or a management-scoped API key; the staff check accepts only a session. That's deliberate. Staff tooling should be reachable by a person in a browser, never by something running unattended.

How invites and role changes actually work

Inviting a teammate takes an email and a role: admin, editor, billing, or viewer. Owner is not an option on invite, since every org gets exactly one owner at creation and that assignment does not move through the invite flow.

No account on that email yet? The invite is stored as a pending membership keyed by the email instead of a user ID. It activates and picks up a real user ID the moment that person signs up or logs in with a matching address. So an invite can go out before an account exists.

This ordering matters for onboarding. A manager doesn't have to wait for a new hire's first login before granting access. The invite goes out the day the offer is signed, role already decided. The pending record sits inert until claimed, so it carries no access on its own.

Role changes go through the same members module, with one guardrail: the owner's role can never be changed through this endpoint. That keeps an org from being left without an owner by a routine permissions cleanup. Removing a member revokes their access going forward, but it does not touch what they already did. Entry revisions stay attributed to them, since revision history isn't tied to an active membership.

Team management approaches compared

These three approaches diverge at the edges. Someone leaves. Billing changes hands. Someone asks who published a given entry. A shared login has no answer to any of that, and a generic CMS answers it differently per vendor. Draftbase answers with the same mechanism it uses for every other request — org ID plus role.

None of these rows are theoretical for a growing team. Access boundary decides whether a departing contractor still has a working password. Billing separation decides whether a finance hire needs write access to content just to update a card. Audit trail decides whether a bad edit is a two-minute rollback or a guessing game about who touched what.

Invite flow matters more than a comparison chart makes it look. A vendor-dependent flow means onboarding behaves differently every time you evaluate a new CMS, and pre-account invites are hit or miss. A dedicated module defines that behavior once. It stays put as the team grows.

Permission best practices

Six rules that hold on any CMS, not only this one. They cost nothing to follow on day one and get expensive to retrofit at thirty people.

• Start from the minimum, then add. Grant the smallest role that lets someone do today's job and widen it when they hit a wall. Starting broad and trimming later never happens, because nothing breaks to remind you.
• Attach permissions to roles, not people. A per-person exception is invisible six months later. If two people need the same access, that's a role.
• Keep billing out of content. A finance hire should be able to read an invoice without being able to publish. Draftbase has a billing role for exactly this.
• One account per person. A shared login destroys the audit trail: every revision, invite, and agent tool call is then attributed to a password rather than a human.
• Review membership on team changes, not just departures. Somebody who moved from marketing to support keeps their old access until someone looks. Departures get handled; internal moves don't.
• Scope access per environment. If a role only needs staging, pin the membership to staging, so a mistake can't reach production content.

Three of these map to a setting rather than good intentions: the billing role, per-environment membership, and the org audit log, which is an Enterprise feature alongside SSO and IP allowlisting. The other three are habits, and no permissions model enforces a habit. A CMS can't stop four people sharing one editor login.

Common pitfalls in team access control

Teams often treat "who can log in" and "who can publish" as the same question. They are not. Authentication proves identity. Authorization decides what that identity can touch once inside. A 2025 enterprise SaaS security report found 47% of file-sharing logins still happen without SSO. (Source: LayerX 2025 Enterprise AI and SaaS Data Security Report) That gap shows identity checks alone are not filling the authorization role many teams assume they cover.

The second failure is under-using role separation. Everyone becomes an admin, because that's the path of least resistance. It quietly spends the audit and rollback value structured content already gives you. Entry revisions still show what changed and when. That record just means less when every account could have made the change, or deleted the org outright.

The fix for both is the same, and it needs no new tooling. Assign roles by what a person's job needs on day one, not by who asked first or who set up the org. Billing for people who touch invoices. Editor for people who write and publish. Admin only for people who also manage templates and members. Owner as a rarely-used safety valve, not a default for the whole founding team.

Worth calling out separately: none of this replaces SSO, and none of it should be read as an argument against it. Org roles decide what an authenticated person can do. SSO decides how confidently the system knows who that person is in the first place. Skipping SSO because roles exist just moves the weak point one layer up, from over-broad permissions to a login that's easier to phish or share.