This post is a continuation of my two-part series on role and workflow strategy. To read about role strategy, please read part one.

In this post, we will discuss a few ways to optimize your workflow to save potentially hours of your life. If you are unfamiliar with states, commands, and actions in a workflow, please read the Workflows and the Workbox Sitecore documentation first.

Rhombic Networks

Introduced in part one of this series, the fictional company Rhombic Networks has 10 employees, but our focus is on Anne, the content manager and Greg, a content editor. Their existing workflow is very basic (Figure 1), which is good because “keeping it simple,” is a well-known best practice. They do suffer from a few issues:

• Greg submits news articles for approval but often wants to make a few more edits. To do this, he has ask Anne to reject his article so he can make the changes and resubmit.
• Some stakeholders request that Anne show them the articles before they are pushed live. To do this, she takes screen shots or physically walks over to their desk with her laptop.
• Anne’s role at Rhombic consists of more than just being a content manager in Sitecore and she’s constantly on the phone and interrupted. Occasionally, an approved article is inadvertently not published.

The Optimized Workflow

We can make this workflow work for us by reducing the touch points required and manual publishing issues. Let’s work backward and look at the end result first.

The few additional steps, added permissions, and automatic publishing will reduce “rolling your face on the keyboard” by 1000%. It’s scientifically proven.

Let’s take a look at each addition in more detail.

The Recall Command

As mentioned before, once Greg submits his articles for approval, he needs to ask Anne to reject his work to make additional edits. The recall command solves this issue by allowing Greg to bring the article back into the Draft state where he can edit it. Figure 3 shows the recall command visible for Greg when the news article is in Awaiting Approval state.

Auto Publish

When Greg submits articles for review and they are moved to the Awaiting Approval State and are automatically published so shareholders can review it. This can be achieved by publishing items to a preview publishing target. The Sitecore documentation will walk you through preparing your publishing target, but we will still want to configure an automatic publish. Note the parameter called targets in our Auto Publish to CM command is set to “preview,” as seen in Figure 4. Preview is the name of Rhombic’s publishing target.

Similarly, when Anne approves content, it will automatically get published to production. Configuring the Auto Publish to Production command is essentially the same, except we would change the targets value from preview to web, the name of Rhombic’s production web database.

Permissions

As an Editor, Greg should be able to submit content for review and use our fancy recall command. Other options should not be accessible to Greg’s role. Using the Security Editor in Sitecore, navigate to your workflow. In our case, we are navigating to Rhombic Networks Workflow. Selecting the custom Rhombic Content Editor role via the Account icon, we set the following permissions (Figure 5).

To ensure that Greg does not have access to see the Approve and Reject commands, it is important to make sure the Workflow State Write permissions do not have apply to descendants as indicated in Figure 6. With the Awaiting Approval state selected, this dialog can be accessed via the Assign icon in Figure 5.

Anne should have access to the Approve and Reject commands in the Awaiting Approval state. We apply these permissions to our Rhombic Content Manager role (Figure 7). Again, make sure that Workflow State Write on the Awaiting Approval state does not have Descendants checked.

The End Result

With properly configured permissions, Greg and Anne’s roles now have the appropriate access to their respective workflow commands.

Illustrated in Figure 8 and 9, Greg’s options in both the draft and awaiting approval states.

When Anne views items in the Awaiting Approval state, she sees the following (Figure 10).

During our permissions configuration, you may have noticed we did not add any explicit denys, instead, we only granted access. This is by design.

Let’s say Anne is going on some well-deserved dream vacation and spend A Week in Peru. Greg has volunteered to cover for her. Since sharing credentials would be a security no-no, we simply add Greg to the Rhombic Content Manager role in addition to his existing role.

Because we did not add explicit denys, there are no permission conflicts and Greg has access to all of the commands. To illustrate this, Greg’s Awaiting Approval state commands can be see in Figure 11.

This is the power of properly designed roles and follows role recommended practices as described in part one of this series.

Recommended Practices

Keep workflows simple. Sitecore prides itself on how extensible it is and you can absolutely make a very complicated workflow, but please avoid if possible. Managing your business process in Sitecore workflows can become an expensive maintenance task for the development team, especially if you have fairly fluid requirements. If you push a lot of content through your Sitecore environment, consider a DAM (Digital Asset Management) product. Sitecore’s DAM product is Content Hub.

Create role-based accounts. It is ok to have multiple Sitecore accounts for different tasks, however, you can be a member of multiple roles as we’ve seen here. As indicated in previous posts, I consider a separate account a requirement if you are doing Admin tasks and content editing. Do not edit content using an admin account. Period.

Don’t overuse email notifications. Creating email notifications can be useful. Adding too many can become unnecessary noise. If your role involves logging into Sitecore multiple times daily, email notifications are likely just that.

Stay tuned for an article on publishing strategies.