Account user roles explained: what admins, editors, and viewers can do

TL;DR — User roles are the rules that decide who can view data, change settings, manage billing, invite other people, or delete things in your account. The single most useful default is: give most people the lowest role that lets them do today's job, keep only 1-2 trusted people as full admins, and use a separate billing or owner-level role only when someone truly needs account-wide control. Reading time: ~7 min

What it is and where it sits

User roles are part of Identity & Access Management (IAM) (the system that decides who a person is and what they are allowed to do). In plain terms, a role is a bundle of permissions. Instead of individually ticking boxes like "can edit project" and "can invite users" for every person, the system usually gives them a named role such as Owner, Admin, Editor, Support, or Viewer.

In most customer-facing software, roles sit between:

• Authentication (proving who the person is when they sign in)
• Application features (projects, content, reports, billing, settings)
• Audit logs (records of who changed what)

A role system usually replaces a messier approach where every user gets custom one-off access. Custom access can be useful, but it becomes hard to review, easy to forget, and risky when staff change jobs.

A typical request flow looks like this:

[User Browser] ---- 1. sign in ----> [Login System]
[Login System] ---- 2. identity + role ----> [App]
[User Browser] ---- 3. click "Delete project" ----> [App]
[App] ---- 4. check permission for role ----> [Access Rules]
[Access Rules] ---- 5. allow or deny ----> [App]
[App] ---- 6. result + audit log ----> [Database]

What talks to it:

• The login system or identity provider (service that handles sign-in, password, SSO, or MFA)
• The application backend (server-side part of the app that enforces permissions)
• The database storing users, teams, roles, and audit history
• Sometimes a billing system, because billing access is often restricted separately from day-to-day work

Where it lives in a typical account:

• In your provider's dashboard, usually under a path like Settings → Team, Account → Users, Workspace → Members, or Security → Access
• In the backend database as a user-to-role mapping, such as "alex@example.com = editor"
• In the app's authorization checks, such as "only admins can change SSO settings"

The important point: a role is not just a label in the UI. The app should check that role every time someone tries to do something sensitive.

How it actually works

Let's walk through one realistic example: you want your marketing manager to update website content and view analytics, but not change billing, delete the workspace, or invite more admins.

Common role types

Names vary by provider, but these patterns are common:

• Owner: full control, often including billing, subscription, security, and account deletion
• Admin: broad operational control, often can manage users and settings, but may not own billing or legal/account closure actions
• Editor/Manager: can create and change day-to-day content or project data, but not account-wide security settings
• Viewer/Read-only: can see data but cannot change it
• Billing-only or Finance: can view invoices and payment methods without changing product settings

End-to-end example

You add Priya, your marketing manager, to your account as an Editor.

1. You open your provider's dashboard. The menu path is usually something like Settings → Users or Workspace → Members.
2. You click Invite user or Add member.
3. You enter priya@example.com.
4. In the role dropdown, you choose Editor.
5. Priya receives an email invite and signs in.
6. The app stores her identity and role, for example: user_id=123, role=editor.
7. Priya opens the content area and changes homepage text. The app checks: "Does editor have content:update?" If yes, it saves the change.
8. Later, Priya opens Billing. The app checks: "Does editor have billing:view or billing:update?" If no, it hides the page or shows an access denied message.
9. Priya tries Settings → Team → Invite member. The app checks whether editors can manage users. Usually the answer is no.
10. The app writes an audit log entry such as "Priya updated homepage content at 2026-10-30 14:03 UTC."

That is the practical mechanism: every sensitive action maps to a permission, and the role grants or denies that permission.

Why this matters for decisions

The biggest mistake customers make is treating "Admin" as the default. Admin often includes the power to:

• change security settings
• add or remove users
• reset integrations
• export sensitive data
• delete environments or projects

If someone only needs to edit content, run reports, or answer support tickets, they usually do not need admin.

When to use it (and when not to)

Use roles when more than one person touches the account, especially if those people have different responsibilities.

You probably do not need a complicated role design if your company has one trusted operator and everyone else never logs in. In that case, a simple split like Admin and Viewer may be enough.

Here is a practical decision table:

You probably don't need this if...

• only one person uses the account
• your provider only offers two roles and that is enough for your workflow
• you are trying to solve a people/process problem with permissions alone (for example, "we don't trust approvals")

Roles help reduce risk, but they do not replace internal process, approvals, or offboarding.

Trade-offs

Every role model is a trade.

A few honest cautions:

• Complexity: More roles are not automatically better. Five badly understood roles can be worse than three clear ones.
• Operational burden: Someone must own access reviews, especially after staff changes.
• Lock-in: Every provider names roles differently. "Admin" on one platform may be weaker or stronger than "Admin" on another.
• Security gaps: If the app only hides buttons but does not enforce checks on the backend, roles are cosmetic. Good systems enforce permissions server-side.

In practice

Below are examples you can adapt today. The first is what to look for in a dashboard. The second and third show how teams often represent roles in config or API payloads.

Example 1: API payload for inviting a user with a role

If your provider offers an API, the invite often looks like this:

{
  "email": "priya@example.com",
  "role": "editor",
  "send_invite": true
}

This creates an invitation for a user with the editor role. Gotcha: role names are provider-specific, so editor might be called member, contributor, or manager in your system.

Example 2: Access policy map used by an application

A backend service often keeps a permission map like this:

{
  "owner": ["billing:view", "billing:update", "users:invite", "users:remove", "settings:update", "project:delete"],
  "admin": ["users:invite", "users:remove", "settings:update", "project:delete"],
  "editor": ["content:create", "content:update", "report:view"],
  "viewer": ["report:view", "content:view"]
}

This shows the real meaning of each role: a list of allowed actions. Gotcha: if you add a new feature like integration:connect and forget to map it, users may get unexpected denials or accidental access.

Example 3: SQL query to review who currently has powerful roles

If your agency gives you database reporting access, a review query might look like this:

SELECT email, role, invited_at, last_login_at
FROM account_users
WHERE role IN ('owner', 'admin')
ORDER BY role, email;

This lists all users with high-privilege roles. Gotcha: do not edit production role data directly in SQL unless your provider or agency explicitly supports that workflow; use the dashboard first so audit logs and validation stay intact.

Practical dashboard checklist

In your provider's dashboard, go to the equivalent of Settings → Users / Members / Team and do these actions:

1. List every user.
2. Filter or scan for Owner and Admin roles.
3. For each person, ask: "Do they need to manage users, billing, security, or deletion?"
4. If not, change them to Editor or Viewer.
5. Open Billing and confirm only finance or owners can access it.
6. Open Security and confirm only trusted admins can change SSO, MFA policy, API keys, or domains.
7. Remove former staff and expired contractors.

⚠️ Changing roles can immediately block access to settings, integrations, or data exports. Before downgrading the last full admin, confirm that at least one trusted person still has enough access to recover the account.

A good operating pattern for most small and mid-sized teams is:

• 1 primary Owner
• 1 backup Admin
• staff as Editor or Viewer
• finance as Billing-only where supported
• contractors on the lowest role possible, removed when the work ends

Further reading

• NIST Role-Based Access Control (RBAC) Model
• OWASP Authorization Cheat Sheet
• The "Authentication" and "Permissions Policy" areas of the MDN Web Docs
• Google Cloud IAM documentation, especially the "Understanding roles" sections
• AWS IAM User Guide, especially "Policies and permissions"

This article was written by an AI system and published pending human review. Verify anything you intend to act on.