Salesforce audit checklist: what to check, and in what order

If nobody has checked your Salesforce org in a while, you're probably forecasting from a pipeline you can't fully trust. You may also be paying for licenses and storage nobody uses. This checklist shows you how to find out and what to fix first, based on how we run client audits. It's written for the Salesforce admin or RevOps lead who runs the audit, and for a CRO or CMO who inherited the org. If HubSpot is your main CRM, start with our HubSpot audit checklist, which also covers the sync settings you can only see from HubSpot.

The audit runs in three parts:

• Steps 1 to 3 happen before you open Salesforce: set the objective, map how the team is supposed to work, and get the right access and tools.
• Steps 4 to 12 are the Salesforce system checks: licenses, security, packages, objects, data quality, duplicates, automation and reporting.
• Steps 13 to 15 review the findings: check each pain point against the evidence, then work out the cause with the team and write it up.

By the end you'll have a readout of the org and a short list of critical findings, each with a question for the team. If you already know the one problem you need to fix, skip to the step that covers it.

Before you open Salesforce

Talk to the team before you open Setup. If you go into Salesforce without knowing what sales and marketing actually do, you'll misread what you find. Thousands of lead records can look like a data problem until someone tells you the team stopped using leads years ago.

1. Decide what the audit is for

When this step is done, you'll have a short written goal for the audit, plus a list of pain points with the name of the person who raised each one.

Without a clear question, the audit turns into a long list of counts with no order to them. The people who use Salesforce every day know where it gets in their way, so start with them.

• Write down the question the audit needs to answer, such as whether the pipeline can be trusted for forecasting, or why two reports on the same thing never agree.
• Talk to the people who use Salesforce every day: reps, sales managers, and whoever runs marketing or service in it. Ask where it slows them down and what they've stopped using.
• Write each pain point down in your own notes, with who raised it. Write those notes yourself rather than relying on AI notes, so you understand each pain point before you test it in step 13.
• Turn each complaint into something you can check in the org. If reps say the opportunity page has too many fields, plan to count which ones actually get filled in.

2. Map the processes Salesforce should mirror

When this step is done, you'll have a written map of how the team is supposed to work: the opportunity stages with their entry and exit criteria, the rules Salesforce actually enforces, and what your team means by a lead and a contact.

You can only judge how Salesforce is set up against how the team is supposed to work. The best case is an org that mirrors the agreed process, with validation rules and required fields that keep reps on it.

• List the opportunity stages and the entry and exit criteria the team agreed on. Our guide to Salesforce opportunity exit criteria covers how to write them if you don't have any.
• Note which rules Salesforce enforces (validation rules, required fields, record types) and which exist only on paper.
• Write down what counts as a lead and what counts as a contact in your business. In Salesforce these are two separate objects, and an unclear line between them shows up in reports, lead conversion and integrations. We recommend retiring the Lead object and tracking early interest as a pre-pipeline opportunity, which is the setup we've seen work best. Our guide to Salesforce leads vs contacts explains why.

3. Confirm your access and tools

When this step is done, you'll have System Administrator access for as long as the audit runs, and a way to run SOQL queries that you've tested on one simple query.

Access is the problem we hit most often when an audit starts. Without access to every record, your queries only count the records you're allowed to see, and nothing tells you the numbers came back short.

• Confirm you have System Administrator access. If that isn't possible, ask for a permission set with View Setup and Configuration and View All Data for the length of the audit. A few checks need extra permissions, and those steps say so.
• Open the Developer Console (click the gear icon at the top right, then Developer Console), go to the Query Editor tab at the bottom, paste a query such as SELECT COUNT(Id) FROM Account and click Execute. The count shows in the results below the editor. Data Loader can also run SOQL if you'd rather export results to a spreadsheet. We always recommend Salesforce Inspector Reloaded, a Chrome extension that runs queries and shows every field on a record. It's an open-source community tool that isn't made by Salesforce, so check your company's policy before installing anything that can read your org's data.
• A few queries in steps 6, 7 and 11 read setup data: installed packages, validation rules, flows by type and code coverage. In the Query Editor, tick Use Tooling API before you run those, and untick it again for the rest.
• Treat the audit as read only. Record what you find, and make changes only after you've walked the team through the findings and explained why each change is needed. In Salesforce a small change can set off flows, Apex code or integrations you haven't reviewed yet.
• If HubSpot is connected, book time with whoever owns the sync.

Salesforce system checks

Salesforce lets you customize almost anything, which is why so many orgs end up with objects, fields and automation nobody can explain. The upside for an auditor is that you can query most of it directly, so much of a Salesforce data check is a SOQL query (Salesforce's query language) that returns a count. Think of the counts as the tests a doctor runs before prescribing anything: they show what's there, and steps 13 to 15 are where you work out what it means. Write each count down as you go, because they become the readout in step 15.

4. Licenses, storage and limits

When this step is done, you'll have the org's edition, licenses in use against licenses paid for, the licenses still assigned to people who've left, and data and file storage against the limit.

Start with what you're paying for and how close the org is to its limits. All of these checks happen in Setup.

• Search Quick Find for Company Information. Note the edition, and how many user licenses are in use against how many you pay for.
• Find licenses still assigned to people who have left or no longer log in.
• Search Quick Find for Storage Usage. Record data storage and file storage used against the limit, and note which record types and which users take up the most.
• Search Quick Find for System Overview. Note API usage and any limit the org is close to, especially if several integrations are connected.

If you have time, review the largest files on the Storage Usage page.

5. Users, permissions and security

When this step is done, you'll have the System Administrators listed by name, each profile with its active user count, the Health Check score with the high-risk settings it flags, whether multi-factor authentication is in place, and who has changed the org's settings recently.

Governance problems usually start here. When too many people have admin rights, fields and automation get added with no documentation, and nobody knows who changed what.

• List your System Administrators by name with the query below. Admin rights should sit with the people who actually own the system.

• Run the next query to see how many active users each profile has. Profiles with no active users are candidates for cleanup.

• Run the next query to list permission sets with how many users each is assigned to, then compare with the full list under Permission Sets in Setup. Look for permission sets with no assignments, and ones nobody can explain.

• Run Health Check: search Quick Find for Health Check. It compares your security settings with the Salesforce Baseline Standard (or a custom baseline) and gives a summary score. Record the score and the high-risk settings it flags. Health Check needs the View Health Check, View Security Center or Manage Security Center permission.
• Confirm multi-factor authentication is in place. Salesforce requires MFA for all logins to its user interface, including logins from automation users. Integration logins through the API aren't covered by the requirement.
• Review org-wide defaults in Sharing Settings. Each object is set to a level such as Private, Public Read Only, Public Read/Write or Controlled by Parent. Note any object that's more open than the business expects.
• Check which profiles restrict login hours or login IP ranges. Both are set on the profile, and login IP ranges are separate from the org-wide trusted IP ranges. Flag profiles with no restrictions where the business expects them.
• Search Quick Find for View Setup Audit Trail to see who changed which setting and when. Salesforce keeps at least the last 180 days of Setup changes, so in an inherited org it's the quickest way to see who has been changing the configuration. This query lists the latest 50 changes with the name of the person who made each one.

If you have time, check the role hierarchy against the org chart, and run the query below to list the lead and case assignment rules and whether each is active.

6. Packages, integrations and sandboxes

When this step is done, you'll have every installed package grouped by what it does, every integration that writes to Salesforce with the user it connects as, and the sandboxes the team uses to test changes.

Packages and integrations are a common source of records and automation nobody can explain. Systems get connected, documentation lags behind, and new records arrive from sources the team can't name.

• Search Quick Find for Installed Packages, or run the query below with Use Tooling API ticked. List every package, group them by what they do, and flag anything nobody can explain or still uses.

• List the integrations that write to Salesforce, and which user each one connects as. A dedicated integration user is much easier to audit than a person's login, and our guide to using a dedicated Salesforce integration user explains why.
• If HubSpot is connected, review the sync from the HubSpot side too. Sync errors and API use show in HubSpot's Sync Health view, and step 9 of the HubSpot audit checklist covers it.
• Search Quick Find for Sandboxes. Note which sandboxes exist, their type (Developer, Developer Pro, Partial Copy or Full), and how many sandbox licenses are available and in use.
• Ask whether changes are built and tested in a sandbox before they reach production. If no sandbox is in use, changes are probably being built directly in production.

If you have time, note which custom objects and fields each package added. Step 7 shows how to spot them.

7. Objects and fields

When this step is done, you'll have the custom objects your team built with what each one is for and whether it's documented, plus field, record type and validation rule counts for each key object.

Start in Object Manager, where each object's fields, page layouts and record types live. Expect a long list. Most objects are standard, and many custom ones come from installed packages.

Here's how to tell them apart. Custom objects end in __c. Objects added by a managed package also carry the package's namespace prefix, so name__c becomes prefix__name__c. A custom object with no prefix was built by someone in your org, and those are the ones that need documentation.

• List the custom objects your team built. For each one, note what it's for, whether it's documented, and whether a standard object could do the same job. Complexity is easy to create and expensive to maintain, so custom objects should exist only when they're really needed.
• Open the record pages for your key objects (account, contact, opportunity, lead and case) and look at them the way a rep does. The record pages matter more than anything else in Object Manager, because they're what the team sees every day. Cluttered layouts and fields nobody fills in are a sign the object has grown without a plan.
• Count fields, custom fields, record types and validation rules on each key object. The queries below do it for Opportunity: the first box lists every field, then only custom fields, then counts record types, and the second box counts validation rules. Swap in Account, Contact, Lead or Case to check the other objects. The two field queries list the fields instead of counting them, because that object doesn't accept COUNT(), so read the total rows shown above the results.

• Before anyone proposes deleting a field, use its Where is this used? button to see what depends on it.
• Walk through the opportunity stages and compare them with the stage criteria from step 2.

If you have time, run the same counts on contracts, products and opportunity products, if the team uses them.

8. Data quality by query

When this step is done, you'll have a count written next to every query below. Together they're the data quality readout.

This is the part of a Salesforce audit that goes faster than in HubSpot, because you run a query and read the count instead of building filters by hand. For each query, click Copy, paste it into the Query Editor (or the tool you picked in step 3), click Execute, and write the number it returns next to that query in your notes. The paragraph under each group explains what a high count usually means.

A few of the queries find records with no related records, such as accounts with no contacts. They use a NOT IN subquery, which Salesforce supports as long as the subquery selects an ID or lookup field. A single WHERE clause can hold no more than two IN or NOT IN conditions.

Contacts

Total contacts, then contacts missing an email, missing a first name, owned by inactive users, and with a bounced email.

Contacts with no email can't be emailed and are harder to match against other systems. Contacts owned by inactive users drop out of owner-based reports and assignment, even if a colleague is still working them. Bounced contacts are worth separating before any outreach.

Accounts

Total accounts, then accounts with no contacts, with no opportunities, missing an industry, missing a website, and owned by inactive users.

A few accounts with no contacts or opportunities is normal. If it's most of the database, you may be storing accounts you don't need. Missing industry makes it hard to analyze who your customers are.

Opportunities

Total opportunities, then opportunities missing an amount, a type or a lead source, with no contact roles, open with no next step, open with a past close date, open and untouched for 60 days, and open with an inactive owner.

These are often the most important counts in the audit, because they tell you whether the pipeline can be trusted for forecasting. Opportunities with no contact roles have nobody recorded in a buying role, so reports can't show who the buyer was. Open opportunities with a close date in the past haven't had that date updated, so ask the owners whether they're still live. The right window for untouched opportunities depends on your sales cycle, but an opportunity nobody has edited in 60 days usually shouldn't still be open.

Leads

Total leads, then leads missing an email, a first name or a lead source, and leads owned by inactive users.

Leads with no source drop out of source attribution reports.

Campaigns and cases

Campaigns missing a start or end date, with no members, still active after their end date, and owned by inactive users, then cases with no subject, owned by inactive users, and open for more than 60 days.

Campaigns still marked active after their end date, or with no members, suggest nobody is maintaining the campaign object. Open cases older than 60 days are worth a question to whoever runs service.

9. Duplicates

When this step is done, you'll have the active duplicate and matching rules with what each one blocks or allows, plus duplicate counts on the fields that matter to you and a few example records saved as evidence.

Duplicates split one person or company across several records and throw off the counts you just took. Check both the rules that should prevent them and how many already exist.

• Review duplicate rules and matching rules. Salesforce ships standard duplicate rules for accounts, person accounts, contacts and leads, each paired with a standard matching rule, and the standard account rule is active by default. Note which rules are active, what they block or allow, and whether anyone can explain why. In our audits, duplicate and matching rules nobody documented are behind a lot of the data quality problems we find.
• Count duplicates on the fields that matter to you. Each of these queries lists a value that appears on more than one record, with how many records share it: contact emails, lead emails, account names and account websites. Swap in phone, or first and last name, for a second pass.

• Save a few example records as evidence, and hold off on merging until the findings are reviewed.

GROUP BY queries can't page through results with queryMore, and formula fields can't be grouped at all. If a duplicate query comes back with 2,000 rows, it has hit the limit for one query, and that alone tells you the duplicate problem is serious. Narrow the query, for example to one record type, to see the rest.

If you have time and the org is on Performance or Unlimited Edition, run a duplicate job, which scans existing records against a matching rule. It needs the Customize Application and View All Data permissions. When you're ready to fix what you found, our CRM deduplication playbook covers the cleanup.

10. Leads and contacts against your definitions

When this step is done, you'll have a short list of the places where the team's actual use of leads and contacts differs from the definitions you agreed in step 2.

Salesforce keeps leads and contacts as separate objects. When the team doesn't have a clear definition of each, you get the same person in both places, reports that count them differently, and conversion steps nobody follows.

• Compare how the team actually uses leads and contacts with the definitions from step 2. Look for the same person sitting in both objects, and for leads that never get converted.
• If HubSpot is connected, check whether new HubSpot contacts arrive in Salesforce as leads or as contacts, and whether that matches your definitions. HubSpot has one contact record where Salesforce has two objects, so this is where many sync problems start.

11. Flows, legacy automation and Apex

When this step is done, you'll have counts of active flows by type, active Workflow Rules and Process Builder processes, and custom Apex classes and triggers, plus a list of automations that look duplicated, conflict with each other, or that nobody can explain.

Automation is where an org's history piles up. Every admin, consultant and package has added something, and much of it is still running.

• Count active flows and group them by type (run this with Use Tooling API ticked). Then list the flows that start from a record change, grouped by the object they run on (this one runs without Tooling API).

• Flag flows that look duplicated, conflict with each other, or that nobody can explain.
• Search Quick Find for Paused and Failed Flow Interviews, and note any failure that keeps repeating.
• Count active Workflow Rules and Process Builder processes (search Quick Find for each). Salesforce ended support and updates for both on December 31, 2025. Existing ones still run and can still be edited, but they won't get fixes. In most cases that makes them a migration item rather than an emergency.
• Count custom Apex classes and triggers (Apex is Salesforce's own code), and note which objects the triggers run on. The two queries below count them, and leaving out anything with a namespace prefix leaves out code that came with packages.

• Check overall code coverage (with Use Tooling API ticked). To deploy Apex, Salesforce requires unit tests to cover at least 75% of the code, and those tests must pass, so low coverage means the next deployment could fail. The query below returns the percentage for the whole org.

If you have time, map which flows, triggers and legacy rules act on the same object, because several automations on one object can cause updates nobody can explain. For legacy automation you plan to replace, Salesforce's Migrate to Flow tool can convert workflow rules and record-triggered processes that use supported features. Converting is a fix, so leave it until after the audit.

12. History tracking, activity capture and reporting

When this step is done, you'll have the fields with history tracking turned on, whether the org has Field Audit Trail, how captured emails and events are stored, and whether the main leadership reports still run on fields the team fills in.

These settings decide what history you'll have when you need it, and whether reports show everything.

• Check which fields have history tracking on, especially stage, amount and owner on opportunities. Standard field history tracking covers up to 20 fields per object, and keeps data for 18 months in the Salesforce UI and up to 24 months through the API.
• Check whether the org has Field Audit Trail: in Company Information, look for it under Permission Set Licenses or Feature Licenses. It tracks up to 200 fields per object and keeps data until you delete it, and it needs Salesforce Shield or Field Audit Trail licenses. If it isn't there, flag it when the business needs history beyond what standard tracking keeps.
• If the org uses Einstein Activity Capture, open its settings (search Quick Find for Einstein Activity Capture) and review the internal domain settings, the contact sync settings and any inactive configurations. Then check whether captured emails and events are saved as Salesforce activity records. Data kept only in Einstein Activity Capture's own storage is kept for 6 to 24 months, and after the initial setup and sync it can take up to 24 hours to show in standard reports.
• Search Quick Find for Sales Engagement Settings, and note whether Sales Engagement is turned on and whether the team still uses it.
• Search Quick Find for Reporting Snapshots. List the active ones, which save a report's results into a custom object on a schedule, and confirm someone still reads them.
• Check whether Einstein Lead Scoring is turned on. If it is, check the scoring still matches how sales qualifies leads. If it isn't, note it as a possible improvement, and check the license first, because it's a paid add-on in most editions.
• List the main reports and dashboards leadership uses, and check that they still run on fields the team fills in.

Reviewing the findings

The counts and settings show what's in the org. This part is where you find out why it got that way, with the people who use it.

13. Check every pain point against the evidence

When this step is done, you'll have a short note for each pain point from step 1 saying what you found, with evidence such as query results, screenshots or example records.

• Go back to your notes from step 1, and investigate each pain point directly in Salesforce: run the relevant queries, open the records and trace where the problem starts.
• Document what you found for each one, with evidence.

14. Work out the cause with the team

When this step is done, you'll have one question for the team about each critical finding, their answers, and the findings ranked by business impact.

It's hard to tell from the org alone whether a finding is a technical problem, a process problem or an adoption problem. Lots of unused custom objects or fields can point to a process gap, such as too many people being able to create them. A high count of open opportunities with past close dates is a question for the sales team before it's a cleanup task.

• Write a question for the team about each critical finding.
• Take the questions to the people who use Salesforce every day, and to anyone who knows the org's history, especially someone who's about to leave.
• Rank the findings by business impact, so a messy field nobody reports on sits below a pipeline nobody trusts, however easy it is to fix.

15. Write up the audit

When this step is done, you'll have the finished audit write-up, ready to walk the team through.

The write-up has three parts:

• A readout of the org: the counts and settings you recorded in each step.
• Critical findings, ranked: for example a high duplicate count, undocumented custom objects, or legacy automation still running on key objects.
• Questions for the team.

Check that it worked

Before you call the audit finished, check that:

• You understand every finding well enough to explain it to the team in your own words.
• Every key object, custom object and setting covered in the steps above has been reviewed.
• Every pain point from step 1 has a finding or an explanation.
• Every critical finding has a question for the team.
• No section is left blank or marked "to be done" without a reason.

Re-run the core queries quarterly, or whenever you take over the org or the team stops trusting the data, to see whether the org is getting cleaner. Between audits, a data quality dashboard built from reports, such as open opportunities with past close dates, keeps the numbers in view.

Frequently asked questions

Do I need a paid tool to audit Salesforce?

No. The Developer Console's Query Editor runs SOQL queries against your org, and Data Loader can export records with a SOQL query if you want to work through them in a spreadsheet. Browser extensions can make it faster, but none are required.

What happens to Workflow Rules and Process Builder now?

Salesforce ended support and updates for both on December 31, 2025. They keep running and you can still edit them, but they won't receive fixes, so plan to move them to Flow. Salesforce's Migrate to Flow tool handles workflow rules and record-triggered processes, as long as they use supported features.

How far back can I see who changed a field?

With standard field history tracking, 18 months in the Salesforce UI and up to 24 months through the API, for up to 20 tracked fields per object. Field Audit Trail extends that, but it's a paid add-on. Changes to settings, such as new fields or edited permissions, are logged separately in Setup Audit Trail, which keeps at least the last 180 days.

What to do next

Walk the team through the ranked findings and agree what to fix first, starting with whatever affects the pipeline and the forecast.

If you'd rather have someone else run the audit, RevBlack runs Salesforce and HubSpot audits for B2B teams.