Dev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

Invite collaborators

How to invite collaborators to your Full Stack project through the Optimizely Application.

Invite collaborators to your project to allow your team to manage feature flags, run experiments, roll features out and roll them back. The number of collaborators is limited to your Optimizely plan. View the plans & pricing page on for more information and current collaborator limits.


Collaborators are users that:

  • Log into the Optimizely application.
  • Utilizes an Optimizely 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. For example, a developer who maintains Optimizely code in their code base and does not use any Optimizely credentials is not considered a collaborator.

Invite collaborators

Invite a Collaborator in Full Stack
  1. Navigate to Settings > Collaborators.
  2. Select Invite a Collaborator.
  3. Enter the email addresses of your collaborators, and select their permission levels. You can also invite collaborators to multiple projects at once.


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 features or experiments.
  • Editors and Restricted Editors can set up features and experiments in restricted environments, like local or staging environments, but cannot launch features or experiments in non-restricted environments like production (you can customize this with restricted environments). If a feature test is running in a restricted environment, an Editor can change only the traffic allocation or whether a feature is enabled or disabled.
  • Publishers and Restricted Publishers can launch features and experiments in production.
  • Administrators have full permissions to manage account settings and access to all Projects

Restricted Editors and Restricted Publishers have distinct permissions from Editors and Publishers within Full Stack Projects. We recommend using Editor and Publisher in Full Stack projects.

ActionsViewerEditorPublisherProject OwnerAdministrator
Experiments (create, edit, start, pause, archive)NoYes *YesYesYes
Variations (create, edit, re-allocate traffic, pause, delete)NoYes *YesYesYes
Features (create, edit, archive)NoYes *YesYesYes
Variable keys (create, edit, delete)NoYes *YesYesYes
Traffic allocation (edit)NoYes *YesYesYes
Events (create, edit, archive)NoYes *YesYesYes
Audiences (create, edit, archive)NoYesYesYesYes
Whitelists (add users, edit, delete)NoYes *YesYesYes
Attributes (create, edit, archive)NoYesYesYesYes
Collaborators (invite, edit, delete)NoNoNoYesYes
Environments (create, edit, archive)NoNoNoYesYes
Webhooks (create, delete)NoNoNoYesYes
Integrations (create, edit, delete)NoNoNoYesYes
Reset resultsNoNoYesYesYes
Mutual exclusion groups (create, edit, delete)NoYesYesYesYes

*** In restricted environments, Editors and Restricted Editors can create features and experiments but cannot launch, pause or change traffic allocation. In non-restricted environments, those Editors and Restricted Editors have full access to all aspects of features and experiments. We recommend using the Editor role to restrict access to production environments while allowing full access in local or staging environments.