Field history tracking is one of the most abused features in Salesforce. I've seen orgs track everything from "created by" to "last modified date" — wasting storage, slowing queries, and creating noise for end users. After managing 15+ enterprise orgs across healthcare, finance, and manufacturing, I'll cut through the fluff: here's what to track, what to avoid, and why.
What to Track: High-Value, Actionable Changes
Focus on fields where historical context directly impacts business decisions or compliance. Track only what you can't get from standard reports or where change velocity matters.
Contract Terms (Healthcare): In a hospital billing org, we tracked
Contract_Start_DateandContract_Amount. When a payer renegotiated a contract, the history showed exactly when the change occurred (vs. relying on a dated spreadsheet). This prevented $200K+ in billing disputes.Product Configuration (Manufacturing): For a client selling custom machinery, we tracked
Configuration_Version__candRequired_Safety_Certifications__c. When a regulatory audit hit, we traced how a field change (e.g., adding a new certification) rolled out to 500+ orders in 3 days — not weeks.Lead Source (Finance): A bank tracked
Lead_Source__candLead_Origin__cfor compliance. When regulators questioned a lead's origin, we pulled the history in minutes — no manual log reviews.
Key rule: If you can answer "How does this history help me fix a problem or prove compliance?" — track it. If not, skip it.
What Not to Track: The Waste That Kills Performance
Overtracking bloats your org. Salesforce charges per 500KB of history data, and each tracked field adds storage costs. Worse, it slows down UIs and breaks tools like Einstein Analytics.
System Fields (
CreatedDate,LastModifiedDate): These are redundant. Salesforce already stores them. Tracking them adds 50+ rows per record per change — zero business value. In a retail org I audited, this wasted 2TB of history storage over 18 months.Checkbox Fields with Low Change Frequency (
Is_Active__c): If a field changes once a year, the history is useless. A manufacturing client trackedIs_Production_Line_Active__cfor 3 years — only 12 changes total. The 365 history rows cost $1,200 in storage and slowed their production dashboard by 2 seconds.Formula Fields: These don't store data — only calculations. Tracking them creates ghost history (e.g.,
Days_Since_Createdshowing "1" when a formula updated). One org tracked 12 formula fields, creating 4M history rows that never helped anyone.
Pro tip: Run this SOQL monthly to find dead weight:
SELECT Id, Field, EntityDefinition.QualifiedApiName, HistorySize
FROM FieldHistoryArchive
WHERE EntityDefinition.QualifiedApiName = 'Account'
AND HistorySize > 1000000
ORDER BY HistorySize DESC
If HistorySize is high but the field rarely changes, untrack it immediately.
Final Rule: The 20% Rule
Track no more than 20% of your custom fields. In my healthcare client's org, they tracked 70+ fields initially. After pruning, they focused on 12 high-impact fields — reduced history storage costs by 68%, and end users stopped complaining about "slow history tabs."
Field history tracking isn't about capturing everything. It's about capturing what you can't afford to miss. Audit your tracked fields quarterly. If it's not driving a decision or compliance need, turn it off. Your storage budget (and your users) will thank you.
Want to see how many wasted history fields you're tracking? Run a free health scan with OrgScanner — it’ll flag dead fields, oversized history, and compliance risks in under 5 minutes.
📚 Recommended Resource: Salesforce for Dummies — great for anyone learning Salesforce.
📚 Recommended Resource: NIST Cybersecurity Framework Guide — great for anyone security frameworks.
Need a second opinion on your Salesforce org? Request a diagnostic.
Top comments (0)