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.
Douglas C. Ayers 
Sweet!
LikeLiked by 1 person
Thanks Sara!
LikeLike
Hey Doug,
Just wanted to say i really appreciate your blog, every now and then i get this mail from you when you posted a new thing, it’s awesome. Just being a junior these examples are pure gold for me. I try to follow and mostly try to do them in a developer org just to practise and learn.
thx 🙂
LikeLiked by 2 people
Hi Louis! Thank you for the kind feedback, that means a lot to me! Glad you are finding the posts helpful 🙂
LikeLike
What a fantastic idea! We have many fields to capture different reason codes on objects. Using one field to enforce requirements and organize them into a related list is brilliant. Thanks to @jeffereyberger for chasing down the why and Doug for the how.
LikeLiked by 1 person
Glad you like it Brian!
LikeLike
Hi Doug, I like your no code solutions very much. Just a quick question here, if more than one key fields changing at the same time, how can this handle?
Thanks,
Sree Amirisetti
LikeLiked by 1 person
Hi Sree, thanks for the kind feedback; I’m glad you find my posts helpful.
If you want to track multiple key fields, update the validation rule to consider all key fields changing, for example:
AND( OR( ISCHANGED( fieldA ), ISCHANGED( fieldB ) ), ISBLANK( Field_Change_Reason__c ) )In your process builder, you would have decision diamonds checking for different key fields having changed and then create an audit record per field. This would require the use of “Evaluate the Next Criteria” so that after one decision diamond was evaluated, the next one to check the next key field would be executed. More details in the docs.
LikeLike
still valid thanks
LikeLiked by 1 person
Hi Doug! Thanks for this. It’s brilliant – as always from you.
Keen on your thoughts to add a prompt for the user to attach a file for justification of the field change (not just text).
Since a validation rule only comes up when you don’t fill in the justification, perhaps a validation rule PLUS a quick action would allow focusing the user on the field change justification, including a prompt to attach a file if required in certain circumstances.
Your solution covers the use case of “multiple fields of interest” nicely. Some customers may want one field change justification record per field (like Field History does), so the PB (or Flow, as we’re leaning these days) could generate the appropriate records as required.
LikeLike