Documentation

Site Members

Site members are the users who have access to a content site in SleekCMS. Every member is assigned one of two roles — admin or editor — which determines what they can see and do within the site. Admins have full control. Editors have content access only, and their permissions can be further restricted with fine-grained access controls.

This page is a reference for the two roles, how they differ, and how customizable access works for editors.

Roles

SleekCMS uses a two-role model at the site level. Every member of a site is either an admin or an editor.

Admin

Admins have unrestricted access to the entire site. This includes content editing, content modeling, site configuration, site builder templates and assets, deployment, publishing, member management, and all other administrative functions.

Admins can:

  • Create, edit, and delete all content — pages, entries, and media.
  • Create and modify content models — page models, entry models, block models, field configurations, and option sets.
  • Manage admin-only entries such as navigation, footer, and site settings.
  • Access and edit templates, assets, and layout in the site builder.
  • Deploy the site to connected hosting providers.
  • Trigger publish actions and manage environments.
  • Invite, remove, and configure permissions for other site members.
  • Access all site settings, including configuration, localization, and image processing.

The admin role is intended for developers, site owners, and technical leads who need full control over both content and infrastructure.

→ Admin Role

Editor

Editors have access to content only. They can create, edit, and manage content within the models that exist, but they cannot modify the models themselves, change site configuration, manage templates, or deploy the site.

Editors can:

  • Create and edit pages, entries, and media.
  • Work with the content editor interface, including dynamic block composition, draft management, and content translations.
  • Preview content in the site builder's preview panel (if the site builder is enabled).

Editors cannot:

  • Create or modify content models, fields, or option sets.
  • Access or edit site builder templates, layout, or assets.
  • Change site configuration settings.
  • Deploy the site or manage hosting connections.
  • Manage other site members or their permissions.
  • Access admin-only entries (unless explicitly granted through customizable access).

The editor role is intended for content creators, marketers, and anyone who needs to work with content without affecting the site's structure or technical configuration.

→ Editor Role

Role Comparison

Capability Admin Editor
Create and edit content Yes Yes
Manage media Yes Yes
Preview content Yes Yes
Create and modify models Yes No
Manage option sets Yes No
Access admin-only entries Yes No (unless granted)
Edit site builder templates and assets Yes No
Deploy site Yes No (unless granted)
Trigger publish actions Yes No (unless granted)
Manage site configuration Yes No
Manage site members Yes No

Customizable Access for Editors

By default, editors have access to all content across all models and languages. When you need tighter control — restricting an editor to specific parts of the site — you enable fine-grained access on that editor's membership.

Fine-grained access is configured per editor. When enabled, the editor's permissions are restricted across four dimensions: models, languages, deploy targets, and publish triggers. Each dimension is independent — you can restrict one without affecting the others.

Models

Controls which content models the editor can access. When model restrictions are active, the editor only sees the specified page models, entry models, and block models in their content editing interface. Models not in their access list are hidden entirely — the editor cannot see, create, or edit content for those models.

This is useful when different editors own different parts of the site. A blog editor might have access to the Blog Post page model and the Author entry model, but not to the Product page model or the Site Settings entry. A marketing editor might have access to Landing Page models and CTA block models, but not to the documentation section.

Languages

Controls which languages the editor can work with. When language restrictions are active, the editor only sees content in the specified locales. They can create and edit translations for their assigned languages but cannot access or modify content in other locales.

This is useful for multi-language sites with regional content teams. A Spanish content team might have access only to the es locale, while a German team has access only to de. Each team works in their language without seeing or accidentally modifying content in other languages.

Language restrictions only apply when localization is enabled for the site.

→ Supporting Multiple Languages

Deploy Targets

Controls whether the editor can deploy the site to specific hosting targets. By default, editors cannot deploy at all. When deploy access is granted through fine-grained controls, you specify which deploy targets the editor can trigger — for example, allowing deployment to a staging environment but not to production.

This is useful when content teams need to push previews to a staging URL without having access to the production deployment pipeline.

→ Deploying Sites

Publish Triggers

Controls whether the editor can execute publish triggers. Publish triggers are automated actions that fire when content is published — webhook notifications, cache invalidations, or external integrations. By default, editors cannot trigger these actions. When publish trigger access is granted, you specify which triggers the editor can fire.

This is useful when certain publish workflows should only be initiated by senior editors or specific team members, while other editors can create and edit content without triggering downstream automation.

→ Automating using Triggers

How Fine-Grained Access Works

Fine-grained access is an opt-in restriction system, not a permission grant system. The distinction matters:

Without fine-grained access enabled, an editor has access to all content, all languages, and no deploy or publish capabilities. This is the default and works well for small teams or sites where every editor works on everything.

With fine-grained access enabled, the editor's access is scoped to what you explicitly configure. Any dimension you restrict narrows the editor's view. Dimensions you leave unrestricted remain fully open.

For example, enabling fine-grained access and restricting only models means the editor sees a filtered set of models but can still work in all languages. Enabling fine-grained access and restricting only languages means the editor sees all models but only in their assigned locales.

Fine-grained access is configured per editor — each editor on a site can have a different set of restrictions. This lets you tailor access to each team member's responsibilities without creating additional roles.

→ Customizable Access

What's Next