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

InPolicy has four roles. A user can hold more than one at once — most commonly via per-area scoping, where someone is Policy Editor in one area and Policy Lead in another. Where a user holds multiple roles, their effective permissions are the union of all of them (Admin and Viewer, the two tenant-wide roles, aren’t combined with per-area roles in practice — see below).

Admin

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

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

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.

Viewer (default)

Read-only. Sees published policies, gets surfaced violations from the browser extension, 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

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
• Email
• Role (highest role they hold)
• Status: ACTIVE, DEACTIVATED, or PENDING
• Last login

You can filter by status, search by name or email, and sort by any column. Pagination defaults to 10 per page.

Filter tabs

Four tabs filter the list by status, and together they account for every user in your tenant:

Tab	Shows
All	Every user except deleted ones
Pending	Invited or SSO-imported, not yet signed in
Active	Signed in and able to use the workspace
Deactivated	Access revoked, record retained

So All equals Pending + Active + Deactivated.

A fifth tab, Requests, sits alongside them but counts something different: people who have asked to join your workspace and don’t have accounts yet. See Join requests below.

Inviting a user

See Invite users by email for the full flow. Short version:

1. Users page → Add users → Invite tab.
2. Enter one or more email addresses.
3. (Optional) pre-assign a Role or Department.
4. Click Send invitations.

Invitees get an email with a link that expires in 7 days.

Join requests

Inviting is admin-initiated. A join request is the reverse: someone signs up with an email whose domain matches your workspace, and instead of getting an account they land in a queue for you to review on the Requests tab. Your admins are notified by email.

Each row gives you two actions:

• Approve — creates the user immediately as ACTIVE with the role you pick (Viewer by default). If they already had a pending invitation, that placeholder is filled in rather than duplicated.
• Reject — closes the request. No account is created.

Two things to know about the tab:

• Decided requests linger for 24 hours. The list shows everything still pending plus anything approved or rejected in the last day, so a request you just handled stays visible briefly before dropping off. The tab’s count only counts the pending ones, so the number and the visible rows can differ.
• Requests can be auto-approved. If your workspace has auto-approval enabled and unlimited seats, matching requests are approved on arrival as Viewer and never reach the tab. An empty Requests tab is expected on those workspaces.

Approving is blocked on the single-seat free plan — unlock unlimited seats first.

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

1. Click the user’s row to open the detail panel.
2. Click Change role.
3. Pick the new role.
4. 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

Two distinct actions:

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

• 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

Policy Lead and Policy Editor roles can be scoped to specific Policy Areas. On the Users page, select one or more users, click Assign role to policy area in the bulk action bar, pick the role (Policy Lead or Policy Editor), and choose the areas. Those users can then author only within the areas you selected — a person can hold different roles in different areas (Policy Editor in Compliance, Policy Lead in HR).

Admin and Viewer are always tenant-wide and take no per-area scope.

This scoping is about authoring — which areas someone can create and edit policies in. It does not affect which policies their own writing is checked against: every user is checked against all published tenant policies regardless of role or area assignment. See Roles & permissions.

Who can see what

	Admin	Policy Lead	Policy Editor	Viewer
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

• SSO-imported users sit at PENDING until they sign in once. First successful sign-in flips them to ACTIVE.
• 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.department field 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.

Related

• Invite users by email
• Single sign-on
• Directory sync
• Roles & permissions