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.
Permission | Member (base level) | Admin | Owner |
---|---|---|---|
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.


See the table below for a summary of project-level permissions:
Permission | Member | Admin |
---|---|---|
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.


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.


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):
- Specific object permissions - Direct access granted to a specific resource object (e.g., Amy can edit Dashboard X)
- Resource type permissions - Access set for all resources of a type (e.g., Customer Support role can view all Notebooks)
- 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:
- Set resource-level access controls to "No access" for all resource types for the contractor
- Give the contractor specific "Viewer" access to the desired dashboard
- 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:
- Create roles for each country team (e.g., "US Team", "UK Team")
- Add team members to their respective country roles
- Set resource-level access controls to "Viewer" for all resource types for each role
- Create country-specific dashboards and insights
- 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:
- Set project default access to "No access"
- Create an "Executives" role
- Add executives to the "Executives" role
- Give the "Executives" role "Admin" access to the project
- 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:
- Set resource-level access controls to "No access" for all resource types for the analyst
- Give the analyst "Editor" access to all Insights (resource-level)
- Give the analyst "Viewer" access to all Dashboards (resource-level)
- 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

