For the last week now, Michael and I have been struggling with a very persistent workflow issue. An approval workflow that we have created, works fine when it’s started by an administrator, however when it started by a regular user, then the approval process won’t work. The workflow is activated with the permissions’ of the user that started it, not the permissions of the approver or the author. It isn’t currently an issue for the work we’re doing, but it will need to be fixed for use in a real world environment. Googling the problem didn’t seem to help, there were too many vague “fixes”, that required complicated multiple workflows that never seemed to work. There didn’t seam to be a solution to this problem anywhere on the internet. However, I then remembered that someone gave me a large SharePoint 2010 book as a “congratulations for getting the job”, so I decided to see if I could find a solution in there. The solution showed itself almost immediately.
The answer is: High-Privilege Workflows. I found this solution to be extremely easy carry out, and it solved our workflow problems 100%. A high-privilege workflow runs with the permissions’ of the person who created the workflow. While editing the workflow, you simply click in the area just below the first step, go to the “insert” section of the ribbon bar and click “Impersonation Step”. This adds a new step into the workflow that carries out the actions within it using the permissions of the workflow author.
I find it embarrassing that the solution was so simple, however I thought I might write a post about it, incase any others users were coming across the same issues.
Work on the holiday approval workflow has continued over this last week. We have been adding more and more actions into it, just to see what we can accomplish. We described our workflow to Dave in out monthly review meeting, and he metnioned other features that should be implemented.
Previously, the workflow calculated how many day’s the user’s holiday is, taking into account half days, and input this into a calendar. To make this workflow more intelligent, and useful, I set up a list that would contain the name and department of each member of staff, with a number of how many days of holiday they have left. Before editing the workflow, I created a custom data view of the list, showing only the members of the Online Services team. This feature was requested by Dave as he wanted to see how many holiday days each member of his team had, and creating a list for this data appeared to be one of the only ways to implement it. This method isn’t entirely desirable, as each time a member is added to the Sharepoint site, they also need to be added into the “Holidays Remaining” list. Another issue that has been raised is that, the “Days remaining” field will need resetting every year, and as of yet we do not yet know a way of resetting every feild at once with a single workflow.
We then incorporated the workflow with the list, getting it to subtract the holiday from the “Days remaining” field. We have found with this particular workflow could easily spiral out of control, there will always be something else to add to improve it and get it to do more. This will most likely be the same for a lot workflows, you just have to find a good stopping point.