Access Groups & Permissions

An access group is a named set of permissions you assign to users. Groups live in tcms-data/.system/access-groups.json, and each one carries the same permission blocks: collection objects, collection settings, schemas, the Site Builder, settings sections, utility pages, extensions, the mailer, the Twig playground, Data Views and the documentation.

Permissions are expressed as CRUD operations — create, read, update and delete — scoped either to everything or to a named list. Each block has an all flag and an allowed array: set all to false and name the collections, schemas, settings sections or utility pages the group may reach. A few permissions are plain booleans rather than CRUD sets, including the Site Builder, the mailer, the playground, Data Views and the docs.

Collections are deliberately split into two blocks. collections governs the objects inside a collection; collectionsMeta governs the collection definition itself — creating collections, editing their settings, deleting them. That split is what lets a client add and edit posts every day without ever being able to delete the collection those posts live in.

Enforcement happens at two levels. Routes are protected by middleware that checks permissions before the request is handled, and template helpers let you hide the links and buttons a user cannot use: cms.auth.canAccessCollection('blog', 'delete'), cms.auth.canAccessSchemasOperation('create'), cms.auth.canAccessBuilder(), cms.auth.canAccessUtil('cache-manager'). The middleware is the security boundary; the helpers are the good manners on top of it.

Some things cannot be delegated at all. Access group management, API key management and user management sit behind an admin-only middleware and require a super admin — a member of the admin group in the default auth collection, who bypasses every access check automatically.

One configuration straight out of the documentation: an editor group with full CRUD on the blog and news collections, read-only access to their schemas, the playground and docs switched on, the mailer off, and exactly one utility page allowed — the cache manager. That is a client who can do their job, and nothing beyond it.

What you get

CRUD, not vague roles

Every block names the operations a group may perform — create, read, update, delete — over everything, or over a named list of resources.

Objects and definitions apart

collections governs the records inside a collection; collectionsMeta governs the collection itself. An editor can post without being able to delete a collection.

Enforced on the route

Middleware checks permissions before a request is handled, so hiding a button is a courtesy rather than the security boundary.

Helpers for the interface

cms.auth.canAccessCollection(), canAccessSchema(), canAccessBuilder(), canAccessUtil() and isAdmin() let a template show only what a user can act on.

Things you cannot delegate

Access groups, API keys and user management are super-admin only. Members of the admin group bypass every access check.

In practice

One snippet

{% if cms.auth.canAccessCollection('blog', 'update') %}
	<button>Edit Post</button>
{% endif %}

{% if cms.auth.canAccessCollection('blog', 'delete') %}
	<button class="delete">Delete Post</button>
{% endif %}

The same permissions the middleware enforces are readable from a template, so the admin shows only what a user can act on.

FAQ

Common questions

Where are access groups stored?

In tcms-data/.system/access-groups.json, alongside the rest of the system configuration, and edited from the admin.

Do access groups apply to the REST API as well as the admin?

Yes. Routes are protected by middleware that checks permissions before the request is handled, so a group's permissions apply to both the admin dashboard and the REST API.

Can I let an editor manage other users?

No. Access group management, API key management and user management require a super admin and cannot be delegated to a group.

Can a group be limited to specific collections?

Yes. Each permission block has an all flag and an allowed list. Set all to false and name the collections, schemas, settings sections or utility pages the group may reach.

Related features

Want the details? Read the Access groups & permissions documentation →

Or keep browsing: every Total CMS feature →

Start Your Free 45-Day Trial

Give everyone exactly the access they need