User & Team Permissions
Fine-tuning user permissions in an application like GrowthBook ensures a tailored experience, empowering organizations to grant precisely defined access levels. This granular control not only enhances security but also enables teams to collaborate efficiently while safeguarding sensitive features or data.
Organizations using GrowthBook have a number of different ways of defining a user's permission level, depending on the organization's plan.
Regardless of the plan, all organizations can assign a global role when inviting a user which defines their permissions across all projects. If you have a Pro or Enterprise account, you can also assign project-level roles for each user.
For example, you can assign a user the global role of Collaborator, allowing them to view features and experiments, add comments, and contribute ideas. You can then assign them an Experimenter role for a specific project, which allows them to create and run experiments, but only for that project.
And, for our Enterprise organizations, we offer the ability to create Teams, which are groups of users, all of which inherit the roles and permissions of the Team they're on.
The table below lists the roles available in GrowthBook and their associated permissions.
| No Access | Read Only | Collaborator | Engineer | Analyst | Experimenter | Admin | |
|---|---|---|---|---|---|---|---|
| Feature Flags | - | View | View Comment | View Comment Add Edit | View Comment | View Comment Add Edit | View Comment Add Edit |
| Experiments | - | View | View Comment | View Comment Edit | View Comment Add Edit Run Queries | View Comment Add Edit Run Queries | View Comment Add Edit Run Queries |
| Metrics | - | View | View | View | View Add Edit | View Add Edit | View Add Edit |
| Dimensions | - | View | View | View | View Add Edit | View Add Edit | View Add Edit |
| Segments | - | View | View | View | View Add Edit | View Add Edit | View Add Edit |
| Datasources | - | View | View | View | View Edit* | View Edit* | View Add Edit |
| Ideas | - | View | View Add Edit | View Add Edit | View Add Edit | View Add Edit | View Add Edit |
| SDK Connections | - | View Add | View Add | View Add Edit | View Add Edit | View Add Edit | View Add Edit |
| Attributes | - | View | View | View Add Edit | View | View Add Edit | View Add Edit |
| Namespaces | - | View | View | View Add Edit | View | View Add Edit | View Add Edit |
| Environments | - | View | View | View Add Edit | View | View Add Edit | View Add Edit |
| Saved Groups | - | View | View | View Add Edit | View | View Add Edit | View Add Edit |
| Tags | - | - | - | View Add Edit | View Add Edit | View Add Edit | View Add Edit |
| Slack Integration | - | - | - | - | - | - | View Add Edit |
| Manage Projects | - | - | - | - | - | - | Yes |
| Manage Team | - | - | - | - | - | - | Yes |
| Manage Plan | - | - | - | - | - | - | Yes |
| Manage Billing | - | - | - | - | - | - | Yes |
*Limited to editing a subset of data source settings - identifier types, experiment assignment queries, Jupyter Notebook queries and Data Pipeline settings. Editing datasource name, projects, description, and connection parameters requires Admin permissions.
Environment Specific Limits
GrowthBook's user permissions also include environment specific limits. This permission level applies only to Engineer and Experimenter roles in Pro or Enterprise accounts. It allows you to limit the feature flags and experiments a user can manage to specific environments. For example, you can allow an Engineer to create and run experiments in a staging environment, but not in production.
How permissions are evaluated
GrowthBook evaluates user permissions based on whether an action is taking place within a specific project. If so, project-level permissions are checked first, followed by the user's global role. If the action is not within a project, only the user's global role is checked.
For organizations without a Pro or Enterprise account, user permissions are evaluated solely based on their global role.
If your organization has enabled the setting to allow verified users to automatically join your organization, they will receive the Collaborator role by default when they join. However, you can change your organizations' default role at the bottom of the Team page.
How does the No Access role work?
The No Access role is available to organizations enrolled in an Enterprise plan.
In some cases, an organization might want to hide certain projects from a user entirely. This is possible with the No Access role. The No Access role can either be applied as the user's global role, or it can be a project-specific role.
In the event you want a user to have access to a subset of projects, you can give them a global role of No Access and then give project-specific permissions for the projects you want them to be able to view.
If, however, you only want to hide a certain project from a user, you can assign their project-level role of No Access which will make it so the user isn't able to view the project.
If you need to apply these rules to many users as once, you can create a Team with the permissions needed, and then add users to that team. But, keep in mind, the user's permissions will be a combination of their user permissions, and the permissions of any team their on, so after adding the user to a team, you may want to reduce their user-level permissions to ensure their previous user-level permissions don't override the permissions inherited by the team(s) they're on.
Within GrowthBook, not all resources are project-specific. For example, Saved Groups, Dimensions, Segments, Namespaces, Environments, Presentations, and Ideas all live at the organization level. This means that all users, regardless of role, will be able to view these resources.
If security of these resources is paramount to your organization, we recommend creating a separate organization, and keeping the resources you want to hide in that organization.
Teams
Enterprise organizations using GrowthBook can create Teams with distinct capabilities. When setting up a Team, you have the option to define both a global role and project-level roles, much like how you do for individual users. Once a Team is established, multiple users can be added to it. Any user added to a Team will automatically inherit all permissions assigned to that Team. This feature becomes particularly useful when combined with GrowthBook's SCIM integration, enabling automated user provisioning and de-provisioning.
To create a Team, you can go to Settings → Team via the Sidebar and then select the Teams tab at the top of the page. Here, you can create and configure various Teams, before adding members to a Team. When evaluating whether or not a user has permission to perform a certain action, we will merge the user's permissions with the permissions inherited from all the Teams the user is on. So if the user's global role is Collaborator but they're on a Team that grants them Engineer permissions, that user's permission will then be a merger of the Collaborator and Engineer roles.