Meet Alice and Bob. Co-workers in a typical office so commonly found in Midwest North America. It has K-Cup coffee, central air conditioning, and maybe even some awards hanging on some walls that were won from another, much larger company. The paint color is conservative. The Girl Scout cookies are in abundance.
Alice is nervous because she asked for time off to visit relatives next week but hasn’t gotten any word back yet on its approval. She sees Bob, her manager, several cubes down cursing at a discontinued printing / fax / scanning machine. She wonders what happened to her request. She wonders if she submitted it too late to be approved. She even wonders if Bob dislikes her. Amid all this wondering and worry, Alice doesn’t know, can’t know, that Bob already approved the request yesterday. She doesn’t know that the two of them are inadvertently bound up in a place where fate and computational catastrophe meet. Its a place we call…..the SharePoint Designer Zone. <music/>
So what we’re talking about here is a simple Time Off Request workflow created with Microsoft SharePoint Designer (SPD). It involves a calendar list that is configured for content approval, item level permission settings, some custom columns, and all authenticated users have Contribute rights. When new items are created in this list, the workflow generates a customized Task item in a separate list. A manager is assigned to the task item and he or she receives an email alert when it is created. The task uses a simple form with radio buttons to signify if the request is Approved or Rejected.
The SPD workflow will then set the actual calendar item to either Approved or Rejected based on this value. If you Google "sharepoint designer workflow time off", the #1 ranked result follows this method.
If your SPD installation and MOSS servers have been updated within the last six months or so, you will quickly find that this type of workflow will fail. Specifically, it fails as soon as the manager sets the radio button to "Approved" and clicks "Complete Task". No notifications are sent. Nothing happens. The process breaks down.
It underscores a very important concept about the security model SPD uses. Essentially, SPD workflows operate under the security context of the user who initiates them. This was introduced way back in Service Pack 1 and is pretty well covered in a blog by the SPD team. Unfortunately for the uninitiated, identifying the nature of security problems can be a little difficult. Inspecting the (hidden) workflow history log, one will typically see something like this:
The System Account in this case is SharePoint impersonating the user, Alice. That’s right, Alice. Despite the fact that Bob (who has Approve permissions to the Time Off request calendar) updated the task and carried the workflow forward, the SPD process still operates under her context, not his. Since Alice does not have Approve permissions to the Time Off Calendar (of course!), the workflow cannot set the item status to Approved or Rejected.
Some SPD activities do elevate permissions to do things. For example, in this configuration Alice does not have any rights to the Tasks list but the task is generated and ownership is assigned just fine. And it is possible to write custom actions for SPD that elevate permissions, if necessary. You can even find some handy custom activities up on Codeplex to help navigate item level security.
But the point I want to stress here is the following: Never architect your workflows using administrative or high-privileged accounts. Build your workflows from the ground up keeping real people and the entitlements they are supposed to have in mind. Test early using low privileged accounts and log your activities to the workflow history.
