Skip to content

Roles & permissions matrix

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.

RoleShort description
AdminFull platform control: users, SSO, analytics
Policy LeadOwns policy approval; publishes policies
Policy EditorAuthors drafts within assigned areas
ViewerRead-only; sees published policies
ActionAdminPolicy LeadPolicy EditorViewer
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.

ActionAdminPolicy LeadPolicy EditorViewer
View comments
Post a comment
Reply to a comment
Mention another user
Resolve own comments
Resolve others’ comments
ActionAdminPolicy LeadPolicy EditorViewer
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.
ActionAdminPolicy LeadPolicy EditorViewer
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)
ActionAdminPolicy LeadPolicy EditorViewer
Connect a Google Workspace directory
Connect a Microsoft Entra directory
Run a directory import
Disconnect a directory
ActionAdminPolicy LeadPolicy EditorViewer
View the Analytics dashboard
Export analytics as CSV
ActionAdminPolicy LeadPolicy EditorViewer
Sign in to the browser extension
Sign in to the Mac app
Disable the extension for a site (for yourself)
Pause the Mac app
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.

PermissionAdminPolicy LeadPolicy EditorViewer
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.