I spent far too much of yesterday fighting with SharePoint workflows… including trying to cancel some that have run away on a list with almost 400 items in it…

Some idiot (initials MW) created a workflow to auto-populate a column based when a record was created or updated. Then, thinking that was successful, he created another one to update a different column. He was so pleased with himself that he didn’t stop to think of the consequences of one workflow updating an item, which would then trigger another workflow because the item had been updated… the resulting event from which would then trigger another workflow… and so on…

The long and short of it, is that I found SharePoint 2007 doesn’t have the ability to bulk remove errant (or otherwise) workflow tasks. Not from the user interface, at least – and I didn’t want to do it, twice, for each one of 377 items (there weren’t quite that many runaway workflows but it was well into three figures). I found some code on a blog post from SharePoint MVP Brian Farnhill (@BrianFarnhill) to cancel a workflow programmatically but I’ll need to put the code  into an app and I’m not really sure how to do that (my limit is probably opening Visual Studio). Besides which, I figure that the administrators of our SharePoint platform, who have probably spent the last 3 weeks wondering why it was running out of memory (or running more processes, or something similar) won’t appreciate me running unsupported code against their servers – even if it is client side…

Although it would be gratifying to create the app, in the end I settled for removing the workflow from the list, which has the side effect of ending all running workflows (unless you select the “no new instances” option). Unfortunately I still have a bunch of items that generate an error message when I try to open them – goodness knows why.

I decided to fight fire with fire and given that I’m clearly some sort of SharePoint Destroyer Designer workflow deity (not), I created another workflow to nuke all the column settings I’d created with the first two workflows (since neutered).

The logic goes like this:

Condition: If columnname is not empty
Action: Set columnname to null

Unfortunately it’s not possible to leave a null/blank value when setting field values but, like so many things in SharePoint, there is a workaround. That workaround is to set a workflow initiation parameter (imaginatively, I called mine Blank) of type single line of text, with an empty default value.

Now, the workflow action can use the value Initiation: Blank (i.e. null) to clear the contents of a column.

Unfortunately, it still hasn’t fixed the problem with the items that will not open. And, in case my manager is reading this post (which I doubt), hopefully this now puts to bed the running joke whether it’s he or I that is our team’s “SharePoint guru”. Clearly my infrastructure background does not lend itself to being a “guru” in an application platform (as I have always maintained!)…