Unexpected error on server associating the workflow

Recently we had to throw together a SharePoint Designer workflow in a hurry for a client. It consisted of 20 plus If Then Else statements that then triggered a separate custom task process.

About halfway through designing it, it started throwing the following error when publishing:

Unexpected error on server associating the workflow

I was able to determine that there was a default limit of 7000 on the UserDefinedWorkflowCompexity property of the web application. I used the follwoing PowerShell script to increase the limit and get passed the error:

$app = get-spwebapplication http://sharepointwebsiteurl/


$app.UserDefinedWorkflowMaximumComplexity = 30000

$app.Update()

After running this script, do an IISRESET and try publishing your workflow.

User Cannot Approve Task - Access Denied

I created a SharePoint Designer workflow that assigns an approval task to a user when a list item is created. I began receiving reports that users were receiving the task emails from SharePoint, but when they attempted to approve or reject the task they received "Access Denied" .

Further troubleshooting showed that they had access to the task library, and could see the tasks, but they could not open any of their tasks. I broke inheritance and gave the users "Full Control". This did not resolve the issue.

I found mentions on the webthat publishing the workflow files to the local file system resolved this issue. As crazy as it sounds, this resolved my issue. Here are the steps I took:

Open SharePoint Designer and browse to the workflow in question. Right click on the workflow and select "Publish Selected Files"

Select the radio button labeled "Local File System", and browse to any area on your local drive:

If you receive a dialog stating that no website exists and asking if you wish to create it, click yes. Allow the files to be copied to your local drive.

At this point, my users were once again able to approve their assigned tasks.

SharePoint Designer Workflow Errors

If you've ever tried to debug a problematic SharePoint work flow, you know it's not a simple, clear cut process. Recently I had a workflow that was designed to strip and reset permissions on documents checked into a document library. The idea was that the creator of the document, and members of a SharePoint group would be granted access to the document, while all others would not be able to see it. In most instances, the workflow executed properly; but in some cases, it would throw an error leaving the document visible to all users.

I began troubleshooting the issue by removing all the steps in the workflow, then adding them back in, one at a time, executing the workflow after each step was added back in. It was then that I realized that the issue involved setting permissions with multiple, nested groups.

The work flow consisted of three steps:

1. Strip permissions from the document for all users
2. Grant Contribute permissions to the document creator
3. Grant Contribute permissions to the "Document Reviewers" group

If I created and submitted a document, the workflow failed. If a different user created the document, it worked fine. It was then that I realized that, since I was a member of the "Document Reviewers" group, as well as the creator of the document, it was trying to grant access to me after I had already been granted access.

Once I removed myself from the group, it worked fine. The workflow would also execute fine when a user who was not a member of the group submitted a document.

If you experience errors with workflows that assign or strip user permissions, look into the composition of the group. That may hold the key to your errors.