The following is a guest post written by Candace, a colleague of mine who is also a part of the Perficient Sitecore Competency Center.
Initially, I found setting up a workflow in Sitecore confusing and frustrating. I hope this article helps you avoid some of that frustration. Chapter 3 of the Workflow Reference is fairly clear until it covers Security. So I won’t cover setting up the workflow in detail, but will concentrate on the security aspect of it.
Our workflow, “ContentSubmissionWorkflow”, has only 3 levels, or States, and is similar to the Sample workflow that Sitecore provides. The first State allows a Content Contributor to submit work to an Approver. State 2 allows the Approver to approve or reject the work. The third state AutoPublishes any approved content.
Our 3 States are Editing, AwaitingApproval, and Approved. Under each state are Commands. Under the Editing state, the content contributor can Submit. Under AwaitingApproval, the approver can Approve or Reject. Finally, under the Approved state, there is the workflow Action of AutoPublish. Each of these States, Commands, and Actions are chose from Templates/System/Workflow.
Let’s configure the security on each state and action mentioned so far. The Editing State and its Submit Command must be accessible to anyone who can edit the content that the workflow is associated with. For purposes of this article, we have only 2 users: Submitter and Approver.
Choose the Editing state of the workflow. Follow these steps:
- Choose Security from the top menu.
- Click Assign in the Security chunk.
- Add Approver and Submitter to the Roles or User Names box.
- In the Permissions section, click Workflow State Delete and Descendants. Click Workflow State Write and its Descendants. Click OK.
Now repeat the process with the Submit Command, but on this one, in the Permissions section, just click Workflow Command Execute and its Descendants.
Follow the exact same process with the Approved state and its AutoPublish command because both the Submitter and the Approver need to publish their work. If you don’t do this, you’ll find that the workflow “hangs” – it’s never completed for the user who doesn’t have access to it, and that user will not be able to edit the content that is still “hanging” in the workflow.
What about the AwaitingApproval state and its commands? Here, we only want the Approver to have access. Otherwise, the submitter would be able to approve her own work. So on this State and its commands, follow the same process as the Editing State and its command, but only assign the Approver and not the submitter.
So we put this workflow in place and the initial reaction to it was quite positive – until the Approver realized that she had to go thru the tedious process of submitting her work, then going into the Workbox and approving her own work. She wanted the workflow but she herself wanted to skip directly to the Approved step. That brings us to the one Command we haven’t discussed yet. Under Editing, there is a DirectApprove command. This command allows the Approver to skip directly to the Approved step if it is configured properly. Here are the 3 simple steps to make that happen:
- Click on the Submit step -> Security-> Assign and remove the approver from its Roles or User Names
- Add the DirectApprove Command and set its Next state property to the Approved State
- Click on the DirectApprove Command -> Security -> Assign, add Approver as a user and click on the Workflow Execute Command and its Descendants.
Voila! The Approver has her wish – she jumps directly from Editing to Approved.
That’s great, she said. But now I want an email to be sent to me whenever someone submits content and I want to notify them via email that I approved or rejected it. Ah, users. They always want more. That’s a post for another day.