Roles & permissions
Scopingly separates who you are in an organization from what you can do to a specific document or PRD. Roles live at several independent scopes, and a user carries one value at each scope that applies to them. Understanding the scopes is the key to reasoning about access.
The scopes at a glance
| Scope | Roles | Decides |
|---|---|---|
| Organization | owner, admin, member | Org-wide administration, billing, users, settings |
| Platform | app admin | Cross-org platform operations (Scopingly staff) |
| Resource | owner, editor, viewer | Access to one document or PRD |
| Team | team owner, member | Curation authority over a team's PRDs |
Every user, team, document, and PRD belongs to exactly one organization, and data is always org-scoped — no organization can see another's content.
Organization roles
These are the roles most administrators think about.
- Owner — the org superuser. The person who signs up is the first owner. Can do everything an admin can, plus billing, trials, granting the owner role, archiving users, and deleting the organization.
- Admin — org administration: managing users, teams, settings, SSO, branding, templates, integrations, and reading the audit log. An admin cannot manage billing, trials, or delete the org.
- Member — the default authenticated user. No admin rights, but a member can still create documents and PRDs, generate scope, comment, and file change requests.
Owners and admins can act across the documents and PRDs in their own organization.
Owner vs admin
The distinction is deliberate: an admin runs day-to-day org operations, but irreversible or financial actions — billing changes, trial extensions, archiving users, and org deletion — are reserved for the owner.
The platform role: app admin
App admin is a Scopingly platform-staff role that operates across organizations. It is not something you assign to your own users.
App admins can see platform-level analytics (org, seat, and document counts; lapsed subscriptions) and perform platform operations such as approving a governed org-deletion request or toggling a custom-domain rollout. Critically, an app admin cannot read any organization's document or PRD content — platform operators are explicitly blocked from customer content.
Per-resource permissions
Access to an individual document or PRD is governed by a three-tier permission model, independent of your org role:
| Permission | Can |
|---|---|
| Owner | Everything: edit, manage collaborators, delete/archive, approve versions |
| Editor | Read and edit content, versions, milestones, gaps; generate scope |
| Viewer | Read only; may request edit access |
A viewer is never handed a private copy — they request edit access, and the resource owner (or an org admin) approves or denies it. See PRDs for the flow. Reviewers are a special case: a reviewer is a viewer-level collaborator pinned for sign-off — they can sign off on a version, which a plain viewer cannot.
Team ownership
A team has one or more team owners. Team ownership grants curation authority over the team's PRDs — a team owner can archive and unarchive the team's PRDs and grant team ownership to others — without needing org-wide admin rights.
Role management (RBAC)
Pro and aboveManaging organization roles — granting and changing members' roles — is a Pro and above feature. A single-seat Free organization has no roles to manage, so the controls are hidden there. See the feature comparison for what each plan unlocks.
TIP
Granting the owner role is reserved for an existing owner; admins can grant the admin and member roles but not owner.
Internal accounts vs client accounts
Scopingly's own model distinguishes internal employee accounts (Scopingly staff — with internal roles such as owner, sales, support, and engineer) from client accounts (external customer users). Internal capability flags govern whether staff may see billing or customer data; engineers, for example, have no access to either. As a customer, everyone in your organization is a client account with the organization and resource roles described above — the internal model is about how Scopingly staff are scoped, not your users.