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. Sees published policies, gets surfaced violations from the browser extension and Mac app, and can’t change anything in the platform itself. New invitees and SSO-imported users start here unless someone explicitly assigns them 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 sit at
PENDINGuntil they sign in once. First successful sign-in flips them toACTIVE. - Email domains matter. A user invited from a domain that isn’t on any SSO connection falls back to password-based auth. Pick the sign-in method you want before you start sending invites — mixing them is annoying to clean up later.
- Deactivating doesn’t kill the extension session instantly. The cached access token can stay valid for up to several days. The session ends on the next refresh, which the deactivated user’s account can no longer perform.
- The
User.departmentfield is metadata, not a permission. It shows up in the UI and analytics groupings but doesn’t gate access to anything. Role-based permissions are what actually control access.