Several months ago I responded (in what has to be the worst titled blog post “SPWorkflowAssociation.AutoCleanupDays”) to an inflammatory post by Dave Wollerman titled “Huge MOSS Workflow Issue… What is Microsoft Thinking!!!” I was recently pointed to Dave’s response to my response.
So I’m with Dave in that I think everyone should know about the situation. Perhaps where I differ from Dave’s thinking is I believe people should have solutions to the problem so that’s what I’m going to offer here.
First, a recap. By default, Workflows will clean themselves up 60 days after they “end”. This process doesn’t delete the actual workflow history table entries but does disconnect them from the user interface, so they’re harder to get to.
So there are two key things to note about this:
- It’s settable. You can change it in your element manifest as my original post on this topic pointed out. You can also change it in the API for every existing workflow association if you want. (SPWorkflowAssociation.AutoCleanupDays). If you never want SharePoint to delete workflow history, the workaround is simple. Write a tool that runs every 59 days that goes through every site, web, list, and workflow association and sets the AutoCleanUpDays property to 9999. The end. No issue. It won’t clean anything up for you. It’s probably 4 hours worth of coding including testing. I don’t understand how something that can be fixed so easily is a “Huge MOSS Workflow Issue”
- Workflow History != Audit (for you VB programmers, Workflow History <> Audit). Workflow history isn’t an audit. It’s not secured by default. It’s not tamper proof. If you’re using Workflow history for audit – and the auditors are letting you – then there’s something wrong. If you need an audited record then have the workflow bundle everything up and record it in a record center (or insert your solution here) so that it is a final record. I can put an entry into the list saying that the Easter Bunny approved something if I’ve got contributor access to the web site (and no one has changed the default permissions of the history list.) I can delete the records indicating that I did approve something. It’s just not secure so using it as an audit record when it isn’t not only doesn’t work, it doesn’t make sense.
So in Dave’s defense, I’ve definitely had those “What were they thinking?!?” moments. The support engineers, product managers, and program managers will all be happy to pipe in and confirm that I’ve had them. However, I have them over things that are more pervasive and don’t have good workarounds. (Like say checking for the existence of a list without throwing an exception, or not allowing for the creation of a content type with a specific ID from the API, etc.) I know it can be frustrating to expect that SharePoint operates one way only to be shown that it operates another.
However, ultimately, this is a non-issue. It’s easy to work around and it’s a bad approach to start.