Background

During the course of prototyping some task management capability for a client, I needed to create some quick and dirty workflow examples on a WSS tasks list. I did not need the workflow example to be deployable, compiled, or have any custom code, so naturally I thought of SharePoint Designer.

I created the workflow and associated it with a tasks list that we were using to manage our tasks. When I initially created the workflow, I set it to start only start when a user explicitly started it, not automatically on item additions or updates. Once I was fairly confident that the workflow was behaving properly, I wanted to go back and modify it to start automatically upon task item additions or updates. When I tried that, SharePoint Designer told me that I had errors in my workflow. It pointed to a step where I was collecting information from the user. I thought that was odd seeing how the data collecting had been working just moments before.

What made matters worse is that I had no way to get at the actual error details. When I tried to hover the cursor over the error symbol, the step drop down would obscure the error. I was stumped.

The Hunt

I decided to investigate the site in the web browser to see if I could pinpoint the problem. I remember working with the workflows that ship with MOSS, specifically, that they allowed me to select a history list and tasks list where workflow-specific data was stored. I looked through the site and found the history list but could not find the workflow tasks list.

I thought the lack of a workflow tasks list was odd. After all, how could the workflow be storing the data collection information if it did not have a workflow tasks list?

The Bug

The lack of the separate workflow tasks list proved to be the issue! It turns out that when SharePoint Designer 2007 creates a new workflow, it utilizes the first tasks list in the current site as the workflow tasks list. Now remember that I created the actual workflow to run on a tasks list. The reason I could not have the workflow auto-start was because SharePoint Designer was placing its data collection tasks into the same tasks list on which the workflow was defined. Knowing that, it was clear why the workflow could not auto-start: if the workflow auto-started it would start not only for task items that users added to the list but also for data collection tasks items that the workflow instances added to the list. That would cause workflows to cascade out of control.

The Workaround

Well, knowing the issue was great and all, but I had a customer breathing down my neck. It turned out that the workaround was easy to implement by using the behavior of the actual bug. If SharePoint Designer wanted to use the first tasks list in the site to store its workflow tasks, let it. I created a new site, and two tasks lists. I made sure to title the tasks list I wanted SharePoint Designer to use for workflow tasks to come alphabetically before the tasks list on which the workflow would actually run.

Here’s an example. Say I wanted my workflow to run on the “Tasks” tasks list. I would create another tasks list in the site called “A Workflow Tasks”. Because “A Workflow Tasks” alphabetically comes before “Tasks”, SharePoint Designer will use the “A Workflow Tasks” as the workflow tasks list for the site. Life is now good.

One Catch

I stated in the workaround that I created a new site to implement the workaround. This is because once SharePoint Designer chooses a tasks list as its workflow tasks list, it will keep that for the duration of the site’s existence. That’s why I created the new site. I suppose given enough time and desire I could have found where SharePoint Designer stores its affinity for a workflow tasks list, but at 3 AM, creating a new site seemed like the way to go.

Update

TBone has a nice article about changing the auto-assigned workflow task. The article can be found here: http://www.sharepointblogs.com/tbone/archive/2008/01/10/ode-to-joy-changing-the-task-list-for-auto-generated-tasks-within-sharepoint-designer.aspx