When several admins or consultants work side by side on the same Salesforce org, it’s often difficult to keep track of configuration changes, especially if teams are remote and no CoE is in place.
There are many reasons why you should get yourself a forensic tool to investigate configuration changes:
Suddenly broken features are hard to fix. Checking what’s been recently changed in your org is the first port of call. For instance, enterprise orgs share some configuration areas between Apps and departments. Opportunities may be only used by the Sales team but then Products may be shared between the Sales department and Customer Service. If the Customer Service administrator modifies a Formula field on the Product object this might impact the Sales App and the Sales administrator will need to know that.
When things go pear shape, it’s always good to be able to learn from what went wrong: some changes may have been applied directly into production, a code freeze may not have been respected, a junior admin may have done a mistake, etc… Although some will see this as a way to blame others, I prefer to see it as a way to improve a process.
It can also be useful to track down who built a specific feature that needs to be improved or refactored. Who created this custom object, who last touched this workflow rule, etc… Granted, its author may have left your company but that’s another story and at least you get some contextual information.
Listing Configuration Changes
To list configuration changes, navigate to Setup, then type Audit in the Quick Find box. This will narrow down the menu options to View Setup Audit Trail. This page shows the last 20 changes done to your org. It can be useful when reacting to a recent change. But if you really need to investigate what happened to your org then you will want to pull more data.
Today, there are three ways to list configuration changes:
1. 🖥️ View on screen the last 20 changes from the View Setup Audit Trail.
1. 📄 Download a CSV file containing the last 6 months of changes.
1. 🤖 Run a SOQL query via the SOAP API on the sObject SetupAuditTrail and get every tracked change.
The CSV file uses the same format as displayed on screen. The SOAP API implementation introduces a couple of differences:
- SetupAuditTrail.Display pulls the data from the Action column, and SetupAuditTrail.Action is, in fact, a short version of the Action column – yeah, I know…
- Source Namespace Prefix is not exposed to the API.
Here is a list of the fields queryable and their equivalent column in the CSV file:
- Action: short version of the Action column.
- CreatedById: Id of the User column.
- CreatedDate: Date column.
- DelegateUser: Delegate User column.
- Display: Action column.
- Id: record ID not available in the CSV file.
- Section: Section column.
The closer you can get to the CSV file is by running the following SOQL query:
/* WHERE CreatedBy.Profile.Name = 'System Administrator' */
ORDER BY CreatedDate DESC NULLS FIRST
- Again, Source Namespace Prefix is not queryable.
- Customise the WHERE clause to your exact need or get rid of it for a full dump.
- Drop the LIMIT for a full dump.
Depending on what you’re after, these three methods should be useful to help you find who’s changed what in your org, but if you need to dig deep you’ll have no other help than your fluency in SOQL. Several months ago, I needed a tool to do an in-depth investigation and created a Google Sheet for this purpose.
Spotting Unexpected Changes
To get cracking with your investigation, you need to go through the following steps (I’ll provide a better explanation at the end of this post):
- Clone the Google Sheet template.
- Pull the Setup Audit Trail data from Salesforce.
- Upload the data in the Log tab of your Google Sheet.
- Start your investigation from the Dashboard, then the Data Cruncher and finish with the Log.
The big picture
Navigate to the Dashboard tab and you’ll find two charts.
- The first chart is a timeline of the changes made to your org year to date. This may help you to communicate with key stakeholders about the various phases of a project and how is the charge distributed, what are the trends, etc…
Just below is a pie chart showing what changes are about (Admin, Config, Dev). This can be used in a weekly report to discuss the amount of development, but cannot be related to the actual effort or cost: resetting a password counts for as much as writing a class! The split is based on the data from the Categories Setup tab.
The Data Cruncher tab is a pivot table pulling its data from the Log tab. I’m proposing a default setting with Categories and users’ Names as rows and Months as columns. This gives you a “who was doing what each month” but the idea is to let you massage the log data by trial and error. Play around with the rows, columns, filters and values, this will give you different perspectives each time.
Playing around with the tool will let you discover interesting information you were not even looking for!
Once you’ve narrowed down your scenarios in the Data Cruncher, chances are that you’ll want to drill down to the individual change level. For this, the best is to return to the source of the data, the Log tab. Using the various column filters, you’ll be able to return some pretty accurate information.
To take ownership of this spreadsheet and customize it to your taste, you need to understand how it works. The output is done on the Dashboard and Data Cruncher tabs. The input is the Log tab. The Categories Setup tab enriches the Log tab with categories (Dev, Config, Admin).
To start analysing your setup audit trail:
- Empty the cells in columns A to E of the Log tab (do not empty the grey columns).
- Import the fresh data without Source Namespace Prefix in the Log tab.
- “Copy” and “Paste Formulas” on columns F to H from top to bottom.
The Categories Setup tab is already configured in my template. But don’t hesitate to double-check the mapping Section to Dev, Config or Admin. It’s a one-off thing to do. Once set to your liking, you’ll just have to clone your own template into a new spreadsheet to be used in a new investigation. Ping me on Twitter (@fcathala 🐸) if you need any help.
Google Sheet are free and I suggest that you keep all your old versions and always start an investigation on a new spreadsheet rather than overwriting an old one.
Related Posts & Resources
- Salesforce Help: Changes tracked via Setup Audit Trail
- Salesforce Dev Doc: SOAP API Guide
- Adam Torman: Using the Setup Audit Trail API
- Andy Fawcett: Setup Audit Trail API in Winter’16
- Daniel Peter: AuditForce
- Google: Introduction to Google Sheet
I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.