# Permissions in Cascade CMS: Sites, Roles, Groups, and Folder Access > Understand how site access, roles, groups, and folder-level permissions work together in Cascade CMS, with a practical decision matrix and troubleshooting guide. URL: https://www.hannonhill.com/cascadecms/latest/articles/cascade-administration/permissions-sites-roles-groups-folder-access.html category: Cascade Administration article-type: concept content-kind: article release-availability: all tags: permissions, sites updated: 2026-10-06 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: 1. **Site access** answers "Can this user work in this site at all?" — configured under the user or group's **Sites** tab. 1. **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**. 1. **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. 1. **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: 1. Add the user to the **Biology Editors** Group (**Administration > Groups > Biology Editors > Members** tab). 1. On the Group's **Sites** tab, ensure the campus site is listed with an appropriate Role (e.g., "Contributor"). 1. The Contributor Role should have Abilities that allow editing and submitting content but not full site administration. 1. 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.