Skip to content

User Management and Roles

beginner

Every person on your team needs different capabilities. Editors write and publish content. Marketers run experiments. Administrators configure the system. Without clear role assignments, you get one of two bad outcomes: either everyone has full admin rights (risky), or people lack the permissions they need (slow).

Optimizely CMS solves this with a role-based access model. You assign each user a role that matches their responsibilities. The CMS enforces what they can see and do.

A role is a named set of permissions. When you assign a role to a user, that user gains all permissions the role grants. Users can hold multiple roles, and the permissions stack — a user with both Editor and Marketer roles gets the combined permissions of both.

Optimizely CMS ships with several predefined roles:

RoleWhat it can doTypical user
CmsAdminsFull system access — manage users, configure settings, deploy content typesIT administrators, technical leads
CmsEditorsCreate, edit, and publish content across the content treeContent editors, copywriters
CmsReadersView content in the CMS editor but not modify anythingStakeholders, reviewers
VisitorGroupAdminsCreate and manage visitor groups for personalizationMarketing leads
WebAdminsManage site settings, scheduled jobs, and system configurationSite administrators

These built-in roles cover the most common needs. For more granular control, you can create custom roles that combine specific permissions.

When built-in roles do not match your team structure, create custom roles. A common pattern is to split editing rights by section:

  • Blog Editor — Can edit content only under the Blog section
  • Product Manager — Can edit product pages but not marketing content
  • Regional Editor — Can edit content for a specific market or locale

Custom roles combine a name with a set of content-tree permissions. You define the role, then assign access rights to specific parts of the content tree.

Opti ID is the identity platform for Optimizely One. It provides single sign-on (SSO) across all Optimizely products — CMS, Experimentation, Data Platform, and Commerce.

This distinction matters and causes confusion. Here is the difference:

ScopeCMS rolesOpti ID organization roles
What they controlPermissions inside CMS (edit, publish, admin)Access to Optimizely products (CMS, Experimentation, etc.)
Where you manage themCMS Admin interfaceOpti ID portal
GranularityContent-tree levelProduct level
Example”Can publish pages under /blog""Can access CMS and Experimentation”

Use Opti ID roles to decide which products a person can access. Use CMS roles to control what that person can do inside the CMS.

  • A new team member needs access to both CMS and Experimentation — assign Opti ID organization roles
  • An editor should only edit blog content, not product pages — assign a CMS role with restricted access rights
  • A contractor needs temporary read-only access to CMS — assign the CmsReaders role in CMS and grant CMS access in Opti ID
  • Start with built-in roles. Only create custom roles when the defaults do not fit your workflow.
  • Follow least privilege. Give each user the minimum permissions they need. Promote to higher roles only when justified.
  • Audit regularly. Review user lists quarterly. Remove accounts for people who have left the team.
  • Use groups when possible. If ten editors need the same access, assign them a shared role rather than configuring permissions individually.
  • Document your role model. Keep a record of what each custom role grants and why it exists. This prevents role sprawl over time.
ScenarioRecommended approach
Small team (fewer than 10 CMS users)Use built-in roles only
Departmental content ownershipCustom roles per department with content-tree restrictions
Multi-market organizationCustom roles per market or locale
Agency or contractor accessCmsReaders role with limited content-tree access
Enterprise with SSOOpti ID with SAML/OIDC integration, CMS role mapping