As a refresher, a workflow in SharePoint 2010 can have within it one or more approval processes. It is the approval process itself, contained within a workflow, that is the subject of this article.

Recently we had an interesting request from a client: to create a three step approval process for documents within a single SharePoint 2010 document library. The idea was that a group of users would upload a documents and then, after reviewing it for accuracy, approve the document to another group of users for review. Let’s call the first group Level 1 users and the second group Level 2 users. The Level 2 users then had the option to accept or reject this document. Approval of the document would send it to Level 3 users for approval. Rejecting the document would send it back to Level 1 users, who would then rework the document and send it back to Level 2. The process continued up to Level 3 users.

How we set up these multiple levels of approval is the subject of another article. However, the Level 3 users didn’t have it so easy. When a Level 3 user receives a task to review a document approved by a Level 2 user he or she still had the option to accept or reject a document. However, sometimes a document, if approved, must be sent to a new team of users (let’s call them Auditors) with their own document library and approval process. So the approval process at Level 3 needed to know how to differentiate between a simple approval and an approval which required a document to be so routed.

This means Level 3 users needed a way to mark a document as Approved, or Approved and Send to Audit.

Figure 1: Approval Screen


As you can see from this Level 2 example, we have the options Accept, Reject, Cancel, and Reassign Task. Accept and Reject are our two main options, but we also want to have the option to approve this document and send it on to the Auditors. Obviously canceling the task isn’t the proper way to get this done. We can’t reassign the task to the auditors because then Level 3 users wouldn’t be approving the document. They’d be passing the buck on to the Auditors and this isn’t the business process we want.

What we have to do is add a button for this approval process to go along with our standard approval, which is not supposed to send the document forward. Once we create the button, we need to update the approval process to accept input from this third button.

If you’ve worked with Workflows before in SharePoint 2010 chances are you’re familiar with SharePoint Designer 2010.  In our example we’re using a list workflow on a document library named Library01.  Within our workflow we’ve created an approval process called “Approval Process at Level 3”.  For completeness sake, I’ve included a screen shot of the workflow below:

Figure 2: Workflow


This workflow runs as an impersonation step for reasons outside the scope of this article, but I will be discussing this in a forthcoming post.  For our purposes, impersonation is not required.

After setting up the approval with the proper users, the approval process screen will have a Customization section and a Task Outcomes section.

Figure 3: Customization screen



Figure 4: Task Outcomes



We’re first interested in the Task Outcomes section.  We need to add a third outcome, which would be approving for audit.  You can do this by clicking the NEW button.

Figure 5: New Outcome


You can see Outcome 1 is highlighted for you. The NAME column is the value a task outcome variable can take.  I’ll name mine “ApprovedAudit”.  Type in your variable name and press enter.  Then single click on the text “Outcome Button 1” and it will highlight and allow you to type in the text you want to appear on the button for this outcome.  Type something like, “Send to Audit”.

You may have noticed at this point that your new entry is Sequence 3.  There appears to be no way to change the order of these sequences.  Normally you would want the two approvals to appear next to each other instead of Approve, Reject, and Send to Audit.  My workaround for this is simply to overtype the Sequence 2 selection with my entry and then remember to put the rejected option as the new out come.  Make sure you get the Name column right; this is where outcome variable values come from in the Approval process.  You’ll see that next.  For now, I’m going to go ahead and leave my new entry as Sequence 3. This is what the Task Outcomes section looks like when I’m done:

Figure 6: New Task Outcome Created


I now have my three buttons, two stock and one custom.  I just need to wire them up in the workflow approval process.  In Figure 3 above you’ll notice in the Customization section a link for “Change the Behavior of a Single Task”.

When you click here, you will see sections for “Before a Task is Assigned”, “When a Task is Pending”, “When a Task Expires”, etc.  You are interested in “When a Task Completes.”

Figure 7: Approval Process



Notice here that there are two task outcomes, “Approved” or “Rejected” that are stored in Current Task:Outcome.  Remember Figures 5 and 6?  The enumerated values of Current Task:Outcome arise from the Task Outcomes section of your approval process.  We added “ApprovedAudit” as a new outcome for our task.

In my example there is a reference to an ApprovalLevel column in the library which is being modified.  Again, I’ll get into this more in another post on multi-level approval processes.  The point here is I need to wire up the ApprovedAudit outcome to an action, and that action will be to copy the document to the Auditor’s library (Library02) as well as doing a normal approval.

Figure 8: Approval Process Finished



As you can see in Figure 8 above I simply added an else-if branch check to see if Current Task:Outcome equals “ApprovedAudit”; and if it does, all the instructions for “Approved” are completed plus the additional copy instruction to Library02.

Once you publish your new workflow, this is what the task should now appear like:

Figure 9: Send to Audit


Like this post? Share it!