We talked about the workflow log types (Audit and Debug), and we agreed that using the built in “Log to History List” action inside SharePoint designer is not a preferred way from my personal point of view. So what is the better way to do logging?.
You can think of a SharePoint list as a database table. It has columns and each column has specific type. Tables in a relational database model can relate to each other using keys. In SharePoint, lists can relate to each other using a column type called (Lookup) in the same way.
We have a process to log changes happening in data centers. We need to create a process to track those changes and require an approval for every change. Finally, auditors will require some kind of logs to be exported as a proof of the integrity of such change control process. You also need some debug logs for troubleshooting purposes.
Let us start designing the solution by defining couple of content types. If you are not familiar with content types inside SharePoint, I suggest you start learning about this concept. In my own words, content types are like creating a class in any programming language. You create a class, define some properties and the data type for each property, and then you can create instances of the class whenever you want.
Same thing applies here.Content Types are like classes, and Site Columns are like Class Properties. If you are still not that comfortable with content types, just create normal lists and columns, but in this example, I will use content types just because I like to do that.
We will create three content types “Parent Content Type shown in the picture”:
- Data Center Changes
- Audit Log
- Debug Log
We will also create three lists:
- Data Center Changes List.
- Audit Log List.
- Debug Log List
Data Center Changes content type has two columns:
- Title (Single Line of Text)
- Data Center Change Reason (Multiple lines of text)
Debug Log content type has two columns:
- Debug Message (Type: Single line of text)
- Change ID ( Type: Lookup) – maps to the Data Center Changes “ID” column.
The same thing with the Audit Log content type, it has two columns in the same way:
- Audit Message (Type: Single line of text)
- Change ID (Type: Lookup) – maps to the Data Center Changes “ID” column.
Now we have the following relation between our three lists:
When you are inside the SharePoint designer, and you want to throw a debug message, choose action (Create List Item), pick the Debug Log list, as per the following:
As shown, you have to populate the (Change ID) with (Current Item:ID), and then fill the (Debug Message) with the log content you want.
The same applies when you want to create an audit message. Finally, you can go to the Debug Log List and the Audit Log List, create a view with (Group By) using the Change ID field, and you will get all debug messages and audit messages per Change ID.
You can use SharePoint Information Management Policy to apply retention policy to purge the debug messages from the Debug Log List after say one month, and another retention policy to purge the audit messages from the Audit Log List after say one year.
I hope this highlight some of the great benefits from using such approach to create and maintain logs generated from your workflows.