By continuing to use this site, you agree to the storing of first- and third-party cookies on your device to enhance site navigation; analyze site, product, and service usage; and assist in our marketing and promotional efforts. Cookie Policy

Skip to Content

Access and Workflow 101

Omni CMS uses access settings to control who can modify what content. This includes setting publish approvers, leading to the workflow system, where pages are sent to other users for review, approval, or decline. This tutorial covers the basic principles of access and workflow and potential scenarios.

BasicsLink to this section

Access determines who can go where and do what; certain folders might be available only to certain users, or some users are unable to upload files, or certain assets are only available for use to some users. Workflow is the process by which pages are submitted for publication to other users, potentially returned or passed on for editing, and finally published.

Access is set on a per-group basis. If you want Liam, Laura, and Marisha to have access to the theater folder, you can't individually allow access for each of them – instead, you create a group containing those three users and allow that group to have access to the folder. Only one group can have access to a folder at a time, but users can be in multiple groups.

Individual users can have enforced approvers, meaning they must always send any files they wish to publish to that user. Approvers can also be set for certain directories. On the other hand, Bypass Approval groups can also be set, allowing members of that group to override the approval process.

A flow chart. It starts with a square bubble labelled "Anna." Three paths lead from it: one to the square bubble "Bob," one to the tag "Alumni Directory" and the square bubble "Christine," and the third to the tag "Faculty Page." All three paths conclude with a square labelled "Publication."
An example workflow.

In the above example, Anna is a user editing content. Normally, her enforced approver is Bob, meaning any changes she makes need to be approved by him. However, the approver for the alumni folder is Christine, so if Anna makes changes within that folder Christine must approve them, not Bob. On the other hand, Anna is in the Bypass Approval group for the Faculty Page, so she may publish directly any changes she makes to that page.

User LevelsLink to this section

User levels are a key part of access and workflow. Note that for nearly all of these user levels, certain rights and abilities can be granted or denied on a per-user basis. For example, a Level 6 user is not by default able to edit source code, but can be given this ability in their user settings.

User Level

Key Abilities

Reviewer ( Level 0)

  • Can preview content but not edit it
  • Can publish content, schedule actions, or forward it to another user
  • Can access Versions and Page Check


Typical user: someone who doesn't edit pages, but wishes to review them before they are published.

Contributor (Levels 1-4)

  • Can view and edit content to a certain degree, such as editing text and inserting images
  • Level 4 users can add pages
  • They can publish by default, but it is common to revoke these rights


Typical user: someone who updates content but doesn't necessarily create new content.

Editor (Level 5-7)

  • Can view and edit content, including the ability to edit page parameters and source editing
  • Level 6 and above can upload files
  • Ability to create new pages


Typical user: a general editor, often someone who has had experience in a CMS, who creates as well as edits content.

Designer (Level 8)

  • Can edit and upload content
  • Can rename, move, copy, and delete files
  • Can change who has access to the folder, page, binary file, or asset to any group to which they belong.


Typical user: a departmental administrator in charge of a section of the website or a group of users

Assistant Administrator (Level 9)

  • Able to perform editing, uploading, and other system tasks
  • Can access all of the Reports
  • Can check in and reassign pages on behalf of others
  • Can change who can access the folder, page, binary file, or asset to any currently defined group.


Typical user: administrators who have a great deal of responsibility but are not in charge of the account

Administrator (Level 10)

  • Can go anywhere and do anything
  • Create users and groups
  • Can change who can access the folder, page, binary file, or asset, as well as modify the other site access settings and directory variables, including those belonging to the site.
  • Perform various site actions and edit site settings
  • Only users with access to the Setup menu
  • Always override approval

Inheritance and PrecedenceLink to this section

Inheritance explains how the system functions in terms of access settings being determined by the settings above them. By default, an item inherits its access settings from its parent. For example, if a folder is restricted to the "Administrators Only" group, then unless specified otherwise all pages within that folder are also only available to members of that group.

Tied into inheritance is the concept of recursive modification. When changing access settings in Omni CMS, you can modify them either recursively or non-recursively.

  • Recursive Modification – changes access settings both for the folder and for every file inside it, even if they already have configured settings, and also affects new files created going forward.
  • Non-Recursive Modification – changes access settings only for the folder and any new items going forward; existing files with configured settings aren't affected.

Precedence refers to how settings closer to the content override any settings that may have been set above it. For example, access settings for a page override those set for the folder it's in, and access settings for an editable region override those of the page it's on.

The order of precedence is, from lowest to highest:





Editable Regions

Users are considered to have the least amount of precedence as they are the furthest from the content. Therefore, if it is important to have settings based on the user, be sure that the setting is not different anywhere else within the site.

Access settings can also be assigned to the servers, assets, templates, and other content, but these settings do not necessarily fall into this hierarchy.

Access SettingsLink to this section


ExercisesLink to this section