Logging Workflows for Troubleshooting

SharePoint workflows are very powerful tools. SharePoint workflows allow you to automate tasks and workflow processes. If you haven’t used workflows before, I recommend reading the SharePoint online help for workflows:

http://office.microsoft.com/en-us/sharepointdesigner/CH100667661033.aspx

Once you start to use workflows in your SharePoint applications, you realise a very important and fundamental truth; what happens when a workflow fails? By default, you can click on an item in a list and see the workflow history. Unfortunately, the error messages in the workflow can be cryptic to say the least. For example, if I have a workflow that creates new items in 5 different lists and the workflow fails, I get a message saying “Unable to update list item”. The message doesn’t tell me which specific action or step failed or which list it was unable to write to.

To get around this issue, and to provide an even finer level of control over my workflows, I created a custom list and used that list to log my workflow actions. The custom list, called WorkflowLog, contains the following fields:

• Workflow Name (text field) – stores the name of the workflow that is logging the event.
• EventOccurred (date & time field) – stores the date and time that the event was completed.
• Workflow Step (text field) – stores the number and label of the step being completed.
• Workflow Action (text field) – stores the specific action step completed.
• Event (multiple line text field) – stores details about the action completed.
• AdminNotes (multiple line text field) – allows me to store specific notes for troubleshooting.

I configure my workflows to write an entry to the WorkflowLog everytime an important step is completed. If the workflow creates a new item and sets the status to ‘Created’, the next action is to create a new item in the workflow log and log that creation. Here is an example of the line item created by my Auto-increment ClientID workflow:

WorkflowName	AutoAssignClientID
EventOccurred	5/15/2008 2:03 PM
WorkflowStep	1 – Update ClientID then Increment ClientID
WorkflowAction	Updated the ClientID on the new client
Event	The workflow has taken the latest ClientID from the SystemCounters database and updated the Customer. Then it has incremented the SystemCounters by one.
AdminNotes	ID: http://mysharepoint/sites/Lists/Customer/DispForm.aspx?ID=3″; Company Name: TEST 3

You can see, from the example, that I know that the workflow ran step 1 at 2:03pm on 5/15/2008. I know the step completed, and what it did. The link in the Admin Notes opens the original item so that I can check it. The workflow log allows you to easily troubleshoot a failed workflow – and it has the advantage that it works for Custom Form Actions (which have no history at all?).

Organising the Log

The log continues to compile workflow entries in the background as my users continue to work in the application. I can sort the log by the date the event occurred or by the workflow name, etc. I also have another field, specific to my company, which contains the “ticket number”. I can sort the workflow log by the specific ticket number, then the workflow name, and then the date and time. I have an admin page that contains a multiple item dataview of the log and allows me to select the ticket number from a drop-down list to filter the available entries. 

Future efforts

I am going to add a new column and link to the workflow. I want a column that stores a link to the actual SharePoint workflow history. If you open the workflow history on an existing item, the URL in the address bar looks like this:

http://mysharepointsite/sites/main/_layouts/Workflow.aspx?ID=72&List=B65934BA-EBF4-4CB8-956D-B0Ce4236B657 

The ID number identifies which specific entry the workflow was run on and the List number identifies which list the entry resides in. I will create a hyperlink that takes the ID from the current item (Dataview) and substitutes the List number as a variable as well.

I think that this log process contains a lot of untapped potential and I will be updating this post as I add to the log.

UPDATE

Paul Galvin pointed out that I forgot to mention some  of the possible downfalls to this logging method. You can see his blog here. 

Thanks for Reading