Salesforce is one of (if not the most) powerful platforms to manage customer data and relationships for businesses. One of the most telling signs that a business is successful is growth. But as businesses grow, so does the complexity of their org. And while Uncle Ben (Parker, not McCarthy) may have told Peter Parker, “with great power comes great responsibility”, I’ll add my own spin: with great growth comes great responsibility.
As orgs become more complex, it becomes increasingly important to monitor changes made to its data to ensure compliance, maintain data integrity, and understand user behavior. There are two tools that admins can use for monitoring changes: Field History Tracking and Audit Trail. Although both serve to provide visibility into what has changed, they differ largely in scope, usage, and functionality.
What is Field History Tracking?
Field History Tracking is a feature that allows you to track changes to individual fields on an object. For example, you’d like to know a specific lead’s previous owner and what status updates were made by its current owner. This tool is especially useful when you need to monitor how specific data points evolve over time.
In the example above you can see that for the Lead Andy Smith, the initial owner was Awesome Admin before it was transferred to Amy Agent who has since made three status changes from New to Contacted, to Nurturing, and finally to Qualified.
Key Features of Field History Tracking:
- Detailed Information: It captures not just the new value, but also the old value and the user who made the change. The entry also includes the date and time when the change was made.
- Retention Period: The history data is retained for up to 18 months in the org and up to 24 months in the API.
- Reporting: Field history data can be used in reports, so you can make custom reports that analyze trends and changes over time.
It’s also great that field history tracking can be enabled for several fields per object, specifically up to 20 standard or custom fields.
Use Cases for Field History Tracking
Many use this feature to keep an eye on compliance, such as tracking changes to sensitive fields like customer data or financial information. Since it analyzes field changes over time, it can also help identify trends (or bottlenecks) in your business processes. For example, by tracking opportunity stage changes, you can look through patterns on why deals get stalled at specific stages. The results can help you identify inefficiencies in the sales process or areas where sales agents may need additional training.
Another use case is for ensuring accountability within your org by maintaining a clear record of who made changes to critical fields. Since Field History Tracking logs the user responsible for each change, it’s basically a transparent audit trail that can be used to address any discrepancies or unauthorized alterations.
Setting Up Field History Tracking
- Decide on the object that you want to track field history for. In this example, I’m doing it for the Case object. Go to Setup > Object Manager > Case.
- Select Fields & Relationships from the left and click “Set History Tracking” on the upper right.
- The next window should show you the object’s list of fields, but if you’re setting this up on the object for the first time, a checkbox for enablement should appear first (like for the Lead object below).
- Select the fields that you want to keep track of. In my imaginary business, the Case object is the most important, so I’m selecting all its fields. I only have 16 fields in here, which is below the 20-field limit, so we’re all good.
- Hit Save!
- We won’t be able to see the Case History if the page layout does not have it, so our next step is to add the history related list. On the left, click Case Page Layouts (or just Page Layouts if you’re on a different object) and select the page layout you’re using.
- Click Related Lists and drag the Case History related list onto the Related Lists part of your page layout.
- Hit Save!
- You should now see the related list when viewing Case Records, and any changes made to the fields moving forward shall be recorded there.
What Is the (Setup) Audit Trail?
While Field History Tracking focuses on specific field changes to individual records, the Setup Audit Trail tracks administrative changes. For example – modifications to user permissions, data imports, or configuration changes.
The Setup Audit Trail provides a broader view of changes made within the Salesforce org itself. I find that taking note of the whole name “Setup Audit Trail” makes it easier to remember that this tracks changes made “within Setup”, which is quite a contrast compared to Field History Tracking.
Key Features of Audit Trail
- Admin-Level Tracking: this captures changes at the admin level, meaning changes to org settings, profiles, roles, and more can be tracked.
- Comprehensive: like Field History Tracking, Audit Trail also logs who made the change, what change was made, and when it was made.
- Retention Period: The setup audit trail displays the last 20 or so changes made in the org. However, it retains data for the last 6 months, accessible by downloading the .csv file of the audit trail history.
- Accessibility: No configuration steps are needed here! The Audit Trail can be accessed through the Setup menu, making it very easy for admins to review the most recent changes.
Use Cases for Audit Trail
Most businesses use this for security, as most things done within Setup may affect larger groups of users or even the entire org. Monitoring these types of changes ensures that your org remains secure. For example, if a delegated admin accidentally grants elevated permissions to a group of users, the Audit Trail can quickly help identify who made the change and when, making it easy to correct swiftly before any potential security breach occurs. This also proves that the audit trail can aid in troubleshooting certain situations.
Imagine a possible scenario where a critical process suddenly stops working as expected. By reviewing recent administrative changes through the Setup Audit Trail, you discover that a new validation rule was implemented the day before. Identifying this change enables you to roll back the rule or adjust its formula, ultimately saving time and minimizing disruption. Reviewing recent administrative changes can really take you far!
History Tracking vs. Audit Trail: Which Should You Use?
We now know the features and use cases for both of these change-monitoring tools. While both are similar in the sense that they provide visibility into changes, it’s obvious how they serve different purposes and are best suited for different scenarios.
Consider using Field History Tracking when you need to monitor changes to specific data points at the record level (aka fields) that directly impact your business processes. These may include opportunity stages, case statuses, or critical custom fields.
On the other hand, use the Setup Audit Trail when you need to track metadata changes at the administrative level within your org. This is particularly useful for monitoring changes to user permissions, security settings, and other configuration changes that could impact the overall functionality and security.
Some managed packages also make setup changes in the background especially when an update has been rolled out. The audit trail can also display these changes, and the package appears as the user who made the change. See the below example where FSL (Field Service Lightning) appears as the user who made changes.
Final Thoughts
Monitoring changes in Salesforce is crucial not just for maintaining data integrity, but also for ensuring compliance and understanding user behavior. By knowing the advantages of using either Field History Tracking or Audit Trail, you can gain comprehensive visibility into changes at both the record and admin levels.
Understanding when and how to use each will help you effectively manage your Salesforce org by safeguarding sensitive data and troubleshooting issues. What other ways do you track changes in your org as an admin? Leave them in the comments below!