User & Team Permissions
In the context of GrowthBook, a user, or member, is an individual who has access to your organization's GrowthBook account. Each user is assigned a role that determines the level of access they have within the application. GrowthBook offers a range of roles, from No Access to Admin and even custom roles, each with a specific set of permissions (see below).
GrowthBook's user permissions system allows organizations to define the level of access each user has within the application. This granular control ensures that users can only access the resources they need to perform their job, enhancing security and privacy.
Adding Users
Team members can be added to your GrowthBook account via the Settings → Members page. From this main page, you'll see an "Invite Member" button on the right. If you do not see this button, you do not have permission to add members to your organization. Clicking on "Invite Member" will open a modal window from which you can choose some options for the new user.
Each GrowthBook user needs an email address, and you can select what global permissions you want to assign (See below for a full list of permission levels).
Inviting a new member to your organization will send an email to that user inviting them to join.
It is possible for a user to join more than one organization. If the user is a member to multiple organizations, they will see a drop-down next to their email address on the top right of the page, where they can select the organization they want to work in.
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.
Project Specific Permissions
Besides the global permissions, you can also assign project-specific permissions to users. This allows you to define a user's default role across all projects
and select per-project overrides. For example, a new user could be a collaborator by default for all projects, but on the mobile project, they could be an experimenter so they can manage all feature flags and experiments assigned to that project.
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.
Self-registering and Automatic Approvals
If users create an account with a verified email address that matches the domain of your account owner, they will be presented with an option to join your organization. If you have not selected Automatically approve new verified users (which is the default), those users will be listed at the bottom of the page under a section called Pending Members. From this list, you'll have the option of approving or deleting these self-registered users.
If you are the account owner, you will see a toggle at the top of the members' page that allows you to automatically approve new members who match your domain. This means that instead of being placed in your pending members list, they will automatically join your organization.
Removing Users
To remove a user from your organization, you can click on the three dots next to their name and select Remove User. This will remove the user from your organization and revoke their access to all projects and resources within your organization.
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.
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, Dimensions, Namespaces, and Presentations 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.
Custom roles
Enterprise organizations using GrowthBook also have the added flexibility of defining custom roles, which enable organizations to fine-tune a role's permissions. These custom roles can be used just like a standard role and can be applied to users and teams at both the global and project levels. A custom role can also be set as your organization's default role, so if you have auto-join enabled, new members will automatically receive the organization's default role, even if it is a custom role.
When creating a custom role, you can either create a role from scratch or duplicate an existing role and then update the role's description along with the policies, which control the role's permissions.
Once created, the name of a custom role cannot be changed. If you need to change the name, you will need to duplicate the role and set the new name before saving. Once saved, you'll need to update users to use this new role.
Policies & Permissions
When creating and editing custom roles, organizations have the ability to select specific policies for each role, where the policy contains the underlying permissions.
Below, we've outlined the current policies and their associated permissions. If your use case is not met with the current policies, please let us know by creating a Github Issue.
| Policy Group | Policy | Description | Permissions |
|---|---|---|---|
| Global | ReadData | View all resources - features, metrics, experiments, data sources, etc. | readData |
| Comments | Add comments to any resource | readData, addComments | |
| Features | FeaturesFullAccess | Create, edit, and delete feature flags | readData, manageFeatureDrafts, manageFeatures, manageArchetype, canReview, |
| ArchetypesFullAccess | Create, edit, and delete saved User Archetypes for feature flag debugging | readData, manageArchetype | |
| FeaturesBypassApprovals | Bypass required approval checks for feature flag changes | readData, manageFeatureDrafts, manageFeatures, canReview, bypassApprovalChecks | |
| Experiments | ExperimentsFullAccess | Create, edit, and delete experiments. Does not include Visual Editor access. | readData, createAnalyses, runQueries |
| VisualEditorFullAccess | Use the Visual Editor to implement experiment changes. | readData, manageVisualChanges | |
| superDeleteReports | Delete custom reports made by other users. Typically assigned to admins only. | readData, superDeleteReport | |
| Metrics & Data | DataSourcesFullAccess | Create, edit, and delete data sources | readData, createDatasources, editDatasourceSettings, runQueries |
| DataSourceConfiguration | Edit existing data source configuration settings (identifier types, experiment assignment queries) | readData, editDatasourceSettings, runQueries | |
| RunQueries | Execute queries against data sources. Required to refresh experiment results. | readData, runQueries | |
| MetricsFullAccess | Create, edit, and delete regular metrics (does not include Fact Metrics) | readData, createMetrics, runQueries | |
| FactTablesFullAccess | Create, edit, and delete fact tables, metrics, and filters. | readData, manageFactTables, manageFactMetrics, manageFactFilters, runQueries | |
| FactMetricsFullAccess | Create, edit, and delete fact metrics and filters. | readData, manageFactMetrics, manageFactFilters, runQueries | |
| DimensionsFullAccess | Create, edit, and delete dimensions | readData, createDimensions, runQueries | |
| SegmentsFullAccess | Create, edit, and delete segments | readData, createSegments, runQueries | |
| Management | IdeasFullAccess | Create, edit, and delete ideas | readData, createIdeas |
| PresentationsFullAccess | Create, edit, and delete presentations | readData, createPresentations | |
| SDK Configuration | SDKPayloadPublish | Make changes that affect data sent to SDKs. For example: edit a saved group, toggle a feature flag, stop an experiment, etc. | readData, publishFeatures, runExperiments |
| SDKConnectionsFullAccess | Create, edit, and delete SDK Connections | readData, manageSDKConnections, manageSDKWebhooks | |
| AttributesFullAccess | Create, edit, and delete targeting attributes | readData, manageTargetingAttributes | |
| EnvironmentsFullAccess | Create, edit, and delete environments | readData, manageEnvironments | |
| NamespacesFullAccess | Create, edit, and delete namespaces | readData, manageNamespaces | |
| SavedGroupsFullAccess | Create, edit, and delete saved groups | readData, manageSavedGroups | |
| Settings | GeneralSettingsFullAccess | Edit organization general settings | readData, organizationSettings |
| NorthStarMetricFullAccess | Configure North Star metrics | readData, manageNorthStarMetric | |
| TeamManagementFullAccess | Invite users, delete users, change user roles, add/remove users from teams. | readData, manageTeam | |
| CustomRolesFullAccess | Create, edit, and delete projects | readData, manageProjects | |
| ProjectsFullAccess | Create, edit, and delete tags | readData, manageTags | |
| TagsFullAccess | Create, edit, and delete API secret keys. Not required to create Personal Access Tokens. | readData, manageApiKeys | |
| APIKeysFullAccess | Set up and configure integrations - GitHub, Vercel, etc. | readData, manageIntegrations | |
| IntegrationsFullAccess | Create, edit, and delete event-based webhooks. Used for Slack/Discord notifications. | readData, manageEventWebhooks, viewAuditLog | |
| EventWebhooksFullAccess | View and edit license key. View invoices and update billing info. | readData, manageBilling | |
| BillingFullAccess | View and export audit logs | readData, viewAuditLog | |
| AuditLogsFullAccess | Create, edit, and delete custom roles | readData, manageTeam, manageCustomRoles |
Deactivating Roles
As we do not support the ability for an organization to delete a standard role, we have introduced the ability for enterprise organizations to deactivate both standard and custom roles. When a role is deactivated, we remove the role from the roles dropdown when adding a new user or updating an existing user's role. If you deactivate a role that is assigned to a user, the user will experience no changes to their permission level. The deactivation of the role simply removes it from the role options.
The only guardrail in place around deactivating roles is that you cannot deactivate your organization's default role.