In this series, we will discuss role configuration and how to create a simple, optimized workflow.
Rhombic Networks
Rhombic Networks has 10 individuals that make up the content team – 1 content manager, 4 editors, and 5 contractors. Anne is the content manager and is responsible for validating the quality of the content and publishing it live. Her account is the only one with the ability to send back content for edits or to publish approved content to production. Greg, an editor, is Anne’s backup when she is not in the office and has her login credentials for those situations. Sometimes, Greg will log into Anne’s account just to reject content so modifications can be made. Greg would prefer to use his own account because of the audit trail, but attempts to copy Anne’s permissions to his account have caused issues in the past.
Recently, Anne found herself missing insert options before a major launch. Rather than fixing the problem, a developer makes her a Sitecore admin to get around the issue. This poor solution remains in place.
Rhombic suffers from the following major issues:
- Users are sharing credentials
- Content user is a Sitecore admin
- Lack of proper use of roles
The key to an easily managed workflow strategy relies on three properly configured factors:
- Roles – applying permissions to roles, not users
- Inheritance – for a structure of roles and permissions
- Avoid deny permissions – avoid if at all possible
Roles
Sitecore comes with no shortage of roles out-of-the-box, such as author and designer. Instead of applying these roles to your users directly, custom roles can be created for each group of editors. For example, rather than applying the author and designer role to every new editor, simply apply your new custom Rhombic Content Editor role as seen in Figure 1.
Notice the Rhombic Content Manager role inherits Author, Designer, and Sitecore Client Advanced Publishing. If a new content manager were hired, we would simply put them in the Rhombic Content Manager role.
There are other roles for users who need to access things like analytics or marketing automation. The security roles documentation provides a full description of each out-of-the-box role.
Rhombic only requires a couple of editor roles, however, your organization might need a more extensive set. Regardless of how complex, we can extrapolate out the roles even more for easier role management.
Inheritance
Just as we simplified adding roles to users, we can now simplify the complexity of roles through a concept called inheritance.
Hypothetically, let’s say Rhombic needs to create 20 new roles. Each role would need to be a member of both Author and Designer. This would be extremely tedious. Instead, we can identify the commonalities between all roles and create a base role called Rhombic Base Editor.
As indicated in Figure 2, all roles can be a member of Rhombic Base Editor. Users are only members of the top-level roles and indirectly inherit Author and Designer.
Figure 3 illustrates how Greg, who is in the Rhombic Content Editor role, inherits Rhombic Base Editor which includes Author and Designer. To reiterate this, Greg is only a member of the Rhombic Content Editor role.
So where did the roles in green come from? Well, those are actually inherited by the Author and Designer roles. You were already using inheritance without knowing it! Figure 4 illustrates the full inheritance – the green being the out-of-the-box roles.
Avoid Deny Permissions
To understand the reasoning behind this recommendation, let’s consider the following scenario.
- A News Editor role can edit news articles. The content tree is visible excluding the product catalog.
- A Product Editor role can edit products. The content tree is visible excluding the news articles.
Assume the explicit denys are set directly on each role against this recommendation. Sam, a new hire, will need to edit news and products. He has been assigned to both the News Editor and Product Editor roles. What happens? Sam can not see either news articles or products because of the combined deny permissions from each role.
One not-so-great solution is to set deny permissions on dedicated deny roles.
Applying the restrictions to deny-specific roles, Product Editor DENY and News Editor DENY, rather than directly onto Product Editor and News Editor, Sam now can fulfill requests for both as illustrated in Figure 5.
Separating grant and deny permissions is definitely recommended if you must have deny permissions, but I challenge you to achieve the same result without them.
Using the security editor, we can do this by breaking inheritance on the news and product items (Figure 6) on the Content Editor role.
Then, we will create additional roles specifically granting access to both news and products (Figure 7).
While we can’t discuss roles and workflows without permissions, there are already a plethora of other resources covering this topic in-depth.
Role Recommended Practices
Identifying Custom Roles
I typically use the company name, in this case, Rhombic (Figure 8). This way they are easy to search, stay together alphabetically in the role list, and are easily distinguishable from the out-of-the-box roles.
Naming Roles
Unlike pretty much everything else in Sitecore, roles are not item-based. This means you can not change the name after it has been created. The name is stored as a string and any permissions you set on items will be tied to this string you initially created. For example, if you accidentally name your role “RhombiK CoNtent EdiTer,” you will need to make a new role with the proper spelling, and any security work you have done will need to be reapplied to this new role.
Sitecore Admin Account
While this post is not specifically about security, I feel a responsibility to quickly make note of this common issue. I often find instances where all users have been made Sitecore admins. This is an unfortunate result of a poor security and rule implementation. Let’s do better!
There is a basic rule I follow: Admins do not touch content. Sitecore admin accounts should be reserved for admin functions. If your responsibilities span both roles, then create two accounts. For example, Anne’s main account is used for editing and approving content, but she has a second account called AnneAdmin to run reports and such.
As a Sitecore admin, you can bypass workflow. This means if you make a change to the homepage, a new version is not created, your changes are immediate, and you likely have lost the content prior to the change permanently. The point being, Admin mistakes are dangerous, and making everyone an admin is reckless.
Check out Sitecore Role and Workflow Strategy: Part Two to see how we can apply these role strategies to an optimized Sitecore Workflow.