I have seen this approach as my company is currently upgrading from SP2007 to SP2010. Because the person who designed this left the company and there hasn't been anyone who continued maintaining the site/architecture, I'm wondering if this approach makes any sense.

Actually, the design is like this:

There is one Task List with like 10 Content Types (e.g. "Print Request", "Send Document"...) attached. Each Content Type has custom forms and all the forms are stored in the workflow itself. So the Content Types are referencing to forms inside the "Workflows list".

I wonder if this approach does have any advantage that I can't see?

2 Answers 2


If it's a single visual studio workflow, then that's how workflows work.

When you create a workflow you don't know the name of either the task or history list (visual studio makes you think you know it, but that's only for debugging) when you associate the workflow with a list you specify the task/history lists either as new or existing lists. But all of the tasks in the workflow use the same list.

If it's multiple workflows then the advantage could be that it's easier to get an overview of all outstanding workflow tasks than if they're spread out into multiple lists.

  • I see, always thought about each task should be stored in its own list. But here it really gives a nice overview about all the tasks which have been created by the workflow. Thanks for helping me out!
    – curmudgeon
    Commented Aug 17, 2012 at 9:04

I like to do this because I create Calendars based on Views of the single Task list. I know you can do this across multiple Task lists, but it is easier/more straightforward for just one. Plus I have a wepart on my Welcome page that is a "My Tasks" view of the Task list - since it is one Task list that was super simple to enable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.