Blog Post: Workflow History Auto-Purge: Do’s and Don’ts

 In deployments that have a decent amount of workflows that fire constantly (i.e. system jobs are spawned), the amount of records placed in the asyncoperationsbase table is quite impressive. However, when these system jobs complete, as either canceled or succeeded, they remain in this table forever until you decide to purge them. When these tables begin to grow into the millions of rows it imposes undue performance issues on the async service and overall system performance may suffer as well. Hence, we have a DBA issue to deal with. It is wise to tackle this issue up front, and consider it in your workflow designs and in your database maintenance processes.

 

 

 

Before the 2011 release, the only way to purge these records was to run a sql script either manually, or in a scheduled sql agent job. The code for this script has been around for some time and a Microsoft KB article provides this script along with other helpful background: http://support.microsoft.com/kb/968520

 

 

 

During an upgrade from CRM 4.0 to 2011, the Deployment Manager Import Organization process will go through all system jobs and apply this purge script automatically to your database before completing the import/upgrade.

 

Going forward, CRM 2011 contains a new feature that allows a workflow designer to define each workflow as available for what I call “auto-purge”. There is a check box on the Administration tab of the workflow design form at the bottom (show in image above). 

 

If you want to take advantage of this option, it can save considerable space and keep your performance issues to a minimum the more workflow you nominate for auto-purge.

 

 

 

One thing to keep in mind when coding a workflow for auto-purge: only those system jobs that end in a status of “succeeded” will actually be purged. There is a mindset at play here…if a workflow ends with status of Canceled, maybe there is something wrong that needs to be investigated…hence let’s not auto-purge those system jobs. As a Workflow Designer, desiring to take advantage of auto-purge, it is important to know this little tidbit of information. Because I know several clients of mine who prefer to end system jobs as Canceled if the check conditions cause the workflow to end without taking any action.

 

Therefore, we recommend the following Do’s and Don’ts:

a) DO consider the auto-purge option when creating any new workflow

b) DO consider rewriting existing workflows (that were upgraded from 4.0) to take advantage of auto-purge

c) DO end system jobs as “Succeeded” if check conditions produce a “no action” outcome in the workflow, if you want those to be auto-purged

d) DON’T assume this problem will manage itself