SharePoint Designer 2010 Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow.

When attempting to publish a SharePoint Designer 2010 workflow that is large or uses multiple Start Approval Process actions, an error indicating that the workflow cannot be published will be displayed.

In SharePoint 2010 RTM:

• SharePoint Designer will show the following error: “Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow”
• And the following message will be logged to ULS: “w3wp.exe SharePoint Foundation Workflow Infrastructure Medium Workflow Compile Failed: Thread was being aborted.”

After installing the February 2011 CU:

• SharePoint Designer will show the following error: “Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow”
• And the following message will be logged to ULS: “w3wp.exe SharePoint Foundation Workflow Infrastructure Medium Workflow dll failed to compile because it exceeded UserDefinedWorkflowMaximumComplexity of 7000”

This problem is caused by the large number of Types that are created during workflow compilation, for workflows with many local workflow variables. It is more common for workflows with multiple Approval Process actions, as each preconfigured Approval Process Action comes with a large set of local variables, for the different configurable property of the Approval Process.

Prior to the February 2011 CU, limits on the complexity of the workflow definition were enforced by the Microsoft .NET 3.0 workflow compiler. With the February 2011 CU, SharePoint uses the SPWebApplication UserDefinedWorkflowMaximumComplexity property to enforce a maximum number of Types in the workflow definition, and prevent compilation in these cases.

The issue can be resolved in numerous ways. The primary point of concern should be to minimize the impact on the SharePoint server by applying the February CU or a CU that includes the February CU. Service Pack 1 is the ideal solution.

Once SP1 has been installed the following property will be made available:

UserDefinedWorkflowMaximumComplexity

Please refer to the link below for more information:

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.userdefinedworkflowmaximumcomplexity.aspx (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.userdefinedworkflowmaximumcomplexity.aspx)

By installing a CU that includes the server February 2011 CU, SharePoint administrators are now able to prevent compilation of workflows whose compilation would affect the performance of the farm. The default value of the property is 7000, but can be changed based on the needs and profile of the SharePoint farm.

The following PowerShell script can be used to adjust the value per SPWebApplication:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

$new_limit = 5000;

$webapp = [Microsoft.SharePoint.Administration.SPWebApplication]::Lookup(http://WebAppURL)

$webapp.UserDefinedWorkflowMaximumComplexity = $new_limit

$webapp.Update()

To give context to the default 7,000 value a Start Approval Process action contains 1176 nodes, a Start Feedback Process action contains 1010 and an empty Start Custom Task Process contains 13 nodes.

Rather than changing the default value, it is recommended that larger workflows be restructured to either have more reusable pieces, or be broken out into smaller individual workflows.

Some ways in which the complexity of larger workflows can be reduced include:

• Use the Start Custom Task Process action instead of Start Approval Process, and add new task process variables only as they’re needed
• When the task approvers (or task email) need to change based on conditions in the workflow, use a conditional block to save the task approver (or email contents) in a local variable and then use a single Approval Process action, rather than having a separate Approval Process actions with hardcoded approvers/email contents in each branch of the conditional block
• When using the child workflow approach, keep the second workflow into a paused state by using an action like Wait for Field Change. In the parent workflow, once the Start Approval actions have been completed the workflow can modify a column which the second workflow is monitoring and then it will come out of the paused state

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use (http://go.microsoft.com/fwlink/?LinkId=151500) for other considerations.