Customize Salesforce Field History Tracking – An Example

The Use Case: The Need for Better Field History Tracking

While the possibilities can be nearly endless, custom development can take a lot of time, and leave your client with more technical debt than they can handle once you’re gone. Time is typically your most valuable resource when on a project cycle, and every hour you save can be precious. In any line of consulting, building off an already great idea can be a great way to avoid starting from scratch. Whether it’s using reusable code, pulling from past experience, or adding your own improvements to a problem someone else has already solved, there are many ways to leverage Salesforce features to extend functionality.

In a recent use case, a client needed the ability to track when fields in Salesforce were changed, and by whom. While your first guess might be to just turn on Salesforce’s built in field history tracking, the standard functionality wasn’t enough. Unfortunately, some areas of Salesforce have less wiggle room when it comes to customization, and field tracking is one of them.

Our client needed the ability to go back into history logs and edit historical data. This isn’t a common use case, but it was a necessity that the client has the tools to do so. While creating a custom solution, we had to do so in a way that was dynamic and easy enough to maintain, as well as friendly enough to mass import hundreds of thousands of historical records from a legacy system.

Starting from ground zero, a custom solution that meets all these requirements could take several resources and time that may have been needed elsewhere. Luckily, half the work was already done for us. Salesforce already had a tool that did nearly everything we needed. So, what if we took their ideas and added a few layers of our own on top?

Using Salesforce Features to Extend Functionality

Summarizing at a high level what the essentials of Salesforce’s field history tracking were, we devised that we needed to capture a few basic points of data:

•  What data was changed

•  Who it was changed by

•  What the old & new values were

•  When it was changed

The next step was to think about how Salesforce actually shows this data to its users. If you look at the field history tracking related list in Salesforce, each change was shown as a line item. In Salesforce layman’s terms, that would determine that each change would be its own record.

Just by analyzing what work has already been done, we had an idea of what we needed, how to approach creating the data, and how to display it. Creating our own custom solution also helped us work around Salesforce’s 20 tracked field limit.

Why do all the work when someone has already done most of it for you?

The Solution: Flows

In order to achieve our task in the simplest, most dynamic way possible, we used Salesforce’s Lightning Flows.

We created a master-detail relationship between opportunity and a new object, Opportunity History. Here we created fields for all the data that we summarized earlier – field change, date change, new value, old value, user, and lookup to opportunity. By adding the same type of process separately for each field type, and a simple guideline for adding the required data fields, we developed an easy-to-maintain process that ran efficiently in one Flow.

While this project had the potential to burn numerous resource hours to achieve, relying on people who have already partially solved our solution saved us a lot of time. Tracking and maintaining new tools to keep in your toolbox is a good practice in any field. It will not only save you time during your next project, but allow you to work efficiently, and devote your time to your client’s additional needs.

Do you have this same need in your organization? Contact us to discover our process.