Salesforce Field History Tracking Past the 20-Field Limit

Someone in a pipeline review asks a simple question: “When did this deal’s close date first slip, and who moved it?” The admin opens the opportunity, scrolls to the history related list, and finds nothing. Close Date wasn’t one of the fields being tracked. Or it was, but the change happened two years ago and the record has aged out.

My position on Salesforce field history tracking: the built-in feature is a debugging tool, not a business history. It’s good for answering “who changed this record last Tuesday.” It was never designed to answer “how long do deals sit in Negotiation” or “how often do reps push close dates at quarter end.” If those are the questions your leadership asks, stop trying to squeeze them out of the stock history list and build a change history shaped around them.

That build is smaller than it sounds. Here’s what it looks like.

The limits you’ve probably already hit

Standard field history tracking has hard edges, and most admins discover them one at a time, usually in a meeting.

20 fields per object. That’s the cap for standard and custom objects. Tasks and events get six. Once you’ve spent your 20 on compliance-flavored fields, there’s no room for the ones sales leadership cares about.
18 months in the UI, 24 via API. History older than that is gone from view unless you’ve paid to keep it. Two-year trend questions are out of reach by default.
Some fields can’t be tracked at all. Formula fields aren’t tracked. For long text areas and multi-select picklists you see that something changed and who changed it, but not the old and new values.
System-context changes can slip through. A change made by automation running in system context isn’t recorded if the running user doesn’t have permission to the field.

Salesforce Ben’s breakdown of field history tracking walks through each of these in detail. None of them are bugs. They’re the boundaries of a feature built for a narrower job than the one you’re asking of it.

The paid fix solves storage, not questions

Salesforce’s answer is Field Audit Trail, part of the Shield add-on family. It raises the cap to 60 fields per object and lets you keep archived history for up to 10 years in a big object you query with SOQL.

If you’re in a regulated industry and need a defensible, long-retention record of field changes, that’s the right tool, and you should talk to your Salesforce rep about it.

But for most RevOps teams, the problem isn’t storage. A bigger bucket of raw change rows still leaves somebody writing queries against a big object to work out how long a deal sat in a stage. You’d have more history and the same unanswered question.

Start with the questions, not the fields

The build starts with a list, not a setup screen. Write down the five to ten questions people actually ask about how records change. In most orgs they look like this:

How long do opportunities spend in each stage, on average and by rep?
How many times has this deal’s close date moved, and by how much?
When did an account’s owner change, and what was the pipeline at the moment of handoff?
Which leads changed status without a logged activity?
What was the forecast category on the last day of each quarter, per deal?

Each question names the fields you need and, more importantly, the shape of the answer. “How long in each stage” doesn’t need every edit to every field. It needs a clean row every time the stage changes, with a start time, an end time, and a duration.

That’s the core idea. You’re not logging everything. You’re logging the events your business runs on, in a form that’s ready to report.

What gets built

Concretely, a purpose-built change history in Salesforce is three pieces.

A change event object

A custom object, call it Field Change, with a lookup to the parent record, the field name, old value, new value, who made the change, when, and the source if you can capture it (UI, integration user, import). Old and new values go into long text fields of your own, so even a long description keeps its full before and after.

Because it’s a normal custom object, it’s reportable in the report builder with no extra licensing, and you decide how long it’s kept.

A capture layer that sees every channel

An Apex trigger on each object you care about compares old and new values for your watched fields and writes Field Change rows. Triggers fire whether the change came from a person in the UI, a Flow, an integration, or a bulk import, which is the gap that bites teams relying only on what the history list shows. The watched-field list lives in custom metadata, so adding a field is a config change, not a code change.

For formula fields, which never fire an edit, a scheduled job takes a nightly snapshot of the values you care about and writes a row only when the value has moved since the last run.

Interval rows for the questions about time

For stage, status, and owner, write a second kind of row: an interval. When a deal moves from Discovery to Proposal, close the Discovery interval with an end date and a duration, and open a Proposal interval. Now “average days in stage by rep” is a standard summary report, not a spreadsheet exercise.

This is the same pattern behind the reports you’ve been told you can’t build: when the report builder can’t answer a question, the fix is usually to store the answer as data, not to find a cleverer report.

What changes once it exists

The pipeline review question gets answered in the meeting. Close-date slippage becomes a dashboard component instead of an anecdote. Stage duration feeds forecasting, so a deal that’s sat in Negotiation three times longer than your median gets flagged before quarter end rather than after.

It also changes how you handle data problems. When a bulk update goes sideways, you have field-level before-and-after values for every record it touched, which makes cleanup automation and bulk updates without Data Loader much less nerve-racking. When duplicates get merged under your duplicate management rules, you can see what each surviving field used to say.

And it pairs naturally with pipeline hygiene automation: the hygiene rules decide what’s stale, and the change history tells you how it got that way.

Keep it lean

A custom change history can grow fast if you let it. A few rules keep it useful:

Watch fields with a question attached. If nobody can name the question a field answers, it doesn’t go on the list.
Set your own retention. A scheduled job can roll raw rows older than your window into monthly summaries and delete the originals. Interval rows are small; keep those longer.
Skip the noise. Ignore changes from known integration users on fields they rewrite constantly, or log them at a summary level.
Keep standard tracking on. Don’t turn it off. The history list is still the fastest way to answer “who touched this record yesterday,” and it costs you nothing.

Why you can hand this build to your AI

None of this is exotic. A custom object, a trigger with tests, a custom metadata type, a scheduled job, and a handful of reports. It’s the kind of work that sits on a backlog because it’s never urgent enough to bring in a contractor, which is exactly the class of project that small Salesforce projects are made of.

With Sentinel, your AI builds it directly in your org. Salesforce changes go to a sandbox with tests before they reach production, every action is logged, and a snapshot is taken before each deploy, so a trigger that writes the wrong rows is visible and recoverable rather than a mystery. If you want the full picture of how that holds up, it’s covered in how AI-written changes are kept safe. Pricing is flat per Sentinel and is covered on a short demo call.

Start with one question

Pick the single history question your team asks most often and can’t answer today. Stage duration is the usual winner. Build the interval rows for that one field, run them for a month, and see whether the report changes a conversation. If it does, add the next question.

Book a Demo Call and bring the history question your org can’t answer. We’ll talk through what it would take to get it on a dashboard.