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.
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 ad-hoc 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.