By
Peter Chittum
September 27, 2024
•
6
min read
The ability to track and attribute data changes is foundational to data security. Naturally Salesforce offers both free and paid premium features to customers depending on the risk profile they operate at. These are Field History and Field Audit Trail respectively. Field history tracks changes on up to twenty fields per object and retains the data for up to two years. Field Audit Trail ups the field limit to 100 and includes indefinite data retention, along with configurable automatic retention rules.
For many Salesforce customers and use cases, these are sufficient. But there are limitations and challenges with each of these features. Accuracy, completeness, implementation challenges and data management could all pose problems or create friction for you depending on your risk profile or the makeup of your Salesforce team.
Of the field history limitations, several such as data retention time and number of audited fields can be bought through the paid field audit trail feature. So no sense in addressing those problems. But there are other challenges you can’t buy your way out of.
Field history is tracked to the precision of a second. In many cases this will be fine. But in a high-volume, high velocity situation, it is possible that changes made to the same record by two users within that second of precision will not be able to reflect the order of those two changes.
Salesforce’s security model uses permissions to ensure that an object, field, or record is accessed by the right user at the right time. However, sometimes an automation will make changes. For instance, a trigger might update a value that a user themselves wouldn’t have permissions to do. This is called system context execution. It can happen in Apex, and also is the execution mode for record-triggered flows, process builder flows, schedule-triggered flows and platform event flows.
In order to respect permissions, field history does not record changes made via system context when the triggering user would not have access to that data (for instance via field level security).
While this ensures sensitive data is not surfaced to users who should not see it, it also means the field history may be incomplete.
One final limitation we’ll address is pretty well known: no tracking of old and new values for long text and multi-select picklist field types. While this is an understandable compromise, it still can mean a lack of completeness in tracked data.
Field Audit Trail is branded under the Salesforce Shield family of features which provide enhanced security features for orgs where a more strict risk profile might be needed. As a paid feature it does address certain limitations. However, even with Field Audit Trail, there are still some concerns you may encounter.
While you can pay for more fields to track, not every org will be able to track every single field. With Field Audit Trail you track up to 100 fields. (Yes, the documentation says 60, but there is an undocumented limit of 100 which can be requested from your Salesforce account executive). This is much better. I would guess the Salesforce product team who designed this feature did the research at the time and figured 100 was more than enough to meet the needs of most likely customers for this feature. But we still couldn’t say this would meet the needs of complete data history.
When an object might have up to 800 custom fields, Field Audit Trail might fall far short of requirements.
While field history is 100% managed through a clean user interface, Field Audit Trail is not. Configuration of retention policy is done manually through metadata via the object metadata’s XML file.
Field Audit Trail is not simply an extended retention period for your Field History data. Once enabled, Field Audit Trail archives field history older than 18 months from a standard SObject to the FieldHistoryArchive big object. This isn’t a huge deal, but it does mean that the access to the entire history of a record is not seamless.
None of these challenges or limitations are empirically bad, they are simply the necessary compromises that Salesforce has made when setting the scope of these based on what their customers will accept—or pay for them in the case of Field Audit Trail. Salesforce excels at finding the compromise point for features. Every software company needs to do this when trying to create a feature that has maximum interest across many customers with different needs.
But this is little consolation if you find yourself on the other side of that compromise point.
If you find yourself thinking about alternative ways to track your org’s history because of the limitations in completeness, accuracy, implementation effort or storage complexity, Audicity might be for you.
Audicity has the most comprehensive and accurate data tracking capabilities of any data history tool for Salesforce. Consider:
Audicity also takes advantage of Salesforce’s permissions structure to ensure that out-of-permission system context changes are tracked, but only viewable by users who have the permissions to view the original tracked data.
Processity was founded on the principle that your data tells a story. But you need the right data to tell that story. Salesforce transactions can often be complex. The initial transaction can have many branches, including before and after logic, flows, workflows, assignment rules, roll-up summary fields, and that doesn’t even count asynchronous Apex calls and platform events.
To truly tell the rich story that happens in a transaction, Audicity uses the principles of observability to trace the entirety of what occurs after your user clicks on a button. Once installed and enabled, it is always on.
Unlike the Apex log, Audicity will capture transactions even when you’re not looking for them.
This means that beyond the most comprehensive data history solution, Audicity can also be an invaluable transaction introspection, observation, and troubleshooting tool. And unlike the Apex log, Audicity will capture transactions even when you’re not looking for them. This can be indispensable if your org suffers from sudden or intermittent problems.
Imagine if you had a complete and accurate history of every action taken in your Salesforce org. With the right understanding and analysis, you would be able to learn the real and true processes your users were following. You might find real bottlenecks and inefficiencies that could be addressed. You might discover how some users have found much more efficient ways of doing their work.
Processity is exactly this tool for Salesforce. This technological approach is called Business Process Mining. And we’re building it now.
We built Audicity to supply Processity with data that has the completeness and accuracy required to redefine business process mining for Salesforce. We see ourselves as the first and most important customer for Audicity.
It is a happy side-effect that in doing so we’ve also redefined data history capture for Salesforce. With Audicity, Salesforce customers can move beyond the data history compromises around accuracy, completeness, implementation complexity and data management.
We’re excited about Audicity. Collectively, the Processity team has decades of Salesforce experience. Seeing such a detailed and complete capture and attribution of data changes in a transaction was something beyond what most of us had imagined. If you'd like to give Audicity a try, check out the listing on AppExchange.
But we’re not done. Now that we have a complete data source that any Salesforce customer can use, we have our eyes firmly on the target of launching Processity. And you should too. Follow us on LinkedIn and join us in revolutionising how data fuels business growth.