Users and roles
This page explains the role model and the day-to-day user management admin tasks. For the side-by-side permissions matrix, see Roles & permissions.
The four roles
Section titled “The four roles”InPolicy has four roles. A user holds exactly one role on a tenant at a time:
Full control. Admins can manage every user, configure SSO, run directory imports, and view analytics. There’s no higher role — Admins can create other Admins.
Policy Lead
Section titled “Policy Lead”Owns a Division or set of Policy Areas. Leads can approve and publish policies, manage Policy Areas within their scope, and delete policies. They cannot manage users or configure SSO.
Policy Editor
Section titled “Policy Editor”Day-to-day author. Editors can create and edit policies (drafts or published) within their assigned Policy Areas. They cannot publish on their own — a Lead or Admin has to approve and flip the publish switch.
User (default)
Section titled “User (default)”Read-only. Users see published policies, get surfaced violations from the browser extension and Mac app, and can’t change anything in the platform. New invitees and newly-imported SSO users start as User unless explicitly assigned a higher role.
Where to manage users
Section titled “Where to manage users”From the top navigation, open Users. (The page lives at /users and requires the MANAGE_USERS permission — only Admin has it.)
The page shows a paginated list of every user in your tenant:
- Name and avatar
- Role (highest role they hold)
- Status:
ACTIVE,DEACTIVATED, orPENDING - Last login
You can filter by status, search by name or email, and sort by any column. Pagination defaults to 10 per page.
Inviting a user
Section titled “Inviting a user”See Invite users by email for the full flow. Short version:
- Users page → Add users → Invite tab.
- Enter one or more email addresses.
- (Optional) pre-assign a Role or Department.
- Click Send invitations.
Invitees get an email with a link that expires in 7 days.
Importing from SSO
Section titled “Importing from SSO”See Directory sync. Short version: once you’ve connected Google Workspace or Microsoft Entra, you can select users from the directory and import them — no per-user invite emails needed.
Changing a user’s role
Section titled “Changing a user’s role”- Click the user’s row to open the detail panel.
- Click Change role.
- Pick the new role.
- Confirm.
The change takes effect on the user’s next sign-in (or immediately if they’re currently signed in — their session picks up the new permissions at the next API call).
Deactivating vs. deleting
Section titled “Deactivating vs. deleting”Two distinct actions:
Deactivate
Section titled “Deactivate”- Reversible. Sets the user’s status to
DEACTIVATED. - The user can no longer sign in.
- Their data is retained — policies they authored, comments they left, revision history remains intact with their name attached.
- Use this for: employees on leave, contractors between gigs, anyone you might reinstate.
To deactivate: user row → Deactivate. To reactivate: same row, Reactivate.
Delete
Section titled “Delete”- Permanent. Anonymizes the user’s PII (name and email are scrubbed).
- Revision history, comments, and audit-log entries preserve a placeholder (“Deleted user”) where the person’s name was.
- Cannot be undone.
- Use this for: GDPR/CCPA erasure requests, former employees beyond your retention window.
To delete: user row → Delete. You’ll be asked to confirm with a typed confirmation.
Assigning users to Policy Areas
Section titled “Assigning users to Policy Areas”Policy Area-level role assignment is partially shipped. The UI shows an Assign role to policy area button on the Users page’s bulk action bar, but the modal currently shows a “coming soon” message. Full per-area role scoping is on the roadmap.
In the meantime, role assignment is tenant-wide. A Policy Editor can edit any Policy Area’s policies, not just a subset.
Who can see what
Section titled “Who can see what”| Admin | Policy Lead | Policy Editor | User | |
|---|---|---|---|---|
| See the Users page | ✓ | — | — | — |
| Invite users | ✓ | — | — | — |
| Change another user’s role | ✓ | — | — | — |
| Deactivate / delete a user | ✓ | — | — | — |
| Configure SSO | ✓ | — | — | — |
| Run a directory import | ✓ | — | — | — |
Only Admin touches user management. Policy Leads and below can’t promote themselves or each other.
Common gotchas
Section titled “Common gotchas”- SSO-imported users are created as
PENDINGuntil their first login. Once they sign in once, they move toACTIVE. - Email domains matter. A user invited with an email that doesn’t match any SSO-connected domain falls back to password-based auth. Decide in advance which sign-in method you want and be consistent.
- Deactivating doesn’t revoke their extension session instantly. The browser extension’s cached JWT lasts up to ~15 minutes after deactivation — after which refresh fails and they’re forced out.
- The
User.departmentfield is metadata, not enforcement. It’s shown in the UI and used for analytics grouping but doesn’t gate any permissions. Role-based permissions are what control access.