Workflows are essential to the content author experience in Sitecore. Along with security, they determine when (and by whom) content can be edited as well as identify when it is ready to be published.
Outlined below are steps to reproduce NLC’s typical workflow security implementation. It focuses on flexibility, ensuring content authors can access multiple workflows and workflow states through the addition of roles to their profile. This implementation may not meet your exact needs, but it is a good starting point to consider.
For the purpose of this post, I will not be focusing a content author’s security access on the underlying item going through workflow, but instead I will focus on the security implementation on the workflows and workflow states themselves. It is important to note however, that a content author must have both write access to the content item in workflow as well as the workflow state the item is currently in before they can edit an item.
|
Governance plays a critical role in any Sitecore deployment Learn more about Best Practices for Sitecore |
My Goal:
As a content author who is a member of the WFEditor role (created for this walkthrough):
- Secure the workflows in the build so members of the WFEditor role can see the Sample Workflow only.
- Secure the Draft state in the Sample Workflow to allow members of the WFEditor role to see items in that state.
Setup:
In addition to creating the WFEditor role, I’ve created a new workflow named Test Workflow which I will use with the out-of-the-box Sitecore Sample Workflow to illustrate the changes to the content author experience as the security changes.
Security Implementation:
1. As a member of the WFEditor role and without changing any Sitecore security, you can see all workflow states and both workflows in the Workbox.
2. The first step is to secure each workflow so that the workflows do not appear in the in the Workbox by default. You do that by securing each workflow via the sitecore\Everyone role.
3. The result of this security change is that a WFEditor role is no longer able to see anything in the Workbox.
4. Now that the role can’t see any workflows in the Workbox, go ahead and apply read permissions on the Sample Workflow itself so that the WFEditor role can see the workflow in the Workbox. There is no need to further change the Test Workflow security settings since the main goal of removing the content author’s ability to see it listed in the Workbox has been accomplished.
5. You may have noticed in the screenshot above that the Descendants have been denied read permissions. The reason for this is simple. Our scenario requires that the WFEditor role must have read access to only the Draft state, and not the other states. Granting read access to the Descendants would mean members of the WFEditor role would have read access to all workflow states.
6. The WFEditor can now see the following in their Workbox.
7. The next step is to grant the appropriate security access on the Draft state.
8. As a result, the WFEditor role is able to see and use the Sample Workflow Draft state.
Conclusion:
With the above scenario, we’ve secured a single role to a single workflow state without using security settings to explicitly deny the role access to any of the other workflow states. This is important. It means that this process can be repeated for additional roles across multiple workflows and workflow states. In the end, adding any of these roles to a content author’s profile will grant them access to those workflow states, ensuring that there is never a situation where deny permissions in one role overrides the grant permissions of another.
