5 Limitations of SharePoint Approval Workflow

The Approval workflow in SharePoint has been helping teams automate business processes since the days of MOSS 2007 and WSS3.0. It is the most commonly used workflow and since it’s pre-built, SharePoint has done the heavy lifting so your setup time is greatly reduced. However, the Approval workflow can be a bane to many. On one hand, you can be up and running with just a few clicks; on the other, the out-of-box user experience may not be very intuitive for the users.

There’s certainly more than one way to skin this cat, but I find myself repeating a similar series of steps to enhance the experience. I look to document these steps before Microsoft officially upgrades my SharePoint Online environment to version 2013. I hope that, in the process, this post could also be useful to other SharePointers.

Before diving into the proposed solution, let’s first breakdown some of the challenges. Here’s my personal Top 5 Limitations of the SharePoint Approval Workflow:

  1. Inability to specify workflow condition

    Applying workflow through the browser only provides you with the option to either start the workflow automatically or start it manually. You can’t conditionally design a parameter around how the workflow starts. For example, if you want the workflow to run only when a specific type of file is uploaded, you can’t do so through the browser.

  2. Potential governance concern

    Users, who can manually start the workflow, can also change the workflow’s rule and designation. When teeing up a document for an approval, SharePoint allows for ad-hoc update to the workflow logic. Almost every makeup to the workflow (approvers, deadline, etc.) is up for grabs to everyone who has access to run it manually. This open-ended structure leaves you at the mercy of your users, who can accidentally (or not) change the most fundamental elements of the approval, thus altering the orientation of your business processes.

  3. Vague email notifications

    The auto-generated emails from the Approval workflow often lack clarity. Upon receiving the email, users may not know how to move forward because the emails have duplicated info, ambiguous message, and most importantly, unclear instructions on how to approve the document. Users would be notified to “Perform specific activities required” without any other context.

    Outlook integration feature – which could open the approval form from the email and is actually very helpful – gets lost in the mix because the language in the email makes no reference to Outlook. Users are simply instructed to “Use the Open this task button” – a “button” that’s located at the top of the email and is very easy to miss, especially in the Outlook preview pane.

  4. Due Date Duration not accounted for

    There are 2 ways to set approval due dates – you can either assign an actual due date or specify a duration of the approval task. For the most part, the preference should be to set deadlines by duration so you don’t pin yourself down to one particular due date for all documents. Furthermore, should enough time passes by and your due date is in the past, SharePoint will display an error message to the user initiating the workflow.

    Due Date vs. Durations

    Unfortunately, if you were to assign due date by duration, the approval workflow would not account for it. The system generated email would simply assign your due date with “None.”

  5. Rejected document marked as “Completed”

    I saved the best for last, because this one trips me up the most. Receiving an email from the SharePoint library with a subject line of “Approval has completed” does NOT necessarily mean that your document has been approved. Your supervisor could very well have rejected your document and as long as all the required tasks are done, SharePoint deems the workflow as “completed.”

    The body of the email doesn’t help the cause either by repeating such words as “approval,” “successfully,” “completed” to further mislead the user. Only if you were to look carefully, would you see 1 mention of the rejection buried in the middle of the email content. A definite flaw from a user experience design perspective.

Despite these challenges, I still believe that there are a lot of business values provided by the SharePoint Approval workflow. Thankfully, there are a few simple ways to overcome these shortcomings and I look to document these steps on my upcoming blog post.

Do you have other challenges with the workflow that’s been plaguing you? If so, please feel free to share your experience. Hopefully we can all compare notes on the implementation work-around and be more productive at the other end.

[Update: My next post in this approval workflow series is now available. Read the 5 Steps to Enhance SharePoint 2010 Approval Workflow]

Advertisements

3 responses to “5 Limitations of SharePoint Approval Workflow

  1. Good post. These vagaries also bug me!

  2. And we get users who see “Rejected” and take it personally, thinking they have been rejected and not the workflow itself. Ugh.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s