Audicity: Total Data History for Salesforce Orgs

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.

Free Field History

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. 

Accuracy

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. 

 A query of the Salesforce Field History object showing time precision to the second.
Time precision to the second

Incomplete History through Data Security

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. 

Field Value Tracking Limitations

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. 

Audicity trace showing the before and after values of a long text field.
Audicity trace showing the before and after values of a long text field.

Paid Audit Trail

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.

The [Bigger] Field Limit

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. 

Implementation Effort

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. 

an excerpt of the raw XML for the history retention policy section of a custom object representing the only way to view and set history retention policies for the field audit trail feature.
The only way to view and set history retention policies for the field audit trail feature - via XML

Your History’s History

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. 

The Art of Compromise

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. 

Audicity - Data History Without Compromise

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. 

Total Data Audit

Audicity has the most comprehensive and accurate data tracking capabilities of any data history tool for Salesforce. Consider:

  • Any field that is create-able or update-able and also queryable can be tracked. 
  • There is no maximum number of fields per object.
  • Before/after field values of long text and multiselect picklists are tracked.
  • Tracked changes are captured at millisecond precision.

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. 

 diagrams of standard field history behaviour where a field updated by a trigger is tracked in field history, but when field security blocks user access, changes initiated by that user will not be tracked.
Audicity enables field tracking for an update by a user without field security access, but limits the view based on permissions

More than Data Audit

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. 

Diagram of tracked changes showing a complex trace comprised of the original synchronous Apex call followed by two asynchronous apex calls.
Tracked changes showing a complex trace consisting of the original synchronous Apex call, followed by two asynchronous Apex calls.

Your Data Can Tell Stories

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. 

Moving Forward

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.

Peter Chittum
Developer Relations
linkedin icon
Hire us to build a website using this template. Get unlimited design & dev.
Buy this Template
All Templates