InPolicy has four roles. Every user has one tenant-wide base role. For Policy Lead and Policy Editor, admins can additionally scope that role to specific Policy Areas, so a person can be a Policy Editor in Compliance and a Policy Lead in HR simultaneously. Viewer is always tenant-wide (no per-area scoping needed for a read-only role).
For prose descriptions of each role, see Users and roles.
Scope vs. applicability. Per-area role scoping controls authoring — which areas a person can create and edit policies in. It does not decide which policies are checked against that person’s own writing. Every user, whatever their role or area assignments, is checked against all published policies in the tenant (minus any team-scoped policy for a team they’re not on). A Viewer with no area assignments is still fully covered.
| Role |
Short description |
| Admin |
Full platform control: users, SSO, analytics |
| Policy Lead |
Owns policy approval; publishes policies |
| Policy Editor |
Authors drafts within assigned areas |
| Viewer |
Read-only; sees published policies |
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| View published policies |
✓ |
✓ |
✓ |
✓ |
| View policy history |
✓ |
✓ |
✓ |
✓ |
| View policy rationale |
✓ |
✓ |
✓ |
✓ |
| View draft policies |
✓ |
✓ |
✓ |
— |
| Create a draft policy |
✓ |
✓ |
✓ |
— |
| Submit a draft for approval |
✓ |
✓ |
✓ |
— |
| Edit any policy |
✓ |
✓ |
✓ |
— |
| Approve and publish a policy |
✓ |
✓ |
— |
— |
| Delete a policy |
✓ |
✓ |
✓ |
— |
| Restore a previous revision |
✓ |
✓ |
✓ |
— |
| Use the Policy Inbox (AI imports) |
✓ |
✓ |
✓ |
— |
| Accept / dismiss Inbox suggestions |
✓ |
✓ |
✓ |
— |
Policy lifecycle — Policies move through: Draft → Pending Approval → Published. Only Policy Leads and Admins can approve and publish. Rejected drafts return to Draft status.
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| View comments |
✓ |
✓ |
✓ |
✓ |
| Post a comment |
✓ |
✓ |
✓ |
— |
| Reply to a comment |
✓ |
✓ |
✓ |
— |
| Mention another user |
✓ |
✓ |
✓ |
— |
| Resolve own comments |
✓ |
✓ |
✓ |
— |
| Resolve others’ comments |
✓ |
✓ |
— |
— |
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| Create a Division |
✓ |
— |
— |
— |
| Create a Policy Area |
✓ |
✓ |
— |
— |
| Edit a Policy Area |
✓ |
✓ |
— |
— |
| Delete a Policy Area |
✓ |
✓ |
— |
— |
| Reassign a policy to a different Area |
✓ |
✓ |
✓ |
— |
| Assign a user to a Policy Area |
✓ |
— |
— |
— |
Policy Lead and Policy Editor can be scoped to specific Policy Areas. A user can hold different roles in different areas — for example, Policy Editor in Compliance and Policy Lead in HR. Admins assign these area-level roles from the Users page.
- Admin and Viewer are always tenant-wide; per-area scoping does not apply.
- Policy Lead (area-scoped): can approve and publish policies only within their assigned areas.
- Policy Editor (area-scoped): can create, edit, and delete policies only within their assigned areas.
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| See the Users page |
✓ |
— |
— |
— |
| Invite users by email |
✓ |
— |
— |
— |
| Change another user’s role |
✓ |
— |
— |
— |
| Deactivate or delete a user |
✓ |
— |
— |
— |
| See pending invitations |
✓ |
— |
— |
— |
| Manage own profile (name, avatar) |
✓ |
✓ |
✓ |
✓ |
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| Connect a Google Workspace directory |
✓ |
— |
— |
— |
| Connect a Microsoft Entra directory |
✓ |
— |
— |
— |
| Run a directory import |
✓ |
— |
— |
— |
| Disconnect a directory |
✓ |
— |
— |
— |
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| View the Analytics dashboard |
✓ |
— |
— |
— |
| Export analytics as CSV |
✓ |
— |
— |
— |
| Action |
Admin |
Policy Lead |
Policy Editor |
Viewer |
| Sign in to the browser extension |
✓ |
✓ |
✓ |
✓ |
| Disable the extension for a site (for yourself) |
✓ |
✓ |
✓ |
✓ |
| Manage tenant-wide disabled sites |
✓ |
— |
— |
— |
The roles above are built from granular permissions. An individual role is a bundle of permissions; you don’t assign permissions directly. This table is for anyone curious about the internals.
| Permission |
Admin |
Policy Lead |
Policy Editor |
Viewer |
VIEW_POLICIES |
✓ |
✓ |
✓ |
✓ |
VIEW_POLICY_HISTORY |
✓ |
✓ |
✓ |
✓ |
VIEW_POLICY_RATIONALE |
✓ |
✓ |
✓ |
✓ |
CREATE_POLICIES |
✓ |
✓ |
✓ |
— |
EDIT_POLICIES |
✓ |
✓ |
✓ |
— |
APPROVE_POLICIES |
✓ |
✓ |
— |
— |
DELETE_POLICIES |
✓ |
✓ |
✓ |
— |
RESOLVE_POLICY_CONFLICTS |
✓ |
✓ |
— |
— |
MANAGE_DIVISIONS |
✓ |
✓ |
— |
— |
MANAGE_POLICY_AREAS |
✓ |
✓ |
✓¹ |
— |
MANAGE_USERS |
✓ |
— |
— |
— |
VIEW_ANALYTICS |
✓ |
— |
— |
— |
VIEW_AUDIT_LOGS |
✓ |
— |
— |
— |
¹ MANAGE_POLICY_AREAS for Policy Editor is scoped: it grants the ability to administer the specific areas the editor is already assigned to, not all areas on the tenant.
Permissions that come up regularly in support but aren’t shipped yet:
- “Suggest mode” — a role that can propose edits but not save them. Not on the roadmap. Use the comments system for the same purpose.
- Custom roles with hand-picked permissions. Today: four fixed roles. Talk to support if you need something different.
- Read-only “Auditor” role with analytics access. Today: analytics access is coupled to Admin.
