Inside Brightspot: Understanding the permissions system

Watch: A guide to permissions and roles management
Brightspot's roles and permissions capabilities allow for granular access control through an intuitive UI, making it easy for even non-technical admins to configure the settings.
0:00 / 0:00
Video Companion

Every so often, our Vice President of Product shares an email with the company that tells the background story on why Brightspot’s features are the way they are. Not one to keep secrets, we’re sharing her insights with you here, in a series called “Inside Brightspot.” From creating users and permissions to knowing the difference between different dashboard widgets, this series will answer the questions anyone who publishes digital content has likely pondered.

In a previous edition of Inside Brightspot, I covered the historical versions of our permissions system, and highlighted some of the challenges that admin users brought to our attention. With that background in mind, let's review the current generation of permissions functionality.

screenshot Brightspot CMS's permissions interface

1. All / All Except / Only / None

Older versions of the Brightspot permissions system were built around the idea of giving users access to All / None / Some. That worked well, so we maintained that capability, but expanded it to increase its flexibility.

Obviously, we kept All and None—those were easy, one-click adds. Then, we expanded Some into additional options, which are Only and All Except. Those settings effectively solve the challenge of opting in or out of the majority of something.

Some example use cases:

  • A team has a Role that needs access only to two of 10 sites the business operates in its multi-site implementation of Brightspot. Under Sites, an admin user would add an Only permission and include just those two sites.
  • A team has a Role that needs access only to Images, Photo Galleries and Tags. Under Types, an admin user would add an Only permission and include only those three content types.
  • A team has a Role that can have access to everything in the CMS, except for a few sensitive content types. Under Types, an admin user would add an All Except permission and include the types that Role should not have access to.

As you can see, with adding the additional Only and All Except settings, admin users now have a simpler creation and maintenance process for management of Roles.

2. Workflow Transitions

Next up are Workflow transitions, and again, we applied the same All / None / Only / All Except capability here. Again, when admin users are configuring Workflow settings per content type, it's much simpler to configure.

Some example use cases:

  • If a Role needs to have access to take every Workflow action on the Article content type—except for Publish—the admin user would simply use the All Except option, and include Publish, which restricts that Role from ever seeing the Publish button.
  • If a Role needs to have only permissions to Save and Submit on the Article content type, but no other steps in the Workflow, the admin user would use the Only option, and include Save and Submit.

Again, the driving force here is that we wanted to make it simpler and faster for Brightspot admin users to create and manage Roles.

3. Content Types and Tabs

Last but not least, we also applied the All / None / Only / All capability to content types. So, for our user group that needed access only to Images and Galleries, you can select Only, then those two content types, and off you go.

In addition to restricting the content types themselves, we also offer a deep well of permission settings per content type. Let's go into a bit more detail about these permission settings as well because teams can get really creative thanks to these options:

  • Type: The options here are Content Type (things like Article, Gallery, Modules, etc.), External Types (Getty Images, AP Images, etc.) and Other Types (for types that don't display in the CMS UI).
  • Form: Remember Content Forms? This is where admin users can associate a Content Form with a given Role. For example, pretend a team wants to remove the SEO area on Images from the photo team. In this case, the admin user would first create a Content Form that hides the SEO area; then, the admin user would associate that form here with the Photo Editor Role.
  • Read-Only After Publish: This is an important setting for large publishers—this setting restricts a Role from being able to make changes to content that is currently Published on a site.
  • Actions: These are the specific workflow actions that were covered above.
  • Content: This is where maximum flexibility comes into play. To start, an admin user can select All / None / Some / All Except—and then configure a very specific subset of content for this Role. A great use case is a large publisher who has the Section content type, but wants the News Role to have access to News Section, and the Entertainment Role to have access to the Entertainment Section. Think of this as a way to further refine the content type permissions dynamically.
image of Brightspot employee Meredith Rodkey
About the Author
Meredith Rodkey is VP of Platform Product Management & Solutions at Brightspot. She has focused on product management for nearly 10 years, contributing to major Brightspot engagements from U.S. News & World Report to Arizent and Healthgrades. In her previous life, Meredith worked as a homepage editor and writer for, curating a daily experience for millions of users.

More from Brightspot