Access Rights and Content Security

A content tree with hundreds of pages and a team of twenty editors is a recipe for accidental changes. Without granular permissions, a blog editor can accidentally modify the homepage. A regional contributor can overwrite content owned by another market. Worse, sensitive pages like legal disclaimers or pricing tables sit exposed to anyone with edit access.

Optimizely CMS addresses this with an access rights model that controls permissions at every level of the content tree. You decide exactly who can read, create, edit, publish, and delete content — and where.

Optimizely CMS defines five distinct permission levels. Each builds on the previous:

You assign these permissions to roles, individual users, or the special “Everyone” principal.

Access rights in Optimizely CMS follow an inheritance model. Permissions set on a parent page apply to all its children automatically. This means you can set access rights at a high level in the tree and have them cascade down without configuring each page individually.

For example, if you grant the “Blog Editors” role Edit and Publish rights on the /blog page, every page underneath /blog inherits those permissions. New pages created under /blog also inherit them automatically.

Sometimes a child page needs different permissions than its parent. You break inheritance by setting explicit access rights on a specific content item. When you do this, the item stops inheriting from its parent and uses only its own permissions.

Be careful with inheritance breaks. Each break creates a maintenance point. If you break inheritance on fifty pages, you have fifty places to audit when roles change. Keep breaks to a minimum and apply them at section boundaries.

Optimizely CMS supports two complementary permission strategies:

Assign broad capabilities through CMS roles. A user with the CmsEditors role can edit content wherever they have access. This approach works well for small teams where everyone edits everything.

Restrict access at specific points in the content tree. A user might have the CmsEditors role but only have Edit rights on the /products subtree. This approach works for larger organizations with content ownership boundaries.

The most effective setups combine both. Roles define what a user can do in general. Content-tree permissions define where they can do it.

Set up your content tree with top-level sections per department. Assign each department’s editors Edit and Publish rights on their section. Break inheritance at the section level.

Root
  /marketing     -> Marketing Editors (Read, Create, Edit, Publish)
  /products      -> Product Team (Read, Create, Edit, Publish)
  /support       -> Support Team (Read, Create, Edit, Publish)
  /legal         -> Legal Team only (Read, Create, Edit, Publish)

All other roles get Read-only access to sections they do not own.

Give contributors Edit rights but not Publish rights. Give senior editors both Edit and Publish rights. This creates a natural approval flow — contributors draft content, and senior editors review and publish.

Some pages should rarely change — the homepage, legal pages, or navigation structures. Grant Edit access on these pages only to a small “Core Editors” group. Everyone else gets Read access.

For organizations serving multiple markets, create market-specific subtrees. Grant each market’s team full editing rights on their subtree and Read-only access to other markets. Shared assets live in a common area with broader access.

When a user reports they cannot access content, check these things in order:

1. Does the user have a CMS role? Without a role, they have no CMS permissions at all.
2. Does the role have rights on that content node? Check the access rights on the specific page and its ancestors.
3. Is inheritance broken? A broken inheritance somewhere up the tree may exclude the user’s role.
4. Are explicit denials in place? An explicit “no access” overrides inherited permissions.

Review access rights periodically, especially after team changes. An annual audit prevents permission drift — the gradual accumulation of unnecessary access over time.