Today's post is written by Rob Montague, a developer at Sonoma Partners.
I was working on a project for a customer that wanted to send an email to all of the previous owners of a case when a case is resolved. We had auditing enabled, and everything looked like it should be some simple fetch queries, but it wasn’t quite so simple. Here were the catches.
1. Even though you have auditing turned on for a field, be sure to check to make sure that the auditing is enabled for the entity type you are using (especially if it’s native)
a. Settings -> System -> Auditing -> Global Audit Settings -> Start Auditing
b. Make sure the entity types that you are using are enabled. In Global Audit Settings, under Enable Auditing in the Following Areas I had to enable Customer Service Entities to enable auditing on Case.
c. Make sure you test to make sure your user will have access to the audit history field that you are accessing
d. If you have an administrator that clears out audit logs OR you have an automated process to do so, you could possibly lose some historical data in the audit trail.
2. You can’t query the audit history directly, you must make an API call. I had tried fetching against the audit history table and the API would deny the request. This is the call I had to make:
The call will get all of the field changes to the target field (in this case, ownerid) that have been done to the record (in this case incident which is the system name for the Case entity).
The audit detail records will have two properties Old Value and New Value. I then created a dictionary of owners so that I wouldn’t have duplicates when I was sending the emails out and went through the audit collection With this approach you could notify salespeople that have modified a record when a contact buys a product, or when their contract is about to expire.