---
title: Access rights without Opti ID
slug: cms-12/docs/access-rights-without-opti-id
docTags: 
createdAt: 2026-08-10T15:55:56.000Z
---

:::hint{type="info"}
**Note**

This topic is for CMS administrators and developers with administrative access rights.
:::

You can add users and create groups and give them varying types of access. By creating a group, such as *Marketing Department*, you can add users from the marketing department and they will each have the same access rights as the others in the group.

:::hint{type="warning"}
**Important**

If your organization uses Opti ID with CMS 12, see [Access rights with Opti ID](docId\:CjO-6alJusBpkVcqMcm7V).
:::

Access rights in Optimizely Content Management System (CMS) controls the content that visitors see, what editors can do, and where they can do it in the content structure. For example:

- You may give members of the marketing department access to edit the website marketing material that other company users should not edit.
- You can set access rights for many types of content, such as pages, blocks, images, and documents, and in the navigation and assets panels.
- You can also use access rights together with audiences and give an audience from a local 10-mile radius access to an advertisement page.

Access rights are normally managed from the administration view in CMS, but you can give editors the right to manage [access rights for a single page in edit view](docId\:e3x3piHYkRsoW3PVOv6i2).

Video: Manage access rights

![video icon](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/gcZeL7wjv1SzZ9V83Yqvc-20260720-145548.svg)

Video tutorial: [Manage access rights](https://optimizely.wistia.com/medias/oyjerpnlvd) (6:39 minutes)

## Types of access

You can control which parts of the application content structure are available to business users, such as content editors and site administrators, and what is available with restricted access to visitors. You can also let visitors post comments on the application through access rights.

- **Read** – The user or group can access the content as a reader; otherwise, the content is invisible.
- **Create** – The user or group can create content under the item on which this right is set.
- **Change** – The user or group can access the content to modify it. Typically, Create and Change are set together, but there may be cases where you want someone to modify created content (but not create their own) or vice versa.
- **Delete** – The user or group can delete the content.
- **Publish** – The user or group can publish the content.
- **Administer** – The user or group can create and edit [approval sequences](docId:3UvrmseQgC0NvxBHEu8I-) and [set access rights and language properties on individual content items from edit view](docId\:e3x3piHYkRsoW3PVOv6i2) for content given this access. This does **not** provide access to the admin view. To access the admin view, you must be a member of the CmsAdmins group, see [Built-in user groups](docId\:e3x3piHYkRsoW3PVOv6i2)).

## Built-in user groups

By default, Optimizely CMS has built-in user groups that align with user roles. You can extend predefined groups and roles; see [Managing users and user groups](docId\:MbjzWcQ6ZDxh45qzgwYLK).

:::hint{type="info"}
**Note**

When your website is set up during development, the membership and role providers available for your website must be configured to use the built-in groups and roles in Optimizely.
:::

![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/8hNOzZ9YSMsWxXlNelwgv-20260720-145548.png)

- **Administrators** – Windows defines this group when the application is created. An administrator can access all parts of the system and can edit all application content. Often, administrators are developers who set up or maintain the application.
- **Content Admins** – Optimizely defines this group to access admin and edit views. Membership in this group does not provide editing access to the content structure. In most cases, only a few system administrators or "super users" belong to this group.
- **Content Editors** – Optimizely defines this group to access the editing view. Add users to this group who need access to the edit view. Then, add the users to other groups to give them specific editing rights to content. On large websites, editors are often organized in groups according to content structure or language.
- **Everyone** – Windows defines this group to give visitors read access to website content. Unregistered visitors to a public website are anonymous, meaning the system cannot identify them. If you want to [remove the Everyone group from content](docId\:e3x3piHYkRsoW3PVOv6i2) (to change access rights for a web page, for example), you must login to access content, even if it is published.

## Access rights to assets

As for pages, you can apply access rights to assets in the content structure, such as folders, blocks, and media. You can define specific access rights from the "Root" level and down, including the **Recycle bin** (Trash) and **For All Sites** that store blocks and media. Blocks and media share the same folder structure.

You assign access rights on a "per content" basis, allowing different levels of interaction for various groups with each content piece. You can set access rights for a single content piece or a content hierarchy, with sub-items automatically inheriting the parent's access rights. You can also apply access to a content item that is different from the parent item by clearing its inheritance.

For instance, Dan might have full access rights while Bob has only read access to the same content. Additionally, Dan can have full access to one piece of content but different rights on another. You should place users into groups for CMS access rights to streamline permission management, ensuring consistent and efficient access control across multiple users and content pieces. See [Add users and groups](docId\:Ri0cbTCw7nykACvxNh03r).

Editors must have **Create** access rights to the global or site-specific folder under **For All Sites** or **For This Site** where they want to upload an image or create a block, or to the current page when adding assets to the local **For This Page** folder. Suppose media should be automatically published when uploaded. In that case, editors who upload must have **Publish** access rights to the global or site-specific folder or the page if media are uploaded to the local folder.

See [Folders](docId\:kF3hS6kg4GSuAvQNF5VX7) for a description of global, site-specific, and local folders.

:::hint{type="info"}
**Note**

Media are never automatically published if an approval sequence is set on the folder to which the media are uploaded.
:::

![Settings-set-access-rights.png](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/LqBRuilvexCph8kYWefEh-20260720-145548.png)

## Set access rights

1. Go to **Settings** > **Access Rights** >  **Set Access Rights**. The Set Access view displays with a content tree structure of the website.
2. Click a node in the content tree (for example, *Alloy Track*). Typically, a content item shows **Administrators** (with all access rights) and **Everyone** (with Read-only access rights). You can change these rights or add users or groups.
   - If the users or groups are inactive (grayed out) for a content item, then the content item [inherits the access rights of its parent](docId\:e3x3piHYkRsoW3PVOv6i2) content item. To set access rights for this content item, clear the **Inherit settings from parent item** checkbox.
   - To add settings to the selected node's subitems without affecting their existing settings, select the **Apply settings for all subitems**; see section [Set access rights for all subitems](docId\:e3x3piHYkRsoW3PVOv6i2) below.
3. Select **Settings** > **Access Rights** > **Manage Users**.
4. Click **Create User** (or select a user from the list). You can enter a name or email address in the search field to find a specific user or group.

   ![Administer-users.png](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/2YCSsI42hQHW_pbjXMqUJ-20260720-145548.png)
5. Go to **Settings** > **Access Rights** > **Set Access Rights** and select **Add Users/Groups**. A list of available users and groups displays.

   ![Set access rights for users and groups](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/dqepuoSUxAUBE43vam7MG-20260720-145548.png)
6. Add or remove the access rights settings as you want them, and click **Save Access Rights**. The users or groups display in the **Set Access Rights** view for the selected content tree item.

   ![Set access rights for users](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/Z8pD-_Jvjy56Dj5qMrMwt-20260720-145548.png)

:::hint{type="info"}
**Note**

If you set conflicting access rights to content, selected access rights prevail over cleared access rights. For example, Abbie is a member of the *Marketing* and *Support* user groups, each with different access rights set on the same content; *Marketing* has **Publish** rights, but *Support* does not. Abbie, who is in both groups, has **Publish** rights to the content, but Erin, who is only part of the Support group, does not have **Publish** rights.
:::

### Set inheritance for content subitems

Content inherits access rights from its closest parent item by default. When you set access rights for a content item, the rights apply to it, and subitems that have a selected **Inherit settings from parent item** option, subitems with this option cleared are not affected. For example, *Alloy Plan*, *Alloy Track*, and *Alloy Meet* have the same access rights because they inherit the access rights from the *Start* page.

![Folder structure under Start](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/rtr6_cyV_at-PwV8t8HuY-20260720-145548.png "Folder structure under Start")

- If you break the inheritance for *Alloy Meet* and change its access rights, the access rights become different from the parent (Start) and its two siblings (Alloy Plan and Alloy Track).
- If you add a *Marketing group* to Start, Alloy Plan, and Allow Track, inherit the Marketing group (because inheritance is selected). Still, Alloy Meet does not because its inheritance is unselected.

The following image shows the access rights for the **Alloy Track** content; it will not inherit from the parent item. Any changes of access rights on Marketing will not be pushed to subitems unless they have selected the **Inherit settings from parent item** option.

![Set access rights for Alloy Track content](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/bPX6juwS3R_wt8nZPb1GP-20260720-145548.png)

*Campaigns* is a subitem of *Alloy Track*. It has **Inherit settings from parent item** selected, so the access rights are identical to that of the Alloy Track content item.

![Set access rights for campaigns](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/kuwJa0CuS0cnqJgPu1shF-20260720-145548.png)

*Book a demo* is also a subitem of Alloy Track, but contrary to *Campaigns*, it has **Inherit settings from parent item** cleared, so its access rights are not the same as the parent content item.

![Set access rights for Book a demo](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/K4ZkfBfTmhhVzev24NmcJ-20260720-145548.png)

### Set access rights for subitems

Selecting the **Apply settings for all subitems** checkbox applies the access rights of the parent item to its subitems, even if a subitem has inheritance cleared. The option adds settings to a subitem it did not have before and does not change or remove any existing settings.

For example, the *Alloy Track* content item has Abbie as a user with access rights.

![Set access rights for user Abbie](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/sFG--eDgtVNvSRLZ26-p7-20260720-145549.png)

When you select **Apply settings for all subitems**, *Abbie* is added as a user with access rights to *Book a demo* because *Abbie* is part of the *Alloy Track* content item's access rights. *Reid*, who already had access rights to *Book a demo*, remains unchanged on the list of access rights.

![Set access rights for users Abbie and Reid](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/pX537zf_5QKWGIKOdq_-6-20260720-145549.png)

Suppose a parent item and a non-inheriting subitem have the same user or group, and the access rights for the user or group differ between the parent and the subitem. In that case, the parent's settings are applied when you select **Apply Settings for all subitems.** For example:

- If the *Alloy Track* parent item has user *Abbie* with only *Read* access set, and *Book a Demo* has user *Abbie* with all access rights set, then **Apply Settings for all subitems** resets Abbie's access rights on *Book a Demo* to Read access only
- Conversely, suppose *Alloy Track* has user *Abbie* with all access rights, and the subitem has user *Abbie* with only *Read* access. In that case, **Apply Settings for all subitems** gives user *Abbie* all access rights on the subitem.

## Set access rights from edit view

Administrators generally manage website access rights from the administration view. However, you can set access rights for a single page or a block from the edit view if you have administrator rights. This is useful when you need to publish an item to verify the final result but you do not want it to be publicly visible.

:::hint{type="info"}
**Note**

If sub-items are set to **Inherit settings from parent item**, these items are also affected by your change.
:::

To set access rights, open the item in the [All Properties edit view](docId\:d3R8i01k20fkNNZR7zagr) (or scroll to the top of the page in the on-page edit view). The **Visible to** option displays **Everyone** for publicly available content on the website and **Restricted** if access limitations apply.

![All Properties visible to view](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/rm6h21iW185YoDP4QB2nz-20260720-145549.png)

Click **Manage** to change the settings in the **Access Rights** dialog box:

![access rights dialog box](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/QJV6XbrrS0GWSFMNpIjZ0-20260720-145549.png)

If access rights are inherited from the parent page, clear **Inherit access rights from parent item**, and click **Add Users/Groups** to define new access rights. Add access rights as desired and save the settings.

For example, removing read access for **Everyone**, as in the example above, hides the published page from the public, but it is fully visible and editable for the **Site\_Editors** group (and **Administrators**).

:::hint{type="info"}
**Note**

You must belong to a group with **Administer** access rights to define access rights from the edit view. This setting does not provide access to other administration options in Optimizely Content Management System (CMS).
:::

## Should I set access rights for a single user or a group?

You can set access rights to content for a single user. For example, you can set the access rights so only *Abbie* (and system administrators) can edit the *Book a Demo* page. You can add *Abbie* to any number of pages and content and set Abbie's access rights to each content item the same (or differently) for each page.

If you have several users who need common access to content, managing access rights on a user-by-user basis can be complex. Create [user groups](docId\:MbjzWcQ6ZDxh45qzgwYLK) with similar access needs, add the users to each user group, and then use the user group to set access rights to content. This lets you manage access rights. You can add a user to one or more groups.

For example, add *Abbie*, *Erin*, and *Reid* to a *Marketing user group* and give access rights to any number of pages and content to the Marketing group instead of each individual. You modify the *Marketing* user group to add *Eddie* to all of the Marketing content (or remove *Abbie*). You do not have to visit each page or content item to update users' access rights.

## Remove a user or group from the access rights list

To remove a user or group from the access list, clear all of the access rights for that user or group and click **Save**.

## Use an audience in an access rights list

The [Optimizely Recommendations](https://support.optimizely.com/hc/en-us/articles/4413200700941) feature uses [audiences](docId\:LobkK1ZzP8EBsvztqwifN); you need administration access rights to manage audiences. If you want an editor to manage audiences without providing access to the entire admin view, you can make the editor a member of **AudienceAdmins**. This group provides access only to the **Audience** option in the top menu. **AudienceAdmins** comes with Optimizely, but you must add it through **Settings** > **Access Rights** > **Administer Groups** > **Create** **Group** > **AudienceAdmins**.

![Audience Admins](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/sbgROfsy7pUq2bBAo6fDW-20260720-145549.png)

You can set specific access rights for audiences, letting them view specific "hidden" content that is not publicly available. For example, you may want only members of the *Visitors from London* audience to have access to a *Family day at the zoo* page with a discount coupon.

This feature is useful to create a "customer area" for registered customers on your website. Being an audience member requires registration and login to access the content.

1. Go to **Settings** > **Access Rights** > **Set Access Rights**.
2. Select a node in the content tree.
3. Click **Add Users/Groups**.
4. Select **Audiences** to view available audiences.
5. Select an audience and click **OK**.

:::hint{type="info"}
**Note**

Audiences can only have **read** access.
:::

## Access rights for languages

If your website has content in multiple languages, you can define access rights for languages so editors can create content only in languages to which they have access. Enabled languages are displayed in the **Config** view, but only users with access rights to a language can create and edit content in that language. See [Website languages](docId\:UpkYWcYTwyI-Pg3uUHKDo).

## Access rights for the CMS platform

See [Permissions](docId\:jH2PV64gk70Wh_BF_BtKw) for information about managing access rights for other parts of the Optimizely Content Management System (CMS) platform.