Invite collaborators
How to invite collaborators to your Optimizely Feature Experimentation release project to let your team manage feature flags and experiments.
Invite collaborators to your Optimizely Feature Experimentation project to let your team manage flags and experiments. The number of collaborators is limited to your Optimizely Feature Experimentation plan. View the plans & pricing page on Optimizely.com for more information and current collaborator limits.
Collaborators
Collaborators are users that:
- Log into the Optimizely application.
- Utilizes an Optimizely Feature Experimentation API where authentication is required.
- Somehow interact with an Optimizely interface, either by logging in or through an API.
On the other hand, there may be additional people involved in a project who are not considered collaborators in Optimizely Feature Experimentation. For example, a developer who maintains Optimizely code in their code base and does not use any Optimizely Feature Experimentation credentials is not considered a collaborator.
Invite collaborators

- Go to Settings > Collaborators.
- Select Invite a Collaborator.
- Enter the email addresses of your collaborators, and select their permission levels. You can also invite collaborators to multiple projects at once.

Permissions
Here is the matrix of permissions for each collaborator type. Each role includes the permissions for the one before it. To summarize:
- Viewers have read-only access and cannot modify flags or rules.
- Editors and Restricted Editors can set up flags and rules in restricted environments, like local or staging environments, but cannot launch flag rules in non-restricted environments like production (you can customize this with restricted environments). If a rule is running in a restricted environment, an Editor can change only the traffic allocation or whether a flag is enabled or disabled.
- Publishers and Restricted Publishers can launch flag rules in production.
- Administrators have full permissions to manage account settings
Actions | Viewer | Editor | Publisher | Project Owner | Administrator |
---|---|---|---|---|---|
Experiments (create, edit, start, pause, archive) | No | Yes * | Yes | Yes | Yes |
Variations (create, edit, re-allocate traffic, pause, delete) | No | Yes * | Yes | Yes | Yes |
Flags (create, edit, archive) | No | Yes * | Yes | Yes | Yes |
Variable keys (create, edit, delete) | No | Yes * | Yes | Yes | Yes |
Traffic allocation (edit) | No | Yes * | Yes | Yes | Yes |
Events (create, edit, archive) | No | No | Yes | Yes | Yes |
Audiences (create, edit, archive) | No | Yes | Yes | Yes | Yes |
Add specific users (add users, edit, delete) | No | Yes * | Yes | Yes | Yes |
Attributes (create, edit, archive) | No | Yes | Yes | Yes | Yes |
Collaborators (invite, edit, delete) | No | No | No | Yes | Yes |
Environments (create, edit, archive) | No | No | No | Yes | Yes |
Webhooks (create, delete) | No | No | No | Yes | Yes |
Integrations (create, edit, delete) | No | No | No | Yes | Yes |
Reset results | No | No | Yes | Yes | Yes |
Mutual exclusion groups (create, edit, delete) | No | Yes | Yes | Yes | Yes |
*** In restricted environments, Editors and Restricted Editors can create flags and flag rules but cannot launch, pause or change traffic allocation. In non-restricted environments, those Editors and Restricted Editors have full access to all aspects of flags and experiments. We recommend using the Editor role to restrict access to production environments while allowing full access in local or staging environments.
Updated 4 months ago