SharePoint Expert Blog
By Russ Edelman, President at Corridor Consulting
February 08, 2011 - 12:30 AM
Greetings AIIMers,
Hope your year is off to a good start and it’s nice to be back on the AIIM blogging scene once again. I’ve got a bunch of experiences and information I’ll be sharing with you once again; however, for this week’s post, I wanted to dive into a technical issue related to SharePoint Designer and Workflow.
Imagine for a moment that I have had the opportunity to dig deep into the creation of a SharePoint Designer 2010 workflow (reusable or list based – doesn’t matter in this case). And imagine that it is for a global company with over 80,000 employees and one that globally embraces SharePoint 2010.
The Situation (Not as in the guy from the Jersey Shore):
I created a very complex workflow that actually required three separate workflows for a variety of reasons; one for each primary list involved in the project; a Forms Request library, a Document Library to hold contracts and the Task List. Security was critical for this particular project so it was important to allow limited access to add contract requests and once entered, the request, the contract and supporting documents (stored in a document set – yes they are valuable!) and the tasks would require a dynamic setting of security.
Using SharePoint Designer’s new Impersonation Step capability in SharePoint Designer, the concept of setting security was a slam dunk and shouldn’t have taken more than a few hours to configure this portion of the workflow. For those unaware of the Impersonation Step, it allows the workflow to impersonate the author of the workflow (make sure the author has appropriate rights) and then additional security actions are made available. For example, you can add, replace or remove people/groups from the security of an item. Very cool stuff considering it wasn’t in SharePoint Designer 2007.
Well, I did the work and it worked perfectly! Let me stress…perfectly! And then something happened and it stopped working so perfectly. In the end it was simple; however, getting to the end was inappropriately time consuming.
The Resolution (New character coming on to the Jersey Shore):
First, the problem manifested itself as I added more logic into other sections of the workflow which had nothing to do with the security declarations in the impersonation step. With no relationship or dependency what so ever in this new logic, it was perplexing. After adjusting security at the list levels and testing on a number of fronts, I ruled out any issues with the security. I tested variable definitions to ensure that I was using the right values for the people and groups and still, the problem persisted with these adjustments. Finally, I placed a bunch of logging or break points into the progression of the workflow by using the Log action. This helped isolate the problem further. Ultimately, I figured it out when recognizing that the process is not always necessarily synchronous and in fact, it is asynchronous. More specifically, the workflow ran so quickly that the creation of the document set (which was in the workflow as well) did not happen quickly enough. When the security portion of the workflow kicked in, the document set was not yet created and I received the error condition. By inserting a 1 minute pause into the workflow with a standard SPD Pause Duration Action, the issue was resolved.
One other pointer – when using security in the impersonation step, there is no way I found to date which allows the workflow to declare security for multiple users/groups from a variable. I confirmed this with a few other SharePoint Designer junkies and they could not provide any other insights. To circumvent this issue, I had to limit the number of users (via prompt/instruction) to 10 users in the InfoPath form that served as the source for defining the users and then the form included a function to parse out each login ID. These were then stored separately in unique variables in the form and then metadata. It was painful and clunky and had we been able to write a quick action and package it as a WSP, we could have avoided that issue completely and made it much more elegant and without any type of limitation.
If technical tips like this help, please comment accordingly. I’ll bounce between SharePoint tech tips and SharePoint strategy.
Have a great week!
Russ
This post and comment(s) reflect the personal perspectives of community members, and not necessarily those of their employers or of AIIM International
