Cascade Administration concept

Permissions in Cascade CMS: Sites, Roles, Groups, and Folder Access

Permissions issues in Cascade CMS usually come from mixing together concepts that do different jobs. Site access controls whether a user can get into a site. Roles (and the Abilities within them) control what kinds of actions they are allowed to perform. Groups make those assignments manageable at scale. Access Rights on folders and assets determine where those actions are allowed. When one of those layers is missing, a user can log in and still be unable to do useful work.

Decision matrix

Use this matrix to decide which permission layer you actually need to change.
Need	Change this	Why
User cannot even access the site	Site assignment	Without site access, the rest of the permission model does not matter.
User can enter the site but cannot edit or publish	Role (Abilities)	The Role's Abilities determine allowed actions such as edit, publish, or administer.
User can edit one section but not another	Access Rights (folder or asset-level)	Access Rights decide where a user's Role applies.
You need to manage many similar users consistently	Group membership	Groups keep assignments repeatable and easier to audit.

How the model works

A useful way to think about Cascade permissions is:

Site access answers "Can this user work in this site at all?" — configured under the user or group's Sites tab.
Role answers "What kinds of things can this user do?" — each Role contains a set of Abilities (checkboxes for edit, publish, administer, etc.) configured under Administration > Roles.
Access Rights answer "Where can this user do those things?" — set on individual folders or assets, controlling which users or groups can read, write, or manage content in that location.
Groups answer "How do we assign this consistently to many users?" — managed under Administration > Groups.

Most scalable setups assign users to Groups, assign Groups to Sites with Roles, and then use folder-level Access Rights to control the content areas each Group can manage.

The "All" site

Cascade CMS has a special All site context. Roles assigned at the All level apply across every site the user can access. Use this for global administrators, but prefer site-specific Role assignments for most users to avoid over-permissioning.

Recommended setup pattern

For most teams, group-based administration is the cleanest default:

Create Groups under Administration > Groups that reflect real job functions or content ownership (e.g., "Marketing Editors", "Biology Department").
On the Group's Sites tab, assign the appropriate Site and Role instead of assigning to each user individually.
Set Access Rights on folders to grant the Group read/write access to the part of the site they manage.
Reserve direct user-specific permission assignments for exceptions, not normal operations.

Tip

If you find yourself repeatedly granting the same access to one person at a time, you probably need a new group rather than more one-off user overrides.

Real-world example

A university needs to onboard a new departmental editor for the Biology section of the site. The right setup is not to copy permissions from another user asset by asset. Instead:

Add the user to the Biology Editors Group (Administration > Groups > Biology Editors > Members tab).
On the Group's Sites tab, ensure the campus site is listed with an appropriate Role (e.g., "Contributor").
The Contributor Role should have Abilities that allow editing and submitting content but not full site administration.
Set Access Rights on the /biology/ folder to grant the Biology Editors Group read and write access.

That single pattern answers all four permission questions: the user can enter the site, perform the correct actions, work only in the right section, and be managed alongside the rest of the department.

Troubleshooting common permission failures

User can log in but cannot see the site

This usually means the account exists but lacks site access. Check the user's or group's Sites tab before changing Roles or Access Rights.

User can see the site but cannot edit

This usually means the Role does not include the required Ability (e.g., the "Edit" ability is unchecked), or the folder-level Access Rights do not grant write access in that location. Check both Administration > Roles and the folder's Access Rights.

User can edit some sections but not others

That is typically an Access Rights issue, not a site-access issue. Compare the Access Rights on the folder they can edit versus the folder they cannot. The user or their Group may not have write access on that specific folder.

User can edit but cannot advance workflow

Workflow problems are usually Role or workflow-assignment issues. The user's Role may lack the Ability to advance workflows, or the workflow step may be assigned to a different user or Group. Access Rights alone do not guarantee the right to move items through a workflow step.

Common mistakes

Granting Access Rights directly to individual users when the access pattern really belongs to a Group.
Changing folder Access Rights when the real issue is missing site access on the user's or Group's Sites tab.
Giving overly broad administrative Roles (or assigning at the "All" site level) just to solve one narrow editing problem.
Assuming a user who can edit one folder should automatically be able to publish everywhere — edit and publish are separate Abilities.
Forgetting that workflow step assignments and content Access Rights are related but not identical concerns.

Avoid permission drift

The more user-specific overrides you add, the harder it becomes to explain why someone has access. If permissions feel unpredictable, audit the model and collapse one-off exceptions back into groups wherever possible.