A Salesforce org audit checklist: five areas to review
We divide a Salesforce org audit into five areas: automation, data, integrations, access and the admin backlog. This checklist gives the place in Setup to look for each check, what a bad result looks like, and how to turn the findings into a ranked plan.
How long it takes depends on the size of the org and how much of it is documented. It is a starting point, not a security or compliance certification.
Before you start
Pick one person to own the audit and agree one rule. Our rule is that an audit finds problems and does not fix them. Fixing as you go changes the evidence and can hide patterns. Write each finding down first.
Use a sandbox for anything that changes settings, and read-only access in production for everything else. Several checks keep only a short history, so on day one export these:
- the Setup Audit Trail download, which covers 180 days;
- Login History, which shows up to 20,000 records from the past six months;
- a screenshot of System Overview, API Usage, which shows the last 24 hours only.
Limits quoted in this guide were read on 28 October 2026 and can change.
Tools: one has gone, and four help
Salesforce scheduled the Optimizer app for retirement as of Winter '26, so advice that tells you to run it is out of date. Salesforce's help article lists manual alternatives, and a Salesforce admin blog points to Org Check, a tool from Salesforce Labs that you install into the org. Four others are worth knowing:
- Org Check is organised by data model, security and access, automations and programmatic code.
- Health Check (Setup, search for Health Check) scores your security settings from 0 to 100 against a Salesforce baseline. Its Fix Risks button can change settings in bulk, which can affect integrations or user access, so test in a sandbox first.
- Code Analyzer version 5 scans Apex, Visualforce, flows and Lightning components. Version 4, the old Scanner, is retired.
- Setup Audit Trail shows the 20 most recent changes in Setup. The download goes back 180 days, after which the records are deleted.
No tool replaces reading the org. Each one tells you where to look.
1. Automation
The question is what runs when a record is saved, and in what order.
| Check | How | What a bad result looks like |
|---|---|---|
| List every Workflow Rule, process, flow and Apex trigger on Account, Opportunity, Case and any billing object | Setup: Workflow Rules, Process Builder, Flows and Apex Triggers | More than one automation writes the same field |
| See the order of record-triggered flows | Flow Trigger Explorer (Setup, Flows, or Object Manager, Flow Triggers). It covers record-triggered flows only | Several flows on one object with no deliberate order. The order inside the asynchronous group is not guaranteed |
| Flag unsupported automation | Filter your list for Workflow Rules and Process Builder. Both lost support on 31 December 2025, still run, and have no bug fixes | Business-critical logic living in either |
| Scan code and flows | Code Analyzer version 5, or Org Check | Warnings in Apex or flows that nobody has reviewed or assigned |
Mark each field with two or more writers. Those are your highest-risk items.
2. Data
The question is whether people can trust what is in the org.
| Check | How | What a bad result looks like |
|---|---|---|
| Count custom fields per object, then ask who can explain each | Object Manager, then Fields and Relationships. Salesforce publishes a custom field limit for each edition, so look up yours | Fields with no owner, near-identical names, or no values |
| Check a field before calling it unused | Open the field and use Where is this used? It lists validation rules, layouts, formulas, Apex, flows, Lightning pages and reports | An empty list is not proof. Reports reached through relationships and joined reports are missed, references from installed managed packages are excluded, and results stop at 2,000 |
| Review duplicates | Check that duplicate rules exist. Report on Duplicate Record Items | Salesforce lists imports and API writes among the cases where the usual duplicate alert behaviour is overridden, and a separate article says active rules can still reject imported rows. Test your own load path, and audit loaded and integrated records separately |
| Find old reports | Create a custom report type with Reports and Dashboard Components, then sort on Last Run | Reports that have not run in a year, or in whatever period you choose. Dashboard refresh dates are not directly reportable |
| Review picklists | Compare values that mean the same thing | "Web", "Website" and "Web Form" all in use |
3. Integrations
The question is what writes into the org, and what happens when it fails.
| Check | How | What a bad result looks like |
|---|---|---|
| List connected apps | App Manager | Apps nobody owns |
| Plan for connected app changes | From Spring '26, Salesforce blocks the creation of new connected apps by default unless Salesforce Support enables it, and points to External Client Apps. Existing connected apps keep working and can still be edited. Salesforce has said an end-of-support date will be announced | Integrations that depend on creating new connected apps |
| List installed packages and API users | Installed Packages and Users in Setup | An integration signed in with a person's login |
| Look at API volume | System Overview, API Usage | No record of how a high-volume sync behaves over time |
| For quote-to-cash, compare one month | Closed deals in Salesforce against orders and invoices in the billing system | Differences nobody can explain. Our guide to the six Salesforce and NetSuite handovers covers one case in detail |
For each integration, record the owner, the objects it touches, the direction of the data, and what happens when it fails.
4. Access
The question is who can see and change what, and whether anyone has access they no longer need.
Salesforce planned to retire permissions on profiles and then cancelled the plan, citing customer feedback and remaining feature gaps. Its current advice is a permission-set-led model: profiles for baseline settings, permission sets and permission set groups for access.
| Check | How | What a bad result looks like |
|---|---|---|
| Find broad permissions | List who holds View All Data, Modify All Data and Export Reports, through profiles and permission sets | Broad rights held for convenience. Salesforce describes per-object View All and Modify All Records as better alternatives |
| Review profiles | Look for profiles cloned from System Administrator | A profile per team, each copied from another |
| Review the sharing model | Setup, Sharing Settings: organisation-wide defaults and sharing rules | Defaults set to open "to make things work", with no record of why |
| Find leavers | Users who have left, users who own records but do not log in, and integration users with personal logins | Frozen users, who still use a licence. Deactivating frees it |
Turning off Modify All Data does not remove the object permissions it switched on, so review the permission set as well. If you plan an AI agent, add the agent user to this review. Our guide on cleaning Salesforce before an AI agent covers it.
5. The admin backlog
We found no Salesforce method for this area, so this part is our own.
Export every open request into one sheet, from wherever your team keeps them: a ticket system, cases or email. Add columns for object, process, requester and age, and one more headed "symptom of which finding in areas 1 to 4?". A request to "fix the discount field" may be a duplicate automation. Count how many requests trace back to one cause. Note who decides priority, because a backlog without an owner only grows.
Turn findings into a plan
Give every finding three things: what is broken, what it costs to leave it, and what it takes to fix. Then place it on a simple scale. This scale is ours, not Salesforce's:
- High: it affects money, security or the forecast now.
- Medium: it makes every change slower or riskier.
- Low: clutter that can wait.
Here is one filled row, as an illustration and not a real client:
| Finding | Cost of leaving it | Fix | Severity |
|---|---|---|---|
| Two flows both write Opportunity Amount | The forecast and the billing system can disagree after a price change | Merge into one flow, test in a sandbox | High |
Put the findings in order, name an owner for each, and decide what to test in a sandbox before it reaches production.
Where we fit
If you would rather not run the audit yourself, the Org Review does that work for you and turns the findings into a costed list. If your own audit already gives you a clear order of work, you may not need it.
The Org Review is our fixed-fee review of your Salesforce setup, from USD 3,500. It gives you a costed list of what needs fixing, what it costs to leave it and what the fix takes. You keep the findings whether or not you hire us for the work.
If you would like to talk it through, book a free twenty-minute call.
Sources
Statements about Salesforce in this guide were checked against these pages on 28 October 2026.
Related guides
Start with the Org Review, not a contract
A fixed fee from USD 3,500, ending in a costed fix list you own outright. Book a free twenty-minute call about what your audit found.