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 first determines whether the action is scoped to a specific project.
**Actions that target a project** (for example, editing a feature flag that belongs to a project) are evaluated using project-specific roles:
* If a project-specific role applies (the user's own, or one from any team they're on), only project-specific roles are used for that project; the global role is ignored. The effective permissions are the union of those project-specific roles (the user gets a permission if any of them grants it).
* Otherwise, the global role applies - itself the union of the user's global role and the global roles of any teams they're on.
Because the global role is ignored whenever a project-specific role applies, a project-specific role can *reduce* access below the global role. For example, a user whose global role is `Engineer` but who has a `Read Only` role on a project is read-only on that project.
**Actions that are not scoped to a project** are evaluated against the global role. This includes organization-level settings and resources that always live at the org level, such as `Dimensions`, `Namespaces`, and `Presentations`.
For organizations without a Pro or Enterprise account, permissions are evaluated solely against the global role.
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 | Project Admin | Admin |
| :-------------------------: | :-------: | :-----------: | :---------------------: | :----------------------------------: | :---------------------------------------------------: | :---------------------------------------------------: | :---------------------------------------------------: | :---------------------------------------------------: |
| Feature Flags | - | View | View