This post is inspired by Jeff Berger who asked on Twitter for a declarative way to track key field changes. But not just which field and what value changed but also the elusive why the user made the change.

What Changed?

Tracking the what field and value changed, when, and by whom is easy, simply enable Field Audit History on your object and select which fields to track. Salesforce will automatically keep record of who and when a field was changed and the old and new values. This audit history supports up to 20 fields per object and is retained for 18 months. If you need to track more fields or longer retention period, Salesforce offers a paid add-on Field Audit Trail.

Why Changed?

To capture the why a field value was changed requires custom solution to collect information from the user. Jeff’s requirement was he needed a declarative solution and that’s just what we can do.

My recommendation was to introduce a custom textarea field on his page layout and use validation rule to require that this custom textarea field be populated anytime a key field is being changed (e.g. account billing address or account number).

Using Process Builder, any time our key fields change then create a child record of a custom “Field Audit History” object with the who/what/when information (redundant of standard Field Audit History) but also the why the field was changed.

Finally, reset the textarea field on the main record to blank. It’s important to reset the textarea field back to blank otherwise it would remain populated from the first time a user was required to fill it out to make a key field change and then the validation rule would never fire again for that same field, defeating the purpose of implementing this solution.

This solution keeps the user interface very simple – it’s just the page layout users already familiar with, and no code is necessary. We leverage declarative automation of Process Builder to insert records into a custom object.