Skip to content
InPolicyInPolicy Docs

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:

Admin

Section titled “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

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.

Viewer (default)

Section titled “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

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
  • 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.

Inviting a user

Section titled “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.

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”
  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

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 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

Section titled “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

Section titled “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.
Section titled “Related”