Publishing access starts with roles

As more people work on your site, publishing access becomes less about who can make changes and more about who should be able to send those changes live.

For example:

• A content editor might need to publish CMS content without publishing the full site
• A designer might need to publish to staging for review, but not to production
• A regional marketer might only need access to a handful of landing pages

Webflow lets you shape that access using site roles, publishing permissions, and granular access controls.

Start with the role

A site role defines the kind of work someone can do in Webflow.

Common contributor roles include:

• Reviewer: Review designs and leave comments
• Content editor: Update content, images, and CMS items
• Marketer: Build and edit pages using components
• Designer: Design with classes, components, and interactions

A role gives someone their baseline level of access. Publishing permissions determine which of their changes they can send live.

Reviewers can review and comment, but they can’t publish. For other roles, publishing access depends on how your team has configured their permissions.

Customize publishing access when you need to

Enterprise teams can use custom roles to give people more specific publishing permissions.

For example, you can control whether someone can:

• Publish the full site to staging
• Publish the full site to production
• Publish a single page to staging
• Publish a single page to production
• Publish CMS items to production
• Queue CMS items for a future publish

That means someone can have the access they need to do their job without automatically getting every publishing permission available to their role type.

Say a content editor should be able to publish CMS items, but not the full site. You can give them the CMS publishing permission they need without also giving them full-site publishing access.

Or maybe a designer needs to test work in staging, but production publishing should stay with someone else. You can allow staging publishing without also allowing production publishing.

Narrow access even further

Publishing permissions control what someone can publish. Granular access controls help determine where they can work.

‍

For example, a regional marketer might only be responsible for a handful of landing pages. You can limit their page access to those pages, so they can work within their assigned area without editing the rest of the site.

The same idea applies to CMS Collections. A content editor might have access to only the Collections they manage, while other CMS content remains read-only or unavailable to edit.

Together, roles, publishing permissions, and granular access controls let you shape access around the way your team actually works.

Give people only the access they need

A useful way to think about publishing access is:

That matters because every publishing workflow in the rest of this course — staging, single-page publishing, CMS publishing, and full-site publishing — depends on the permissions behind it.

Feeling good?

Next, you’ll take a closer look at staging and how it gives your team a checkpoint before changes reach production.