Turning on Field History Tracking in Salesforce
It takes about four minutes if you know where to look, and about forty-five if you don't. The feature lives in Setup under Object Manager, which most admins navigate to by typing "Object Manager" into the Quick Find box. From there you pick the object you want to track—usually Account, Contact, or Opportunity in my experience—and toggle Field History Tracking on at the top of the Standard and Custom Fields page. That part is straightforward. The confusing part is what happens next. Once the main toggle is on, Salesforce reveals a button labeled Edit Related List. Clicking it opens a list of all fields that are eligible for tracking. Not every field shows up. Custom text fields with more than 255 characters are excluded by design. Picklist fields show up as tracked, but the history record only captures the label value, not the API name. That distinction mattered to me once when an auditor asked why three different "Priority" values appeared to map to the same historical entry—I had built three custom priority picklists on Account because someone thought it would be cleaner than extending one shared picklist, and Salesforce was happily tracking all of them without any way to visually correlate them in the history view. The fields you enable there are the ones that will populate the History related list on the record page. There is no UI component needed on the layout itself to make it work, but if you want users to actually see the history, you need to add the History related list to the page layout. I learned that the hard way. We enabled tracking on Account and Contact fields for about eighty people across three business units, and for three weeks nobody could find the data because it sat in a related list that wasn't on any layout. The setup was correct. The visibility was the problem.
After you save your field selections, history starts recording immediately for subsequent edits. The first time someone modifies a tracked field after enabling it, Salesforce writes a history row. It does not backfill previous changes. If you need historical data going back further than the enable date, you are looking at a data export and merge workflow, or a third-party tool likeOwnWorld or Simplicite. I once tried building a trigger to snapshot old values into a custom junction object, but that approach had a fundamental flaw: triggers can only see the current and previous state of a record at the moment of change. You cannot retroactively reconstruct five years of field edits from a trigger alone. The only honest answer for deep historical is scheduled exports or a dedicated audit tool. There are limits worth knowing before you go wild with it. Standard objects support field history tracking up to twenty fields per object. Custom objects have the same twenty-field cap. If you need more, you build a separate tracking mechanism. The history data is retained for seven years by default on standard objects, but you can reduce that through Security Settings if you have compliance requirements that demand shorter retention. Salesforce does not let you extend retention beyond seven years natively. Another thing that trips people up is the difference between Field History Tracking and the Event Log Files. Field History is record-level and readable directly from the Salesforce UI. Event Log Files are row-level transaction logs you download as CSVs, and they contain metadata about who ran what query and when. They serve completely different purposes. I watched a junior admin try to use Event Log Files to replace field history because "it has more rows," not realizing that Event Logs do not store field-level before and after values. They are operational logs, not audit trails. Mixing them up caused about two days of confusion and a ticket to the security team that didn't need to exist.
The API name of the history object is the same as the source object plus "History"—AccountHistory, OpportunityHistory, and so on. You can query it like any other object: SELECT Field, OldValue, NewValue, CreatedDate, CreatedBy.Name FROM OpportunityHistory WHERE OpportunityId = '006xx000001ABC' This is useful when you need to build reports or dashboards around historical changes, but note that the History object only stores data for the fields you explicitly enabled. If you forgot to check a field when setting it up, the data is gone from that point forward. There is no undo button on the field selection, only an Edit button that lets you add or remove fields for future tracking. Past data for newly added fields does not exist. New fields added to the object after you set up tracking also do not auto-enable; you have to go back and include them manually.
I used to enable field history on every field of every object "just to be safe," and that was a mistake. It bloats the History related list, slows down page loads on large records, and makes it harder for support teams to find meaningful changes among the noise. I now track maybe five to eight high-value fields per object—owner changes, stage changes on Opportunity, account rating on Account, and the fields that compliance cares about. The rest I leave alone unless someone has a concrete use case for it. If you need a download link for anything related to this, the only official resource is the Salesforce Help article on Field History Tracking, which you reach from Setup by searching "Field History Tracking" in Quick Find. Third-party tools like OwnWorld, Simplicite, or SalesLoft's history extensions offer extended retention and better reporting views, but they are optional. The native feature covers most orgs adequately. The main downside to the native feature is that it is blind to records created and then immediately deleted before any tracked edit occurs. A record that lives for five minutes and never changes a tracked field leaves zero history. Also, field history does not capture workflow field updates in a way that distinguishes them from manual edits—the history row just says the field changed, not whether it was a user or a flow that made it happen. If audit clarity matters, you build a custom change log object with flags for automated versus manual updates, or you use a platform event with a traceability layer.
That is basically how it works. Enable it in Object Manager, pick your fields, add the History related list to layouts, and accept the twenty-field and seven-year limits as permanent constraints. Plan around them instead of fighting them.
Get the Full Details
