Access rights

🚧

Important

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

Access rights in Optimizely Content Management System (SaaS) control the content visitors see, what editors can do, and where they can do it in the content structure. For example, you may do the following:

• 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.

You normally manage access rights from the administration page in CMS (SaaS), but you can give editors the right to manage access rights for a single page in the All Properties view.

CMS (SaaS) access rights work together with Opti ID roles, where you define the access rights (read, create, change, delete, publish, administer) and assign them to a specific Opti ID role in CMS (SaaS). Then, you assign that Opti ID role to users or groups in Opti ID.

Access to features

Opti ID provides a login to switch among your Optimizely products with just one authentication using an identity provider (IdP) or a local login. You also can manage your users in a centralized location. Each part of the Optimizely platform has different built-in roles and groups to control authentication and authorization. (Developers may set up permissions during implementation and service onboarding.)

You need to have administrator access to configure access rights in Optimizely.

The product switcher lets you switch between products. You can also access parts of the platform by a specific URL.

What you see in the CMS (SaaS) side menu when logged in depends on which product you have selected and your permissions. The side menu is configured during CMS (SaaS) onboarding and setup, and access rights are defined for different user groups. See Get started with CMS (SaaS) for details about the side menu.

Access to content

You can control which parts of the CMS (SaaS) 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.

Types of access

You can grant or deny the following access rights in CMS (SaaS) for Opti ID roles that then get assigned to users or groups in Opti ID.

• Read – Users with the role can access the content as a reader; otherwise, the content is invisible.
• Create – Users with the role can create content under the item.
• Change – Users with the role 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 – Users with the role can delete the content.
• Publish – Users with the role can publish the content.
• Administer – Users with the role can create and edit approval sequences and set access rights and language properties on individual content items for content given this access. This type of access does not provide access to the administrator page. To access the administrator page, you must be a member of the Content Admins group (see Built-in user groups (roles in Opti ID) in this article).

Built-in user groups (roles in Opti ID)

Optimizely CMS (SaaS) has built-in user groups with pre-defined access levels shown in the following image. The Everyone and Administrators user groups exist only in CMS (SaaS) and are evaluated during runtime. This means you cannot assign them to users and instead, the system handles that. The Content Admins and Content Editors user groups exist in CMS (SaaS) and Opti ID. In Opti ID, these user groups are called roles, which you assign to users or groups in Opti ID to give specific users, or groups of users, this access.

• Administrators – Windows defines this group when you create the application. An administrator can access every part 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 role to access administrator functions. 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 role to access the editing functions. Add users to this group who need access to the editing functions. You can then add users to groups to give them editing rights to specific content. You can organize editors in groups according to content structure or language on large applications.
• Everyone – Windows defines this role as giving visitors read access to application content. Unregistered visitors to a public application are anonymous, meaning the system cannot identify them. If you want to remove the Everyone group from content (to change access rights for a web page, for example), you must login to access content, even if it is published.

You can assign these CMS (SaaS) built-in user groups to users and groups in Opti ID.

• To assign a CMS (SaaS) user group to an existing user in Opti ID, see View user details and edit access in the Opti ID documentation.
• To assign a CMS (SaaS) user group to an existing group in Opti ID, see Edit a group in the Opti ID documentation.
• To add users in Opti ID, see Manage users in the Opti ID documentation.
• To add groups in Opti ID, see Manage groups in the Opti ID documentation. Groups in Opti ID let you assign the same access to a group of users at once instead of individually assigning the same access to multiple users.

If you want to personalize permission levels, create custom roles in Opti ID, where you can assign the roles to users and groups. Then when a user signs into CMS (SaaS) with a custom role, that role syncs to CMS (SaaS) as a user group, where you define the access level (read, create, change, delete, publish, administer).

The following section describes creating a custom role in Opti ID, assigning it to a user or group in Opti ID, and then setting access rights for the CMS (SaaS) user group that syncs from the custom Opti ID role.

Create custom Opti ID roles and set access rights in CMS (SaaS)

You can create custom roles in Opti ID to apply specific access rights to areas of your CMS (SaaS) content tree. For example, part of your content tree may be devoted to marketing assets, and you want to limit access to only Marketing group members. In this case, you could create a custom role called Marketing in Opti ID, assign it to a user or group of users in Opti ID, and then assign access rights to that role after it syncs to CMS (SaaS) as a user group.

🚧

Important

You must create custom roles in Opti ID, and then define the custom role's level of access in CMS (SaaS).

Create a custom role in the Opti ID Admin Center

1. Go to Roles in the Opti ID Admin Center and click Add Role. The Add Role side panel displays.

   • Role Name – Enter the name of the role. For example, Marketing.

   • Description – (Optional) Enter a description for the role. For example, Access to marketing assets in the content tree.

   • Product – Select Optimizely Content Management System. 

   • Product Instances – Select one or more instances. The role is only available for use in the CMS instances you select here. For example, to make this role available across all of your CMS instances, select All instances.

   • Duplicate Role –  Select No to create the role from scratch. To duplicate a role, select Yes, and select a role you want to duplicate, which copies the product and instances to the new role.

   • Select Attributes – You must define the access rights for the Opti ID role in CMS (SaaS) after it syncs.

     
     

2. Click Save. The role displays in the Roles list. The following image shows the Roles list filtered by product (Optimizely Content Management System). You can edit an existing role by clicking More (...) > View Custom Role or clicking the role name, then Edit.

   
   

Add a custom role to an individual user in Opti ID

📘

Note

While you can give a role to an individual user for a specific instance, consider creating a group or users and giving access to the group for a more efficient process. See Should I assign an Opti ID role to a single user or a group? in this article.

1. Go to Users in the Opti ID Admin Center. Search for the user and click their user name. The User panel displays information about the user.

   

2. Click Add Product Access.

   • Product – Select Optimizely Content Management System.
   • Instance – Select the desired CMS instance for which you want this user to have access.
   • Role – Select the custom role you created. For example, Marketing.

3. Click the Checkbox.

   

   The custom role is added to the individual user's access to the selected CMS instance, as shown in the following image:

   

Add a custom role to a group of users in Opti ID

1. Go to Group Access in the Opti ID Admin Center and click Add Group.

2. Enter a Name for the group (like Marketing Members).

3. Select the users you want to be part of the group on the Users tab.

   
   

4. Specify the role (level of access) on the Products tab for a specific CMS instance that everyone in the group will have, and then click Add. For example, in the following image, users in the Marketing Members group have the Marketing role assigned to them for three CMS instances.

   

5. (Optional) Enter a group description on the Details tab.

6. Click Save. The group displays in the Group Access list. The following image shows a filtered Group Access list and five users in the custom group.

   

You can verify that a user's access is assigned through a group by

• selecting a group on the Group Access page, and then checking the Users tab of the group details.
• going to the Users page, viewing a user's details, and expanding the assignments in the Access section.

When you look at the details in the following image, Zach can access three instances through the Marketing role assigned to the Marketing Members group (see notification below each role).

Set access rights in CMS for Opti ID roles

At this point, you have created a custom role for CMS (SaaS) in Opti ID and assigned it to a user or group of users in Opti ID. The custom role syncs from Opti ID to CMS (SaaS) when a user signs into CMS (SaaS) with the custom role. You can optionally assign the role to yourself, and then sign in to initiate the sync.

Now that the custom Opti ID role is in CMS (SaaS) as a user group, you need to define access rights for it.

1. Go to Settings > Set Access Rights in CMS (SaaS) and select the content tree item you want. For example, Marketing.

   

2. Scroll to the bottom of the tree to see the access rights if your content tree is large.

3. Clear Inherit settings from parent item so you can create custom access rights for your selected branch of the content tree (for example, Marketing). To apply your custom settings to the subitems of the branch you selected of the content tree, select Apply setting for all subitems.

   

4. (Optional) Clear the checkboxes for existing CMS (SaaS) user groups to remove unwanted access to this branch of the content tree..

   

5. Click Add User/Group and select the custom Opti ID role you created (for example, Marketing).

   

6. Set the CMS (SaaS) access rights for the custom Opti ID role and click Save Access Rights.

   

7. Select the same page of the content tree (for example, Marketing) to refresh the page. The new access rights display.

   

   Content tree subitems also display the new access rights inherited from the Marketing page.

   

Now the custom Opti ID role you added is in CMS (SaaS) as a user group, and you have defined access rights for it. Any users or groups that you assign this custom role to in Opti ID now have the access you defined in CMS (SaaS).

Access rights inheritance and subitems

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 the Inherit settings from the parent item option enabled. Subitems with this option cleared are not affected. For example, Addresses, Cards, Dictionaries, Mosey Bank Footer, and Mosey Bank Header have the same access rights because they inherit the access rights from the Content page.

If you break the inheritance for Cards and change its access rights, the access rights become different from the parent (Content) and its two siblings (Addresses and Dictionaries). An example of this is shown in Set access rights from the All Properties view in this article.

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, you can apply the same access rights from the Content parent page to its children (Addresses, Cards, Dictionaries, Mosey Bank Footer, and Mosey Bank Header).

When you select Apply settings for all subitems, anyone with a selected CMS (SaaS) user group is given access.

Suppose a parent item and a non-inheriting subitem have the same CMS (SaaS) user group, and the access rights for the CMS (SaaS) user group differ between the parent and the subitem. In that case, CMS (SaaS) applies the parent's settings when you select Apply settings for all subitems. For example:

• If the Content parent item has Opti ID role Content access with only Read access set and the Mosey Bank Header subitem has Opti ID role Content access with all access rights set, then Apply settings for all subitems on the Content parent item resets the Opti ID role Content access access rights on Mosey Bank Header to Read access only.
• Conversely, suppose Content has Opti ID role Content access with all access rights, and subitems have Opti ID role Content access with only Read access. In that case, Apply settings for all subitems gives Opti ID role Content access all access rights on the subitems.

Set access rights from the All Properties view

Administrators generally manage application access rights from Settings. However, you can set access rights for a single page or a block from the All Properties view if you have administrator rights, which is useful when you need to publish an item to verify the final result. Still, you do not want it to be publicly visible.

The following example shows how to set additional access rights to (1) the Mosey Bank item (and its subitems) and then set different access to (2) the Insights item and its subitems).

📘

Note

You must have CMS (SaaS) administrator access in Opti ID to define access rights from the All Properties view. This setting does not provide access to other administration options in CMS (SaaS).

1. Select Mosey Bank in the content tree.

2. Click Manage in the Visible to field.

   

   The Access Rights page displays.

   

3. If an item inherits access rights from the parent page, clear Inherit settings from parent item. You can now edit the access rights.

   

4. Select Add User/Group to add a CMS (SaaS) user group (called role in Opti ID) to the access rights list. In this example, add the Authenticated CMS (SaaS) user group (also called Opti ID role).

   To have the Authenticated Opti ID role as an option here, you must first Create a custom role in the Opti ID Admin Center, then Add the custom role to an individual user in Opti ID or Add the custom role to a group of users in Opti ID. The custom role syncs to CMS (SaaS) when a user with the role signs in to CMS (SaaS). Then it becomes available for selection here.

   

5. Set the access rights you want, and click Save. In this example, the Authenticated Opti ID role has Read, Create, Change, and Publish rights but cannot delete or administer any of the content in the Mosey Bank content tree.

   

6. Select Insights in the content tree, and click Manage in the Visible to field (in All Properties view).

   

   The Authenticated Opti ID role was inherited.

   

7. Clear Inherit settings from parent item to edit the Authenticated Opti ID role's access rights.

8. Clear the settings for the Authenticated Opti ID role and click Save.

   

9. Click Manage in the Visible to field (in All Properties view) to verify that the Authenticated Opti ID role was removed from the Insights access rights.

10. Go to Insights subitems (Giving Back, Financial Services..., and How to: Use AI...) and click Manage to verify that the Authenticated Opti ID role was removed from the access rights of those subitems. The Authenticated Opti ID role was given specific access to all items in Mosey Bank except for Insights and its subitems.

📘

Note

If you clear access for the Everyone CMS (SaaS) user group, the page is from the public, but visible and editable for Administrators, Content Admins, and Content Editors (and SearchIndexer) CMS (SaaS) user groups (in this example).

Set access rights for media

An editor must have Create access rights to the global or application-specific folder under For All Applications or For This Application to upload an image or create a block. Similarly, an editor must have Create access rights to the current page when adding assets to the local For This Page folder. 

Media are never automatically published if someone sets an approval sequence on the folder to which the media are uploaded.

Suppose you want media to be automatically published when it is uploaded. In that case, editors who upload must have Publish access rights to the global folder, application-specific folder, or the page if you upload media to the local folder. See Folders for a description of global, application-specific, and local folders. 

Should I assign an Opti ID role to a single user or a group?

You can assign an Opti ID role to a single user or group of users, and then set access rights for everyone assigned to that role to content in the CMS (SaaS) content tree. For example, you can assign a role to Abbie in Opti ID, then set the access rights for that role in CMS (SaaS) so only Abbie (and system administrators) can edit the Book a Demo page. You can add the Opti ID role that is only assigned to Abbie to any number of pages and content and set the role's (and therefore Abbie's) access rights to each content item similarly (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. Instead:

1. Create a custom role in the Opti ID Admin Center.
2. Add a custom role to a group of users in Opti ID.
3. Set access rights in CMS for Opti ID roles.

For example, create a custom Marketing role in Opti ID, create a Marketing users group in Opti ID, add the Marketing role to the Marketing users group in Opti ID, then add Abbie, Erin, and Reid to the Marketing users group in Opti ID. Now when you give access rights to any number of pages and content in CMS (SaaS) for the Opti ID Marketing role, that gives everyone in the Opti ID Marketing users group the same access at once instead of having to assign it to each individual. Then you can modify the Marketing user group to add Eddie to all the marketing content (or remove Abbie). You do not have to visit each page or content item to update users' access rights.

📘

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 users and Support users groups in Opti ID, each have Opti ID roles with different CMS (SaaS) 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.

Remove CMS (SaaS) access rights for an Opti ID role

While you can clear access rights in CMS (SaaS) for an Opti ID role, it might be more efficient to go into Opti ID and delete the role. That will remove the role from any users or groups that had it, which removes the access the role previously gave them, regardless of it it still exists in CMS (SaaS) with defined access rights.

Access rights for languages

If your application has content in multiple languages, you can define access rights for each language so editors can create content only in the languages to which they have access. Go to Settings > Manage Website Languages to see enabled languages, but only users with access rights to a language can create and edit content in that language. See Manage languages.