Friday, February 7, 2014

Save early and save often, unless you are using SharePoint Designer

When editing a workflow in SharePoint Designer 2013, you have two options: Save and Publish. Saving is a great feature, allowing you to save your progress while modifying a workflow without affecting instances already running.


You would think if there are two versions of a workflow (published and unpublished) that you could back out of your changes and revert your working copy to the current published version.

Why would you think that?

Unfortunately not. If you made a mistake and saved, or you quickly hit the cancel button during save (which is the equivalent of betting on a horse named Lil Couch Potato), you either have two options: eventually publish those saved changes and break everything for everyone, or your published version just became the last that ever will be.


I’m not going to go into all the work it took to get to the solution, because it’s useless information, and frankly, I am having bouts of PTSD.

Basically any “saved” workflow is stored locally in SharePoint (in the database) and any “published” workflow is the saved copy, pushed to “the cloud” (Workflow Manager).

I used SharePoint Manager 2013 to try to find which hidden list the workflow files could be stored in. Turns out it is in “wfsvc”. Within that list there are folders stored by the GUID of the Definition ID of the workflow. And within that folder there are child items for the association files, a VSDX if you used Visual Designer, and the brain of your workflow “workflow.xaml”.


If you expand workflow.xaml, you will see “Versions”, and for each of those items, a copy of the file for each change that was saved. What I needed to do was go through the list of file versions to find the one before my bad save. The list is in order from earliest to latest, so I scrolled to the bottom and clicked up a few to a date before my save. I then got the ID number, which will be used in the PowerShell to get your workflow back. You could try right-clicking and deleting the SPFileVersion items that came after the version you want to bring back (which I did), but it doesn’t solve the issue.


Below is a PowerShell screen capture to show you what the properties look like. There are different levels, structured like the screen shots in SharePoint Manager above. There is a list item for the Workflow Definition (a folder), for each workflow file (a list item), and then there is a binary file for each workflow file and for each version of that workflow file. There are also versions for the list items.


Are you still reading this? Because just think about that again to write this made my head hurt. But good news! It’s simpler from this point on. You can find the PowerShell below that I used to get the previous version of the workflow back and some other points about issues I came across.

$site = Get-SPSite <URL>

$rootWeb = $site.RootWeb

$workflowDefinitionList = $rootWeb.Lists["wfsvc"]

$item = $workflowDefinitionList.Items[0]







$item.SystemUpdate() # Did this, but the FileVersion property was blank.

$itemVersion = $item.Versions | where {$_.VersionId -eq 66560}

$fileVersion = $itemVersion.FileVersion

$stream = $fileVersion.OpenBinary()



So let me explain the above:

For Line 4: I am making an assumption that the first item is for workflow.xaml. You can further check to ensure that $item is indeed the workflow.xaml file.

For Lines 6-10: I made the mistake of clicking on “Visual Designer”. If you do this (or rather before you do this), make sure that everyone that will ever be editing the workflow in the future has Visio 2013 Professional installed, or that everyone will wind up being you. Because you will get a warning that it cannot be edited without it. When you do switch, some properties get added to the Workflow Definition list item (not the workflow.xaml file itself), which will cause the workflow file to be opened in Visual Designer. You can remove these properties if you are having issues.


For Lines 12 and 13: I tried using the RestoreById method, which did set the properties on the Workflow Definition list item correct, but the FileVersion property was blank.

For Lines 15-18: I got file version for the item version, sucked the binary contents of that file and shoved them into the current version of the file.

Opened in SharePoint Designer, everything was there, and everyone lived happily ever after.