Access control

Last updated:

|Edit this page|

PostHog's access control system allows you to manage permissions at three levels: organization, project, and resource. This hierarchical approach provides granular control over who can view and edit different parts of PostHog.

Levels of access control

1. Organization level

Organization members can have one of three access levels, which determine their permissions for organization-wide settings and actions.

The three access levels are: Member, Admin, and Owner. An organization must have at least one Owner but can have more than one.

PermissionMember (base level)AdminOwner
Viewing and querying project data
Accessing billing management
Managing reverse proxies
Creating and deleting projects
Managing project access controls (see more below)
Changing authentication settings (SAML, SSO settings, 2FA enforcement, etc.)
Changing organization settings (name, logo, etc.)
Managing RBAC Roles (creating, editing, deleting, changing members, etc.)
Inviting new members (only for current level or below)*
Managing members (changing roles, removing, etc.)
Leaving an organization
Transferring organization ownership
Deleting an organization

*This permission is configurable and can be disabled for members by organization admins and owners.

Access levels can be viewed and changed in the Members section of organization settings.

2. Project level

At the project level, there are two access levels: member and admin.

Each project has a default access level that applies to all organization members. The default access level can be one of these three options:

  • No access – Members need explicit permission to access the project
  • Member – All organization members have member-level access
  • Admin – All organization members have admin-level access

You can override the default access level for specific members or roles. A user's effective access level is the highest level granted from any source.

Organization owners and admins automatically receive project admin access.

Project access control

See the table below for a summary of project-level permissions:

PermissionMemberAdmin
Manage project access controls
Delete project
Edit project settings
View/edit own or permitted resources (based on resource-level access controls)
View/edit all resources (regardless of resource-level access controls)

3. Resource level

Resource access controls allow you to control who can view and edit specific resource objects. These can be accessed in the "Access control" sidebar when viewing a supported resource.

Currently, resource access controls are available for:

  • Insights
  • Dashboards
  • Notebooks
  • Feature flags
  • (more resource types coming soon – looking for others? Let us know!)

Note: We do not yet support limiting access to querying data, viewing replays, or accessing person / group profiles. Support for these features is planned for the near future.

Resource access controls have four possible access levels:

  • No access – Cannot view or edit the resource
  • Viewer – Can view but not modify the resource
  • Editor – Can view and modify the resource
  • Manager - Can change metadata about the resource like access controls

There are two ways to set resource-level access controls:

a. Individual resource object

These settings allow you to control who can view and edit a specific resource object. You can access these controls via the project's access control settings.

By default, new resources are set to "Editor" access. Users with appropriate permissions can modify this default and set specific permissions for members and roles.

Resource creators, project admins, and users with "Manager" access can always view and edit resources, as well as manage their access controls.

You cannot set resource-level access controls for project admins, as they always have full access.

Object access control

b. All resource objects of a given type in a project

These settings allow you to control who can view and edit all resources of a given type within a project. These controls are set at the project level.

You can set default access levels for all resources of a given type in a project. This allows you to set it once and apply it to all resources of that type in the project (past and future).

Individual resource object access controls for specific users or roles take precedence over resource-level access controls.

You cannot set resource-level access controls for project admins, as they always have full access.

Resource access control

How object-level access control precedence works

When determining what a user can access for a specific resource object, PostHog checks permissions in this order (highest priority first):

  1. Specific object permissions - Direct access granted to a specific resource object (e.g., Amy can edit Dashboard X)
  2. Resource type permissions - Access set for all resources of a type (e.g., Customer Support role can view all Notebooks)
  3. Default object permissions - Default access that applies to a resource object (e.g., Insight Y has view access by default)

Note: Resource creators and organization admins always have full access, regardless of these precedence rules.

Common use cases

Here are some practical examples of how to configure access controls for different scenarios:

Contractor with access to only one dashboard

Scenario: You want to give a contractor access to view only a specific dashboard without access to other project resources.

Setup:

  1. Set resource-level access controls to "No access" for all resource types for the contractor
  2. Give the contractor specific "Viewer" access to the desired dashboard
  3. The contractor will only see and access that specific dashboard

Country teams with role-based access

Scenario: You have teams organized by country and want each team to have edit access to their country's resources.

Setup:

  1. Create roles for each country team (e.g., "US Team", "UK Team")
  2. Add team members to their respective country roles
  3. Set resource-level access controls to "Viewer" for all resource types for each role
  4. Create country-specific dashboards and insights
  5. Assign each role "Editor" access to their country's resources

Private project for executives only

Scenario: You want to create a project that only executives can access.

Setup:

  1. Set project default access to "No access"
  2. Create an "Executives" role
  3. Add executives to the "Executives" role
  4. Give the "Executives" role "Admin" access to the project
  5. Only executives will have access to the project and its resources

Data scientist with limited access

Scenario: You want to give an analyst access to create and edit insights, but only view dashboards.

Setup:

  1. Set resource-level access controls to "No access" for all resource types for the analyst
  2. Give the analyst "Editor" access to all Insights (resource-level)
  3. Give the analyst "Viewer" access to all Dashboards (resource-level)
  4. The analyst can create and edit insights but only view dashboards

Feature availability

Free / Pay-as-you-go

These plans do not currently offer any access control features. All projects are open to all members and all resources are open to all members with "Editor" access.

Boost or Scale

The Boost and Scale add-ons include access controls for teams with stricter security requirements.

What you can do:

  • Set default access levels for projects and resources
  • Configure specific access levels for individual members (but not roles)

Enterprise

Note: While you can create roles on any plan, they can only be used for access control on Enterprise plans.

Enterprise plans include full access control capabilities with role-based access control (RBAC).

What you can do:

  • Create roles to group users together
  • Assign permissions to roles at both project and resource levels
  • Manage permissions at scale instead of individually
RBAC settings

Questions? Ask Max AI.

It's easier than reading through 717 pages of documentation

Community questions

Was this page useful?

Next article

Single sign-on authentication

SSO makes logging in easier for users to log and compliance easier for administrators. We also allow support just-in-time provisioning of users with our platform add-ons, which means that team members can self-serve creating their account, while still enforcing log in through a specified SSO provider. Some SSO features are add-ons. Please review each section below for details. Authentication domains SSO configuration mostly occurs in your Organization settings and is based on authentication…

Read next article