Lately, I’ve been cutting back on tv. Instead, I’ve been reading, hanging with friends and family, and occasionally contributing to side projects.
Today I focused on implementing the Field History Tracking Counter doesn’t take limit increases into account Boostr Request in Boostr for Salesforce.
By default, Salesforce only allows up to 20 fields to be specified for field history tracking per object. However, that limit can be increased, by purchasing more from Salesforce. Boostr was hard-coded to only think 20 was allowed.
Allowed # of Field History Tracking Fields Configurability
Boostr has been enhanced to allow one to configure how many field history tracking fields are allowed on the options page of Boostr.
In the example above, I’ve increased the limit to 40 and saved it. When configuring the Field History Tracking Fields for an object, the label shows how many allowed fields can be tracked based on the setting.
- This hasn’t been released into Boostr yet but hopefully should be soon!
- Also, if you’re working in multiple different orgs where the limit may differ, you may want to update this setting to reflect the current allow number of fields. However, this is probably not an issue since most orgs usually only have 20 and that’s what the setting is defaulted to be.
- I tried to find a way to programmatically find the number of allowed fields but their doesn’t seem to be a way to do this through an API or otherwise. If someone knows a way, please let me know!
One of my favorite Salesforce features is Field History Tracking. Field History Tracking allows one to track a specified set of fields’ value changes over time. The field history is tracked up to 18 months by default.
Whenever a specified field is changed, Salesforce creates a new “History” record tied to the record in question. The History record contains the following information:
- ParentId – The Id of the Salesforce record that had its field changed.
- Field – The API name of the field that was changed.
- OldValue – The old value of the field before the change was made.
- NewValue – The new value of the field after the change was made.
- CreatedById – The Id of the user who made the change.
- CreatedDate – The UTC datetime of when the change was made.
On Standard Objects, field history tracking is setup by going to fields –> Set Field History Tracking –> Checking the fields to track and Saving.
On Custom Objects, one has to first enable field history tracking on the Object Definition page. Next, Click the “Set Field History Tracking” button, check the fields to track, and Save.
Account Setup Example
Note that the “(8 of 20 selected)” text is added from the Salesforce Boostr Chrome Extension, which is highly recommended.
Account Field History Example
- Eases Troubleshooting – This allows an admin or developer to see what changes have happened to a record over time. When troubleshooting, this is a godsend because it allows one to see what happened to the data over various records in a given timeframe. For example, a particular user may be incorrectly entering data so that user needs additional training and/or the system needs additional validation.
- Auditing – Certain industries require additional auditing of data for various reasons such as complying with governmental regulations. E.g Sarbanes-Oxley or HIPAA.
- History Records don’t count towards record counts. Typically, an enterprise Salesforce org has a limit of 1GB or 500,000 records, since each record counts as 2KB. With many fields being tracked across objects, many history records can be created.
- History Objects are queryable through SOQL. This is helpful because there are times when a bug in software has caused numerous records to be updated with wrong value(s). One can query all the parent records with their old values and reset the invalid field(s) to their former values with a data correction apex script.
- Changes to fields with more than 255 characters are tracked as edited, and their old and new values are not recorded.
- If a trigger causes a change on an object the current user doesn’t have permission to edit, that change is not tracked because field history honors the permissions of the current user.
- Detail Objects part of a Master-Detail relationship can’t have their Field History Tracking used in Salesforce reports.
- Other Caveats
- Always enable Field History Tracking and specify the fields to track.
- If there are 20 fields or less, track all the fields.
- If there are more than 20 fields, choose the fields to track based on priority.
- Know that more than 20 fields can be tracked per Object for an additional cost. Contact Salesforce for more information.
- Know that Salesforce can retain history records for longer than 18 months if needed. Contact Salesforce for more information.
What other benefits, caveats, and recommendations do you have regarding Field History tracking?