Skip to content
Who Sees What

Salesforce permission and visibility audit

Who sees what in your Salesforce org?

Expose risky access before auditors, customers, or incident response force the question. Who Sees What reads your Salesforce sharing and security settings and answers who can see what, through which grant, for any record, field, or person.

Scan a production org Scan a sandbox or ask us for a walkthrough ›

Safe by design.

Who Sees What auditing a Case record in a demo org: the People view reports that 6 active users can see this record, 3 of them with View or Modify All Data, and lists each internal user with their profile, license, access level, last login and the exact permission or sharing path behind their access, each with a Verify button.
One record, every person who can see it, and the grant behind each. Captured from a demo org.

Ask Horton

Ask it the way you would ask your admin.

Horton answers questions about Who Sees What from the panel beside this page (on a phone, at the top of it), and inside the app he runs the audit for you: he reads your org's own schema to work out which object you meant, finds records by name instead of making you paste an Id, and shows the reason behind every result.

  • Who can see this Case, and why?
  • Which fields on Contact can a Standard User read?
  • Who holds View All Data without logging in?

Why Who Sees What exists

It's hard to easily determine record and security access on a single screen in Salesforce

Salesforce decides who can see a record through seven layers that were designed one at a time and never meant to be read together: org-wide defaults, the role hierarchy, sharing rules, groups and queues, profiles, permission sets, and field-level security. No admin can hold all of it in their head, so access drifts, auditors get estimates, and the question "who can see this?" goes unanswered.

Who Sees What reads those layers as one model and answers from it: the people, the fields, and the exact grant behind each. The same definition of a user's effective access, which we call a visibility class, is becoming the shared language of the Digadop security family, so what one product learns about your org the others can use. The job is making Salesforce legible.

What gets flagged

Permission risk, translated into decisions.

Salesforce access is spread across profiles, permission sets, groups, roles, sharing rules, queues, teams, and managed-package defaults. The audit connects those layers so teams can answer who can see what, why, and what to fix first.

  • Overexposed profiles

    Find profiles and permission sets granting broad object, field, or system access beyond the role that needs it.

  • Sensitive data paths

    Map who can reach regulated fields, revenue data, customer records, and internal-only objects across every access layer, including field-level security read on its own and relationship-derived record sharing.

  • Dormant access

    Surface users, groups, and assignments that still carry meaningful access after the business process moved on.

  • Audit-ready evidence

    Produce a concise report with findings, severity, affected users, and the exact grant behind each one, so your admin team knows what to fix.

What nothing else answers

The questions your other tools leave open.

Salesforce Setup, Health Check, and the posture platforms tell you how the org is configured. None of them answer who can actually reach this data, or get it out. These views do, and they are the reason teams keep Who Sees What after the first audit.

  • Who can export your data?

    The bulk-egress report: every user who holds Export Reports, View All Data, API Enabled, or the other permissions that let data leave the org, and the exact profile or permission set granting it.

  • Which risks come from code, not settings?

    Risks are traced through what actually touches the object: Apex, Flows, Visualforce, and cross-object formulas that republish a value past its own field-level security. You see the dependency, not just the symptom.

  • Which exposed fields matter most?

    Fields are ranked by how sensitive they are, so a widely-readable national ID rises above a widely-readable industry code. You triage the exposure that matters instead of a flat alphabetical list.

  • Which apps are connected, and still in use?

    Every connected app and live OAuth authorization in the org, with the scopes it holds and whether it is still in use. Integrations bypass the sharing model, and most orgs have never inventoried them.

  • Who holds dangerous permissions they no longer need?

    Org-wide findings for the dangerous permissions concentrated in too many hands, and for privileged access that outlived the person or process it was granted for.

An org-wide Risk findings scan: 4 critical and 2 medium findings. Rows show a dormant privileged Integration User holding View All Data and View Setup and Configuration, a dormant System Administrator holding 10 dangerous permissions, and a permission set granting View All Data that reaches no active user, each with the permissions as chips and a plain-language explanation.
An org-wide risk scan on the demo org: dormant privileged users and a broad permission grant, ranked by severity, each with the permissions behind it and a plain-language explanation. Exportable as CSV.

See it in action

The people, the fields, and the reason.

Ask Horton in plain English or build the audit by hand. Every row carries its reason in the Why column (View All Data, a sharing rule, the role hierarchy above the owner), and every table leaves with you as CSV, as an Excel workbook, or as a print-ready PDF.

The Fields view for the same Case record: 40 fields, 9 active object-readers, no field-exposure flags. Each row shows the field, its type, its exposure (No FLS, all readers) and how many of the 9 readers can see it, with Copy summary, CSV, Excel and Print or PDF export buttons.
The Fields view of the same Case record: 40 fields, 9 active readers, and for each field its type, its exposure and how many of those readers can see it.

Every field on the record, ranked by exposure.

Open a record and see all of its fields at once: the type, how it is exposed, how many sources grant it, and how many of the record's readers can see it. A formula leak, where a visible formula field exposes a value past the field's own field-level security, is flagged in the same table.

Copy summary, CSV, Excel, and Print or PDF sit on every result.

The custom field Potential Liability expanded inside the Fields view: 8 of 9 readers can see it through 47 field-level security sources, and a table lists each user, how they see it (direct FLS) and that it is surfaced on a page layout.
The custom field Potential Liability expanded: 8 of 9 readers see it, and the table names each one, how they see it, and whether it sits on a page layout.

Click a field, get the people and the path.

A custom field such as Potential Liability expands into the users who can see it, how each one sees it, and whether it is surfaced on a page layout. That is the question an auditor asks, answered without a query language.

Verify opens the record as that user, so you can confirm exactly what they see.

The audit builder: Audit access to an Object, a Record, a Field, Metadata, Sensitive data or Dependencies, with a record picked and an Audit button.
The audit builder: pick an object, a record, a field, metadata, sensitive data or dependencies, name it, and audit it.

Or build the audit yourself.

Pick an object, a record, a field, metadata, sensitive data, or dependencies, name the thing, and audit it. The result is the same People, Fields, and Risks views.

Security

Built to be trusted with your access model.

These are the controls that keep the audit itself safe. The full specifics are on our trust pages.

Details: Data scope, Privacy, Revoke access, Terms.

Least privilege by design
Who Sees What requests only what its audit needs, through standard Salesforce OAuth. No password is shared.
Isolated, encrypted, deterministic
Tenants are isolated with org-scoped access and row-level security, stored credentials are encrypted with AWS KMS, and the audit is computed by deterministic analysis you can re-run. Your data is never used to train models that benefit other customers.

See who can reach your most sensitive data.

Nothing to install. You authorize access and can revoke it anytime. Connect an org and have a first risk snapshot in under five minutes.

Start a quick scan