0

I have a auditing requirement to ensure that most code and configuration changes to our org can be related to a change request. Because our deployments can never be considered a single-source-of-truth for changes (there will always be emergency or inadvertent untracked configuration changes), I would like to be able to automatically have a report of the Setup Audit Trail parsed so it easy to then programmatically match up each audit change to a change request (in our external change management system). Right now, it seems my only option is create some custom code or perform some spreadsheet magic to parse out the Setup Audit Trail data.

Are there any tools that work with the Setup Audit Trail data? Are there any deployment tools that will automatically return the Setup Audit Trail data associated with a deployment?

Improve this question
3
  • 3
    Personally, I'd use a vendor tool like Gearset or Copado that associates JIRA tickets to deployments
    – cropredy
    Feb 17, 2022 at 17:52
  • the vendor tools also can tell you when metadata changes in the PROD org -- including direct changes to PROD (alerting you that someone has updated metadata outside of normal deployment procedures
    – cropredy
    Feb 17, 2022 at 18:52
  • Unfortunately, it was not within my purview to choose a tool, and I initially was tasked with figuring out how to do this with Metazoa's Snapshot. That tool gives you a nice view into SetupAuditTrail but no further ability to parse it or report on it.
    – bullcitydave
    Jul 10, 2022 at 19:33

1 Answer 1

Reset to default
1

There's an object you can interact with SetupAuditTrail. As such, a SOQL query can retrieve what you'd like and a scheduled Apex class could presumably make this easier to alert you of changes or send out information.

SELECT Id,Action,Display,Section from SetupAuditTrail

I see an example of leveraging this in AuditLogScanner.

However, aggregate queries are not supported so you couldn't group the above by a created date to point to any deployment. You could ORDER BY CreatedDate to assist with that linking.

However, I think the above has a lot of risk if you have strict requirements with auditing. Ignoring the need to create something custom to support even doing the above - you are indebted to relying completely on the Setup Audit Trail's functionality. It may not be tracking things you need to track (ex. report creation).

If you have strict auditing requirements, you should look towards "how" you get your changes into production - not reactively figuring out what change goes where in your external system.

Your statement that deployments "can never be considered a single-source-of-truth for changes" raises questions on your development/change process. You may not be able to jump into using git depending on your current process, but you should look to have a better view of your metadata since you do have a requirement of controlling/knowing what goes in.

It's much easier to tag your external ticket number in a git commit or, if that's an unrealistic pivot at the moment, a deployment history that a (paid) deployment tool may provide.

In terms of the "exceptions", emergency changes may go quicker into production, but should still follow a process that fits into your change management system/deployment pipeline. Inadvertent changes should happen rarely and if they do not, you should re-evaluate why they keep occurring and possibly think of lessening how many people can do significant changes in production if it's a cause for concern.

Improve this answer
1
  • 1
    and SetupAuditLog has a 6 month rolling window so you need to save it in a custom object
    – cropredy
    Feb 17, 2022 at 18:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .