When Sitecore is installed for the first time (complete with that New CMS smell) there are as many as 35 out-of-the-box roles available. Roles exist to allow administrators to assign access rights to different groups of users, which simplifies many things including user maintenance and security. Users can be assigned to more than one role, and this system of organization streamlines the content management process by allowing access to certain portions of content and functionality on the needs of the team.
Sometimes, though, the need arises for a role that isn’t sitting at the established “cool kids” table.
Modifying the inheritance of the predefined roles is a big no-no. I mean, you CAN do it, in the same way that you CAN stick a key in a light socket, but it’s far from recommended.
Sitecore may make slight modifications to default roles and permissions in new releases of the product, and if they do then either A) your inheritance modifications will be erased or B) your permissions might not work as expected. Either way, it’s going to be messy. It’s best to avoid the hassle by not touching the predefined roles in the first place.
Since you’re not going to modify the predefined roles, another solution (see what I did there?) is needed. And boy do I have good news for you. You have the option to create…
Custom Roles are easily produced using the Role Manager, located in the Sitecore Control Panel. By default, a Custom Role is nothing more than an empty container. Think of it as your blank canvas for applying permissions. You can choose to define your own permissions, or inherit from Sitecore’s pre-defined roles, or both. It’s really up to you. The point here is that you are creating roles specific to your users’ needs without modifying the inheritance of the pre-defined ones.
This is especially useful if you’re in charge of a larger team of content editors. It also comes in handy if you want to create a streamlined editor experience. A highly-scientific survey that I conducted by walking around the office and talking to my coworkers reveals that two or three Custom Roles is generally a good starting point, but that too is dependent on your solution. If you have a multi-site instance you may have roles for each website and that’s fine too. Regardless, Custom Roles should be set up within your solution before any editor touches it. From start to finish, it’s about maximizing efficiency.
With Custom Roles you can hide entire sections of the tree from users; which can avoid issues further down the road by giving editors access to only what they should see and use. Custom Roles are a Cloak of Invisibility, to be shared at the discretion of the administrator. Feel the power.
A blog is a perfect example. If you want three people in the company to have access to the blog and ONLY the blog, you would create a Custom Role titled Blog Author and then assign those three specific editors into that role. A word of caution here: You’ll generally want to avoid assigning permissions to directly to a user account. Even if it’s a single permission change, you’re much better of assign that permission to a role and assigning users and/or editors to those roles. This is a good idea even if the role is only intended for one person. And another word of caution: setting explicit DENY access on a role is a pretty powerful thing. It cuts across all inherited roles like butter. Instead, consider breaking inheritance, which is neither as ominous nor Victorian as it sounds. Breaking inheritance resets all permissions to their default state, allowing you to deny access in a way that can be overridden by another role, whereas explicitly denying access means that you can never override the denial.
That leads into my final point. As with almost everything in life, Custom Roles come with a downside: they add complexity. Creating several very granular custom roles can lead to unanticipated extra work; changing those roles down the road because you didn’t anticipate certain editors needing access to various items will bog you down. Creating Custom Roles can be extremely useful, but it gets complicated in a hurry. Before implementing custom roles you want to map out all your use cases and think them through as thoroughly as possible.