Inside Brightspot: The background story on permissions

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.

Let's talk about Users and Roles, aka Permissions, and take a little field trip into the history of these settings. There are major differences between more modern versions of Brightspot, and the first version that many of our customers are familiar with. For the sake of this excursion, let's focus on how permissions worked in Brightspot's 3.0 version.

1. All / Some / None

Here's how Permissions were configured in Brightspot 3.0:

Brightspot 3.0 permissions configuration

When creating a Role, and configuring access to Sites, Areas, and so on, users had the choice of giving permission to All, None or Some. This setting was applicable to tool areas (like Admin) as well as to Content Types.

“All” and “None” are pretty straightforward—one click by an Admin gave a user access to everything or nothing. The “Some” setting is what introduced a certain level of difficulty.

Take that list of Main Content Types in the screenshot above. There are 22 Main Content Types in that list and (not shown) approximately 70 Miscellaneous Content Types. When an admin user selected Some, the default setting was All. The admin user would then have to click within all 22 of those Main Content Types and all 70+ Miscellaneous Content Types, and then decide whether to set it to All, Some or None.

To put it into practice with an actual use case, imagine a role for a photo editor who only needed access to Images, Galleries and Modules. The admin user would need to set access on those three Types to All and then set the other 89 to None. To put it mildly, creating a heavily restricted role meant a lot of clicks.

2. Workflow Transitions

Next, let's take a use case of a Writer role that needed access to only Articles, Blog Posts and Galleries, and the business was using Workflows for those content types. The Writer should not be able to publish any content, only to draft, save and submit the assets to an editor.

Similar to the first use case, the admin user would set all the other content types to Access: None. Then, set Article, Blog Post and Gallery to Some. Then, the UI would expose the workflow transitions relevant to that content type:

Brightspot 3.0 workflow transitions

As you can see, at this step, the admin user would again need to click to select the relevant steps in the workflow — for each content type. Depending on the complexity of the workflow, that added up to a lot more clicks.

3. Content Types and Tabs
Last but not least, let's cover the permission settings in 3.0 that covered Tabs:

Brightspot 3.0 tabs dropdown

Yes, more check boxes.

In my personal opinion, this was one of the harder things to manage in the 3.0 permissions system. In this context, the Tabs in question are the tabs we use on content types to organize the UI.

On an Article, for example, often times those tabs are "Styles" and "SEO." Makes sense in the context of the Article, but in the permissions system, it was a separated—if you weren't sure which content type included a tab of a particular name, it was difficult to reconcile what belonged where.

The other limitation in 3.0 was that this Tab settings area was applied to all content types. So, say a team wanted to remove the Writer Role's access to SEO on Blog Posts, but not on Articles—unfortunately, that wasn't supported. Once the SEO tab was restricted on one content type, it was removed from them all.

How We Improved Permissions

To be clear: I'm not trying to pick on the 3.0 Permissions system here. It got its job done, and it was certainly a useful system.

However, we certainly received feedback from our admin users and product managers (myself included ) who found it difficult to create and maintain these roles.

We listened to that feedback, and the difference in permissions from Brightspot 3.0 and Brightspot 4.0 and into more modern versions is demonstrable. Let's review the latest and greatest product functionality around permissions next.

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 AOL.com, curating a daily experience for millions of users.

Related resources

Companies today are becoming increasingly borderless, meaning it's more common to need multiple sites in multiple languages to support their business. A modern CMS will ensure seamless and consistent multisite management no matter the geography, number of sites or source of original content assets.
See the consequences associated with staying with a legacy CMS and learn how upgrading can boost your bottom line.
When you’re in the market for a new content management system, you can keep your publishers, developers and marketing teams happy by reading this first.
Learn how to approach multi-layered security to protect from external and internal threats.