When building a solution using SharePoint and Workflow Foundation your requirements are sometimes that it should be possible track what everyone did and when it was done, in other cases you can forget all about the process once it has completed. Another name for this is that the system should support auditing.
This discussion has once more become current as there recently has been some talk in the blogosphere about SharePoint's removal of association between item and workflow, one such post is written by Robert Bogue. So those who have considered tasks and workflow tasks as suffucient tracking may have to reconsider. Before going any further let me say that I have not personally verified which items and associations that are removed.
I can quickly think of five different places which you could store tracking data:
- Tasks: The task holds information about who was assigned, when it was completed, etc.
- Workflow History: Custom data logged by a developer, only holds information which the developer chose to log. Can either be used for audting or for "debugging".
- Event Log: Custom event log used to store audit information.
- SharePoint Audit Log: Log information to the audit log using the audit API.
- Custom Audit Log (e.g. SQL Server): Log information to a database or text file which you have control over.
|SharePoint Audit Log||
|Custom Audit Log||
One issue to consider when choosing a tracking mechanism is what kind of proof you will need to show in an audit. Is it sufficient that there is a log or are you required to prove that an entry hasn't been manipulated? Or have entries been removed?
Currently I'm leaning towards using a custom audit log in SQL Server. It can be reasonably protected from everyone except SQL Server sysadmins. But I will also have to further consider the merits of the SharePoint Audit Log.