The Org Audit gives you an instant briefing on a client's Salesforce environment — before you've had a single discovery call. In minutes you can form a confident picture of what you're walking into: how the org is structured, how healthy it is, how actively it's maintained, and where the risk lives.
This is most useful at the start of an engagement, but it's equally valuable mid-project when you need to quickly cross-check an area you haven't touched yet, or when preparing for a client conversation.
What a good first pass looks like
A complete first-pass audit covers eight dimensions. You don't have to go in order, but the following sequence tends to produce the clearest overall picture:
1. Users
Start here to calibrate the size and shape of the org. License distribution tells you how Salesforce is actually used — a heavily Sales Cloud shop looks very different from one running Service Cloud with Communities. Admin count relative to total users is one of the fastest indicators of governance maturity: too many admins suggests accumulated access that was never cleaned up.
What to look for:
License mix that doesn't match the client's stated use case
A disproportionate number of admins (more than 3–5 for most mid-size orgs is worth flagging)
Profile proliferation — many profiles with small user counts can signal ungoverned access growth
2. Security
Salesforce's Security Health Check scores the org against a set of recommended baselines. This is the fastest way to surface misconfiguration risk without needing to know the org first. High-risk items here are often the easiest wins in an audit presentation — they're named, measurable, and fixable.
What to look for:
Any high-risk findings, especially around session security, password policies, and network access
Items that interact with each other — for instance, relaxed session settings compounding a weak MFA posture
The overall ratio of compliant vs non-compliant settings as a headline health number
3. Permissions
The permission model is where security risk often hides in plain sight. View All Data and Modify All Data are the most powerful permissions in Salesforce — finding them attached to non-admin permission sets is almost always a finding worth raising. Beyond the high-risk items, the total permission set count and how they're organized signals whether the client has a thoughtful access model or accumulated one organically over years.
What to look for:
Permission sets with View All Data or Modify All Data (especially if many users hold them)
A very high total permission set count with no clear grouping strategy
No Permission Set Groups — this is the modern pattern; absence suggests the model hasn't been reviewed recently
4. Change History
This tab tells you how the org is actually managed day-to-day. Two questions matter most: does this org have a deployment pipeline, and are people actually using it? An org where the audit trail is dominated by direct admin changes in production — regardless of whether a DevOps tool was detected — is operating at significant delivery risk.
What to look for:
No deployment tooling detected (change sets or manual deployments only)
Deployment tooling present but most audit trail changes made by individual users bypassing it
Change activity concentrated in one or two people (bus factor risk)
Unusual activity spikes that might indicate incident response or emergency changes without process
5. Integrations
Integration footprint is often larger than clients realize. This tab gives you a complete picture of what external systems the org is connected to, which auth patterns are in use, and whether there are any stale or ungoverned connections. Integration users with broad profiles are a common security gap.
What to look for:
Remote Sites configured for endpoints that should be using Named Credentials (a security and governance gap)
OAuth tokens that look stale or abandoned
Integration service accounts with profiles that grant more access than the integration needs
Duplicate entries suggesting a copy-paste setup pattern rather than governed configuration
6. Code
Code complexity tells you a lot about delivery risk. An org with hundreds of Apex classes, no trigger handler framework, and a mix of Aura and Visualforce isn't just technically old — it's expensive to change safely. The code breakdown gives you the data to scope a modernization conversation or set appropriate change-risk expectations.
What to look for:
Visualforce and Aura components: these are migration candidates and signal legacy implementation patterns
Trigger handler framework adoption: absence suggests direct-in-trigger logic and a higher regression risk for any future automation work
High controller counts relative to class counts: a common legacy pattern from early Salesforce development
Batch, scheduled, and queueable patterns: gives you a quick read on async architecture complexity
7. Data Model
Custom object and record type density are proxies for business complexity. An org with many custom objects and high validation rule concentration on a few of them tells you exactly where the business logic lives — and where changes will be most risky. This is also a good early indicator of whether the data model has grown organically without governance.
What to look for:
Objects with unusually high record type counts (often a workaround for something else)
A small number of objects carrying the majority of validation rules — this is where your change impact analysis will matter most
A custom object count that seems disproportionate to what the client has described the org as doing
8. Installed Packages
Managed packages are a dependency footprint. Too many packages, especially in overlapping functional areas, is a governance and upgrade-complexity problem. Packages without namespace prefixes are less standardized and carry more unpredictability.
What to look for:
Multiple packages in the same functional area (e.g., two integration middleware tools, overlapping CPQ solutions)
Packages that don't align with the client's stated tech stack
A large number of packages with no clear owner or renewal cadence
AI Assessments
Each tab includes a Generate Assessment button. This sends the live org data to an AI model that produces a written analysis: overall posture, specific concerns, cross-cutting patterns, and prioritized recommendations.
The assessment is designed to go beyond what the raw data surfaces on its own. Rather than summarizing the numbers you can already see, it focuses on what the distributions reveal — governance gaps, compounding risks, architectural signals. The output is structured so it can go directly into a client report or be used as a starting point for a findings conversation.
Assessments are cached. If you navigate away and come back, the previous result is still there — you don't have to regenerate unless the underlying data has changed.
When to use it: After reviewing a tab yourself and wanting a second opinion, or when preparing material for a client-facing document and you want a written summary you can edit.
Export to LLM
The Export to LLM button copies the raw tab data along with a structured prompt to your clipboard. You can paste it into ChatGPT, Claude, or any AI tool you already use.
This is useful when you want to do something more specific than what the built-in assessment covers — slicing the data in a particular way, asking follow-up questions, or incorporating the org data into a larger analysis you're assembling in another tool.
Practical scenarios
New engagement kickoff. Connect the client org and walk through all eight tabs before your first call. You'll arrive with specific observations to validate rather than open-ended questions, which changes the dynamic of the discovery conversation.
Pre-assessment scoping. Use the Code, Data, and Change History tabs together to understand delivery risk before committing to a timeline. An org with legacy code, no deployment tooling, and high-complexity validation rules needs more buffer than one that looks clean.
Security audit. Security and Permissions together cover the two areas where Salesforce orgs most commonly carry risk: misconfiguration and over-permissioning. Generate assessments on both and use the output as the basis of a security findings report.
Handing off to a teammate. If you need to brief someone who hasn't been in the org, walk them through the Org Audit with Generate Assessment run on each tab. They'll have enough context to start productive work without needing an extensive handoff session.