Setup Audit Trail

Why Setup Audit Trail Matters
In any organization with multiple administrators, changes to configuration can happen frequently and sometimes unexpectedly. A field disappears, a validation rule stops firing, a user suddenly has elevated permissions, or a workflow behaves differently than before. Without a way to see who changed what and when, troubleshooting becomes guesswork and accountability becomes impossible. Setup Audit Trail is Salesforce's built-in answer to this problem. For the Advanced Administrator exam, it falls under the Auditing and Monitoring domain, and you are expected to know exactly what it captures, what it does not capture, how long data is retained, and how it differs from other auditing tools such as Field History Tracking, Login History, and Event Monitoring.

What Is Setup Audit Trail?
Setup Audit Trail is a log of administrative and configuration changes made in the Setup area of a Salesforce org. It records changes made by administrators (and anyone else with Setup access) to metadata and org-level settings. It answers the question: Who made this configuration change, and when did they make it?

Key characteristics you must memorize:
• It tracks changes made in Setup, not changes to record data.
• It is available in all editions that support Setup access (Contact Manager, Essentials, Group, Professional, Enterprise, Performance, Unlimited, and Developer editions).
• The Setup Audit Trail page displays the most recent 20 entries on screen.
• You can download a CSV file containing the last 180 days of setup changes.
• After 180 days, the data is no longer available from Setup Audit Trail.
• You access it via Setup → Security → View Setup Audit Trail (in Lightning Experience, search for "View Setup Audit Trail" in Quick Find).
• Viewing it requires the View Setup and Configuration permission.

What Does It Track?
Setup Audit Trail captures a broad range of administrative changes, including (but not limited to):
• Administration changes: company information, default settings such as language or locale, multiple currency changes, user creation and deactivation, portal and community user changes, role changes, profile and permission set changes, record type changes, email address changes for users, password policy changes, and security settings.
• Customization changes: creation, modification, or deletion of custom objects, custom fields, page layouts, field-level security, validation rules, workflow rules, approval processes, flows, Process Builder processes, custom tabs, custom apps, custom buttons and links, and picklist value changes.
• Security and sharing changes: organization-wide defaults, sharing rules, public groups, session settings, network access (trusted IP ranges), login IP ranges on profiles, and Salesforce CRM Content permissions.
• Data management: use of Data Loader (mass transfer, mass delete), import wizard usage, mass email, and mass reassignment of records.
• Development changes: Apex classes and triggers, Visualforce pages, static resources, changes deployed via change sets, and installed or uninstalled packages.
• Other tracked items: login as another user (delegated administration or admin login as user), Chatter settings, Email templates, Territory management changes, and changes made through the Metadata API.

What Does It NOT Track?
This is one of the most heavily tested areas. Setup Audit Trail does not track:
• Changes to record data (for example, who changed the Amount on an Opportunity). That is Field History Tracking or Field Audit Trail.
• Login attempts, IP addresses of logins, or login failures. That is Login History.
• Detailed user activity such as report exports, dashboard views, or API calls. That is Event Monitoring (part of Salesforce Shield or available as an add-on).
• Changes to individual report or dashboard content (although some report and dashboard folder sharing changes may appear).
• Data stored more than 180 days ago (unless you have exported and archived the CSV yourself).

How It Works
Whenever an administrator makes a change in Setup, Salesforce automatically writes an entry to the audit trail. Each entry contains:
• Date: the date and time the change was made.
• User: the username of the person who made the change.
• Source Namespace Prefix: populated if the change came from a managed package.
• Action: a description of what was changed, such as "Changed profile Standard User: Field-level security for Account.Rating changed from Read Only to Edit."
• Section: the area of Setup where the change occurred, such as Manage Users, Customize Accounts, or Security Controls.
• Delegate User: if an administrator logged in as another user and made a change, this column shows the admin who was actually logged in, which is critical for accountability.

The on-screen view shows only 20 entries, so the practical workflow for a real investigation is to click Download to retrieve the 180-day CSV and filter it in a spreadsheet. Because the data expires after 180 days, best practice for compliance-driven organizations is to schedule a periodic export and archive the files externally. There is no native scheduling for this download, so it is a manual process or must be automated via the API (the SetupAuditTrail object is queryable via SOQL using the API, which is a point that sometimes appears in advanced questions).

Comparing Setup Audit Trail to Other Auditing Tools
The exam frequently presents a scenario and asks which tool fits. Keep this comparison clear in your mind:

• Setup Audit Trail: Configuration and metadata changes by administrators. 180 days of history, downloadable CSV, last 20 entries on screen.
• Field History Tracking: Changes to specific field values on individual records. Up to 20 fields per object (standard), retained 18 months via UI or 24 months via API. Displayed in the History related list.
• Field Audit Trail (Shield add-on): Extends field history retention up to 10 years and allows tracking of up to 60 fields per object, with retention policies defined via Metadata API.
• Login History: Who logged in, when, from what IP, with what status (Success, Failed: Invalid Password, etc.). Retained for 6 months, downloadable CSV, shows last 20,000 records in the UI.
• Event Monitoring (Shield): Granular user activity logs such as report exports, API calls, Lightning page views, and URI access. Delivered as Event Log Files, typically retained 1 day (standard) or 30 days (with Shield).
• Identity Verification History: Tracks identity verification attempts such as two-factor authentication.
• Debug Logs: Tracks code execution and system processes for troubleshooting, not for auditing user changes.

Common Real-World Scenarios
• A validation rule is suddenly blocking saves and nobody admits changing it. Setup Audit Trail shows which admin modified the rule and when.
• A user complains they lost access to a tab. The audit trail shows a profile change made by a specific administrator.
• Auditors ask for proof of who changed password policies in the last quarter. You download the CSV and filter on the Security Controls section.
• A field was deleted and you need to know who deleted it before restoring from the Recycle Bin (custom fields remain in the Recycle Bin for 15 days).
• Someone mass-transferred records using Data Loader and you need to identify who ran the job. The audit trail logs mass transfer actions.

Exam Tips: Answering Questions on Setup Audit Trail

1. Memorize the numbers. The exam loves specific figures. Setup Audit Trail shows the last 20 entries on screen and lets you download 180 days of history. If an answer option says 90 days, 6 months, 1 year, or "last 50 changes," it is a distractor. Be careful: Login History is also roughly 6 months, which is why it is easy to confuse. Associate "180 days" strongly with Setup Audit Trail.

2. Separate configuration from data. If the question describes a change to a record (an Opportunity stage, a Case status, an Account phone number), the answer is Field History Tracking or Field Audit Trail, never Setup Audit Trail. If the question describes a change to a setting, object, field definition, profile, permission, rule, or process, the answer is Setup Audit Trail.

3. Watch for the "who logged in" trap. Questions about login times, IP addresses, failed login attempts, or suspicious login locations point to Login History, not Setup Audit Trail. Setup Audit Trail only records that an admin used "Login As" to access another user's account, not general login events.

4. Know the Delegate User column. If a scenario describes an administrator logging in as another user and making changes, and asks how to identify the real person responsible, the answer involves the Delegate User column in Setup Audit Trail.

5. Understand the retention limitation. If a scenario says the company needs to retain configuration change history for several years for compliance, the correct answer involves regularly downloading and archiving the CSV (or querying the SetupAuditTrail object via API and storing it externally). There is no setting to extend Setup Audit Trail retention beyond 180 days, and Field Audit Trail does not extend Setup Audit Trail.

6. Recognize edition and permission requirements. Setup Audit Trail is available in essentially all editions with Setup access and requires the View Setup and Configuration permission. It is not a Shield feature and does not require a paid add-on, unlike Event Monitoring and Field Audit Trail.

7. Eliminate options by scope. When asked "which tool would an administrator use to determine…", quickly classify the scenario: configuration change (Setup Audit Trail), record value change (Field History), login event (Login History), detailed user behavior such as report export (Event Monitoring), or code execution (Debug Logs). This classification resolves most auditing questions in seconds.

8. Expect scenario-based wording. The Advanced Administrator exam rarely asks "What is Setup Audit Trail?" directly. Instead, it describes a situation such as "A sales manager reports that a field is no longer visible on the page layout. The administrator did not make this change. How can the administrator determine who did?" The answer is to review Setup Audit Trail. Read the scenario carefully, identify whether the change was in Setup, and select accordingly.

9. Remember what is included in the CSV. The download includes Date, User, Source Namespace Prefix, Action, Section, and Delegate User. If a question asks what information the audit trail provides, these are the fields to recall. It does not include IP address or before-and-after values for every change (though many Action descriptions do include old and new values for things like field-level security or picklist edits).

10. Do not overthink mass operations. Mass delete, mass transfer, and import wizard usage are logged in Setup Audit Trail because they are initiated from Setup or administrative tools. If a scenario asks who ran a mass transfer of records, Setup Audit Trail is a valid answer even though the records themselves changed.

Summary
Setup Audit Trail is the administrator's primary tool for tracing configuration changes within an org. It logs who changed what in Setup and when, displays the latest 20 entries on screen, and allows export of 180 days of history as a CSV. It does not track record data changes, login events, or detailed user activity, each of which has its own dedicated tool. For the exam, anchor yourself on the key figures (20 entries, 180 days), the required permission (View Setup and Configuration), the Delegate User column, the need to archive exports for long-term retention, and the clear distinction between configuration auditing and data auditing. Master those points and you will handle any Setup Audit Trail question with confidence.