Skip to content


One of the things I like (mostly) about working with SharePoint is that I get the opportunity to learn stuff almost every day.  I say mostly because although I love to learn, sometimes I have to learn by making mistakes – and that’s never fun.

About a month ago Dave Wollerman learned something about the way workflow’s worked and blogged about it.  The post titled “Huge MOSS Workflow Issue… What is Microsoft Thinking!!!!”  The post lays out how workflows based on the out of the box workflows – Approval is the one he calls out – lose their workflow history after 60 days.  In his post he’s frustrated (as in fact I might be) because he expects that workflow history stays around as long as the item does.  He mentions that there’s a performance reason for doing this but doesn’t dig behind the scenes.

In a recent conversation with some folks on the product team I got to mention Dave’s post and talk through it with them.  Out of that conversation I was struck by a few things.

First, there is a real performance issue that they were trying to address.  Because of the way that lists are implemented there’s a soft limit around 2000 items per “view” where the performance starts to decrease.  It’s a long story about the database table that items are stored in, how SQL treats the query, etc.  The short of which is that you need to be cognizant of how big lists get.  Steve Peschka wrote a white paper on this “Working with large lists in Office SharePoint Server 2007”.  It’s good reading if you want to know more about this.  But what does this have to do with Workflow History?

Help Your SharePoint User

Well, each workflow history entry is placed into a big list.  In that list you have all of the workflow history items for all of the workflow instance for every workflow association that has that workflow history list associated with it.  If you figure on five workflow history entries per workflow it’s easy to see that even a few hundred items with workflow can quickly cross that 2,000 item mark.  As a result deleting items – making sure that the list doesn’t get really, really huge, is an important part of maintaining performance on the system.

Second, Dave’s thinking about the workflow history list as a permanent audit record.  MOSS provides an audit mechanism – but the workflow history list isn’t it.  I have to admit that I’ve fallen into this trap.  I do have some workflows that I think of the workflow history list as a part of the auditing – so I need to go back and revisit these workflows.  A better way to think about the workflow history list is a log.  The log files that MOSS creates – the ULS Log – are automatically recycled. Based on the schedule you set new logs are created and eventually deleted.  Workflow histories are designed to be like this.

Third, there’s a gap in the documentation.  It’s not precisely clear how this automatic recycling of the list takes place.  The object model reference lets you know that SPWorkflowAssociation.AutoCleanupDays exists, however, it doesn’t offer any additional information about how it works, why it exists or how it works.  I’ve found only a few references to this property in the Blogosphere.  I haven’t found an article or book that covers it (including my chapter in Real World SharePoint 2007 or articles.)  That means that it’s not going to jump out at you – unless you go looking for it because you already know it’s there.

Fourth, and finally, I’ve not been able to find any place that it is documented how to set the AutoCleanupDays when the workflow is associated.  However, a buddy on the program team showed me where this can be set so it will apply to every new association of the workflow – it won’t solve the built in workflows but it can help you with your own workflows.  Note the addition of an node in the following sample Element Manifest Xml:

<Elements …>
<Workflow …>
<MetaData …>


That’s pretty cool and not unlike the idea of feature stapling – where you can handle all of the new instances created even if you have to go back and update the existing associations.

[Update: 2007-10-16: It turns out that autocleanup doesn’t actually clean out the workflow history.  It does, however, remove the entry from the workflow instances that connects the workflow history to the item that the workflow ran on.  It also turns out it deletes any tasks that were created by the workflow.  The net effect of this is that the actual auditing is OK — the user interface just doesn’t look so good.]


  1. Hi Robert,

    Do we have any Microsoft official documentation available to this elements.xml approach?


  2. Good article. I recently came across something quite wierd while using OOB Approval Workflow. The task in task list disappeared for a specific document which was in workflow “completed” state. And added to that the “Approval” column for all documents in that list went blank! Is this because of the 60 day History list purge rule?

  3. Aravind – It’s in the SDK now.
    Sam – Yes, this is the workflow cleanup running.

  4. Hi Robert,

    I have attached custom workflows at the site content type level(Page).
    After that i clicked on “Update all content type” link.
    Created new page using custom page layouts, at that time it created new column with “Workflow instance” name. After that i created one more page with different page layout in the same page library then one more column got created with same name. So i have 2 columns with same name(Workflow instance name). When i check the same thing in OOB workflows there also same thing happened. My question is “Is it oob behaviour of MOSS” or what?
    All our custom page layouts are deriving from Page Content Type.


  5. Sri – Yea, this is normal because they’re not the same instance. The thing is that the different page layouts are based on different content types (I assume) — thus the association may have the same name but is internally different, thus you get two columns. I don’t understand your situation but I wouldn’t bind a workflow to the page content type. It will impact dozens of content types.

  6. good work Robert,thanks for the article really good work from you and i have bookmarked it to see your daily stuff at your blog.

  7. Idea is fine ,but is it applicable for sharepoint designer workflows…
    if i will update it at this file “WorkflowHistory.xml” will it work..pls reply

  8. Terrific way of expressing those things in your post. Clear cut meanings.

  9. good work Robert, thank you for the article you work really well and I have a bookmark to see your stuff on your daily blog.

  10. the schedule you set new logs are created and eventually deleted. Workflow histories are designed to be like this.

  11. This is really awesome Robert. I could see the things done in right way. Its so nice indeed.

  12. About this topic, I have been lately in your blog once or twice now. I just wanted to say hi and show my thanks for the information provided.

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share this: