Fix SharePoint workflows after deactivate

Within the SharePoint environment, there are a bunch of “features” that are installed out-of-the-box.  

In addition, developers can code WebParts, Workflows and artifacts such as Master Pages and Page Layouts that can all be activated in the same way.

> Site Actions > Site Settings > Modify All Site Settings

 

Depending on the site template used (eg. Publishing), there are different WebParts and Workflows that are “required”, and should not (recommended not) be de-activated.

Case-in-point – Routing Workflows :

These are used within Publishing Pages – such as “submit for approval” – and the corresponding approval chain in order to publish the page, image, document, etc.

When a sub-site is created in the Publishing site structure, the default “Parallel Approval” workflow is automatically associated with the particular document library, pages gallery, etc.

> View All Site Content > Pages > Settings > Document Library Settings > Workflow Settings

The quickest and easiest way to BREAK this – is to simply deactivate the feature within “All Site Settings”.   Trust me on this fact.   😦

There is a warning on this dialog – read it closely…

We were testing out another workflow, and had mistakenly deactivated the underlying approval feature. 

This problem was discovered when trying to approve a page, or force a “Parallel Approval” workflow to start.

Not a very helpful error message though :

The workflow failed to start due to an internal error.

Unlike a WebPart, simply activating the feature again won’t actually FIX the problem – there is a deeper association somehow/somewhere within the SharePoint content database.

Solution ?

A quick way to FIX things is to manually delete the workflow, and re-create it.  This re-adds the workflow back to the library – not fun when you consider you’d have to do it for every library – and every subsite.  

(Our Publishing Site has 100-120 sites, with 3 libraries in each – do the math !)

The only way was to consider a script of some sorts, that “re-associates” the workflow instance in the library, with the workflow template/feature.

This involves the following steps :

• Find the existing “broken” workflow, and remove it
• Create a new workflow “association”
• Assign it to the the document library (eg. Pages)
• Set it as the default approval workflow
• Move on to the next list/library – and site

Scroll below for a link to the sample code.

Here’s a run-through of the code…

Find the SharePoint list, such as Pages, Images, Documents :

SPList splList = vspwSite.Lists[“Pages”];

Find the existing broken workflow, named as “Parallel Approval” :

SPWorkflowAssociation wfaParallelApproval = splList.WorkflowAssociations.GetAssociationByName(“Parallel Approval”, System.Globalization.CultureInfo.CurrentCulture);

If the workflow was found, then remove it :

if (wfaParallelApproval != null)
    splList.RemoveWorkflowAssociation(wfaParallelApproval);

Get a reference to the approval workflow ‘type’ :

SPWorkflowTemplate wftApproval = vspwSite.WorkflowTemplates.GetTemplateByName(“Approval”, System.Globalization.CultureInfo.CurrentCulture);

Create a workflow association, with the workflow “name”, task list and history list to use :

wfaParallelApproval = SPWorkflowAssociation.CreateListAssociation(wftApproval, “Parallel Approval”, vspwSite.Lists[“Workflow Tasks”], vspwSite.Lists[“Workflow History”]);

The next step is to define the “association data”.  This is a huuuuge XML chunk that defines the details for the workflow, including the options, approvers, and default start values.

This is initially set from within following UI :

 

Here’s an example of the XML chunk you need to include – I did say it was huuuuge !

<my:myFields xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:my=”http://schemas.microsoft.com/office/infopath/2003/myXSD” xml:lang=”en-us”>

<my:Reviewers>

<my:Person> <my:DisplayName> Approvers </my:DisplayName> <my:AccountId> Approvers </my:AccountId> <my:AccountType> SpUser </my:AccountType> </my:Person>

</my:Reviewers>

<my:CC> </my:CC>

<my:DueDate xsi:nil=”true”> </my:DueDate>

<my:Description> </my:Description>

<my:Title> </my:Title>

<my:DefaultTaskType> 1 </my:DefaultTaskType>

<my:CreateTasksInSerial> false </my:CreateTasksInSerial>

<my:AllowDelegation> true </my:AllowDelegation>

<my:AllowChangeRequests> true </my:AllowChangeRequests>

<my:StopOnAnyReject> true </my:StopOnAnyReject>

<my:WantedTasks xsi:nil=”true”> </my:WantedTasks>

<my:SetMetadataOnSuccess> false </my:SetMetadataOnSuccess>

<my:MetadataSuccessField> </my:MetadataSuccessField>

<my:MetadataSuccessValue></my:MetadataSuccessValue>

<my:ApproveWhenComplete>true</my:ApproveWhenComplete>

<my:TimePerTaskVal xsi:nil=”true”></my:TimePerTaskVal>

<my:TimePerTaskType xsi:nil=”true”></my:TimePerTaskType>

<my:Voting>false</my:Voting>

<my:MetadataTriggerField></my:MetadataTriggerField>

<my:MetadataTriggerValue></my:MetadataTriggerValue>

<my:InitLock>true</my:InitLock>

<my:MetadataStop>false</my:MetadataStop>

<my:ItemChangeStop>true</my:ItemChangeStop>

<my:GroupTasks>true</my:GroupTasks>

</my:myFields>”;

The trick here is to determine what the values need to be.

The quickest way I found – and a little nervous to say this – is to jump into the SQL Server database for the SharePoint content database.

WARNING – USE CONTENT DB + SQL AT YOUR OWN RISK…!

1. Take a note of the URL in the Workflow page as above – eg. http://server/site/_layouts/AddWrkfl.aspx?List={D27C93E4-7D28-4745-B486-DD4C71C7732F}&TemplateID=%7BC360A3C1%2D0312%2D4175%2D924B%2D4CAE52D8837A%7D
2. Within SQL Server, open the content database (eg. WSS_Content)
3. The table to look into is “WorkflowAssociation” – but unfortunately, the column for LIST ID is a varbinary, not a GUID – so need “convert”
4. The field to get is “InstantiationParams”
5. So – the query to use for MY list is :

SELECT InstantiationParams

FROM WorkflowAssociation

WHERE CONVERT(UNIQUEIDENTIFIER, ListId)

= ‘D27C93E4-7D28-4745-B486-DD4C71C7732F’

Just need to copy this entire XML chunk into the console app

Last up, just need to set the “default” approval workflow :

splList.DefaultApprovalWorkflowId = wfaParallelApproval.Id;

splList.Update();

The program code I’ve used does the above steps, for many various document libraries with each Publishing Site – ie. Documents, Images and Pages.

  

Give it a quick run-through, and should then fix up ALL your workflow woes !

Click here to see the code, let me know if you have any comments/questions.