Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

In one sentence: the Setup Audit Trail records who changed what in Setup for the last six months, it does not record data changes or before-and-after values, and if you have not been exporting it then anything older than six months is gone. Read it with the Delegate User column in view, because that is the column that tells you a change was made by someone logged in as somebody else.

Where it lives and what it holds

Setup, then Environments, Logs, View Setup Audit Trail. The page shows the most recent entries only. The download link gives you a CSV covering the full retained window.

Each row has a date and time, the user who made the change, a Section, the Display text describing the change, and a Delegate User. Section is the Setup area, such as Manage Users or Customise Accounts, and it is the most useful column for narrowing a search.

The same data is queryable, which is how you should actually work with it:

SELECT CreatedDate, CreatedBy.Username, Action, Section, Display, DelegateUser
FROM SetupAuditTrail
WHERE CreatedDate = LAST_N_DAYS:7
ORDER BY CreatedDate DESC

The six month window

Entries are retained for six months, and then they leave. There is no setting to extend it and no support request that recovers an older entry.

This matters more than it sounds. Audit questions arrive late. “When was this permission granted” is usually asked during an annual review or after an incident that has been quietly running for a year, and by then the answer has expired.

The fix is a scheduled export. A weekly job that queries SetupAuditTrail for the previous seven days and writes the rows somewhere durable, a big object in the same org or a table in your warehouse, costs almost nothing and turns a six-month window into a permanent record. Do it before you need it.

What is not in it

People expect far more from this log than it delivers. It does not record:

  • Data changes. No record creates, edits or deletes. That is field history tracking, and separately Field Audit Trail if you have Shield.
  • Logins. Login History is a different page, with its own retention.
  • Views. Nobody’s report runs, record views or exports appear here. Event Monitoring covers some of that ground.
  • Old values, most of the time. The Display text is a sentence, and often it names what was changed without saying what it was before. “Changed profile Sales User” does not tell you which permission moved.
  • Automation activity. A flow that runs a million times leaves nothing here. Only the change to the flow definition is logged.

Managed package installs and metadata deployments are logged, but as a wave of entries attributed to whoever ran them. A single deployment can produce hundreds of rows and bury everything else that happened that afternoon.

Reading it properly

Filter the noise before you look. Exclude your deployment user and your CI user on days when a release went out, or you will read release output for an hour.

Then watch for the changes that actually matter. In practice that is a short list: profile and permission set changes, especially anything granting Modify All Data, View All Data, or Manage Users; login IP range and login hours changes. Password and session policy changes. Sharing settings and organisation-wide defaults. Connected apps, named credentials, certificates and remote site settings. And user deactivations and email address changes.

A weekly query filtered to those sections, sent to whoever owns platform security, is a better control than any dashboard, because the volume is small enough that someone reads it.

The Delegate User column

If an administrator uses Login As to work in another user’s session and changes something in Setup, the change is recorded against the user they were impersonating, with the administrator’s username in Delegate User.

Miss that column and the log lies to you. You will conclude that a salesperson granted themselves a permission, when in fact support did it on their behalf. Include it in every export and every query.

Frequently asked

Can I build a report on the Setup Audit Trail? Not with the standard report builder. Query the object, or work from the CSV download.

Is the audit trail editable or deletable? No. Entries cannot be created, changed or removed by anyone, including administrators, which is what makes it worth something.

Does it record changes made through the Metadata API? Yes, deployments appear like any other change, attributed to the deploying user. Whether you can tell what each entry means is another question.

How quickly do entries appear? Close to immediately for the on-screen list. Do not assume the same for a query written milliseconds after the change in a test.