Frequently asked questions

Salesforce admins, security and compliance teams, and anyone who has to answer “who can see this data, and why?” for an audit, a customer security review, or an incident. If you own a Salesforce org’s access model, it is for you.

Who Sees What is a read-only Salesforce access and permission auditor. It maps who can reach a record or a field across every access layer (profiles, permission sets, roles, public groups, sharing rules, and more) and shows not just who has access but why they have it. The result is a prioritized, audit-ready picture of your exposure.

You connect your org with standard Salesforce OAuth. The connection is read-only: Who Sees What reads your access-configuration metadata and user directory to build the audit. You can connect a production org or a sandbox, and you can disconnect at any time.

Connect your org and you will have an initial risk snapshot in under five minutes, no install required. Run a quick scan to begin.

Our assistant is named Horton, after Horton Hears a Who! by Dr. Seuss. In the story, Horton the elephant is the one who can hear the tiny Whos that nobody else can hear. That is a fitting name for Who Sees What: a tool whose job is to surface who can see what in your Salesforce org, including the access that nobody else notices. Horton is an AI assistant, not a person, and for anything important we will connect you with a member of our team.

Salesforce access is decided in layers, and Who Sees What evaluates them in the same order Salesforce enforces them:

1. Object access (CRUD). A user first needs Read on the object (granted through a profile or a permission set). Without object Read, nothing else matters, the user cannot see any record of that object.
2. Record access (sharing). For users who have object access, record visibility is then decided by sharing: who owns the record, the org-wide default (OWD), the role hierarchy, sharing rules, manual and team shares, and “View All” or “Modify All” permissions that override sharing.
3. Field-level security (FLS). Even when a user can see a record, field-level security can hide individual fields, so two people who both see a record may see different fields.

When Who Sees What answers a question, it tells you which of these layers is the deciding one, so you see not just whether someone has access but exactly why. It reads this configuration only; it never changes it.

A sharing rule grants access to records beyond what the org-wide defaults allow, usually by opening records owned by one group of users to another group. Sharing rules are one of the easiest ways for access to quietly widen over time, because they grant access in addition to everything else (profiles, permission sets, roles). That is exactly why Who Sees What traces them: when it shows who can see a record, a sharing rule is often the reason, and it is the layer admins most often forget to check.

A permission set is a bundle of permissions (object access, field access, system permissions, and more) that you assign to individual users on top of their profile. Permission sets are additive: they can grant access but never take it away. Because any number of them can stack on a user, they are a common source of access that is broader than anyone intended. Who Sees What attributes access back to the specific permission set that granted it, so you can see exactly why a user has the access they do.

Every user has exactly one profile, which sets their baseline access. Permission sets are then layered on top to grant additional access to specific users without changing everyone on the profile. Salesforce is moving toward keeping profiles minimal and granting most access through permission sets and permission set groups. Who Sees What reads both, so when it explains who can see something, it names whether the access came from the profile or from a specific permission set.

Org-wide defaults set the baseline level of access to each object’s records for users who do not own them: Private, Public Read Only, or Public Read/Write, among others. Everything else (role hierarchy, sharing rules, manual sharing, teams) only opens access up from that baseline. Getting OWD right is the foundation of a sound sharing model, so Who Sees What starts from your OWD and then shows every mechanism that widens access from there.

Field-level security controls which fields a user can see or edit, independent of their access to the record itself. A user can have access to a record but still be blocked from a sensitive field on it (such as a salary or a national ID), or the reverse. Because FLS is set per profile and per permission set, it is easy for a sensitive field to be exposed somewhere unexpected. Who Sees What maps field-level security so you can see who can reach regulated fields, and why.

The role hierarchy gives users access to records owned by people below them in the hierarchy, so managers can typically see their teams’ records. It is a powerful and often invisible source of access: someone high in the hierarchy may be able to see far more than their day-to-day job suggests. Who Sees What includes the role hierarchy when it traces who can reach a record, so inherited manager access is never a blind spot.

Who Sees What starts with a free trial, so you can connect an org and see the full product before you pay. After the trial, pricing is per production org, billed monthly:

• Who Sees What: $499 per org per month. Access visibility: the question library, the audit explorer, and on-demand scans.
• Who Sees What Enterprise: $1,299 per org per month. Everything above, plus continuous monitoring, multi-org comparison, SSO and team access, and API access.
• Lynceon: our standalone security product, $2,499 per org per month (introductory $2,074/mo on a one-year contract, $1,499/mo on a five-year contract). It adds risk findings, remediation guidance, and threat detection on top of Who Sees What.

There is introductory pricing right now: 33% off with a one-year contract and 50% off with a two or three-year contract. See the pricing page for the current numbers and to start a free trial.

We offer a full free trial first, so you can evaluate Who Sees What on your own org before you pay anything. After you sign up for a paid plan, we do not offer refunds. If you would rather not commit long-term, you can choose monthly service and pay month to month instead of committing to a longer term.

Yes. Who Sees What begins with a free trial of the full Who Sees What experience, so you can connect your org with read-only Salesforce OAuth and run real audits before you decide, with the complete risk findings included. You start the trial yourself from the app, no sales call required. When the trial ends you choose a plan: plans are tiered (see Pricing), so some detail like the full risk findings moves to a higher tier, but your work carries over.

Per org, not per user. You pay one flat monthly price for each connected production org, and you can invite the admins on your team without paying for more seats. Who Sees What is an admin tool used by a few people, so per-org pricing keeps it simple and predictable: you are paying for visibility into the org, not for the number of people who look at it.

On a month-to-month plan, you can choose to stop at any time. If you have already paid for the current month, that month is not refunded, but you keep access for the rest of that paid term. Multi-year contracts cannot be cancelled: they remain in effect for the full term you agreed to, even if you stop using the service. If staying flexible matters to you, the month-to-month plan is the better fit.

Who Sees What answers “who can see what, when I ask.” You connect one production org, use the full question library and audit explorer, and run scans on demand.

Who Sees What Enterprise turns that into an always-on, team-wide capability. It adds:

• continuous monitoring and scheduled scans, with alerts when access changes
• access-change tracking, so you can see who gained access to something since the last scan
• multiple connected orgs plus sandboxes, with comparison across them
• SSO, roles, and access for your whole team
• API access and scheduled exports for your other systems
• longer audit history and priority support

A simple rule: if you want to connect or compare more than one org (for example production versus a sandbox, or one client org versus another), that is Enterprise.

We accept invoice, purchase order (PO), and ACH. We also accept credit cards with no fee for monthly billing. If you would like to pay for an annual plan by credit card, a 3% convenience fee applies; you can avoid that fee by paying annually with ACH, invoice, or PO.

No. There is no setup or onboarding fee. You connect your org yourself with a read-only OAuth login, with no managed package to install, and you can start with a free trial.

Who Sees What shows you the facts of access: who can see what, and what changed. Lynceon is the security product that judges those facts and helps you fix them. On top of Who Sees What it adds:

• the full set of risk findings, in detail, with severity
• remediation guidance for each finding, so you know how to fix it
• a security posture score and trend over time
• risk prioritization, so you fix the most important things first
• compliance and framework mapping
• threat and anomaly detection for unusual access patterns

Lynceon is a separate product. If Who Sees What tells you who can see what, Lynceon tells you what is risky about it and how to remediate. Talk to us for Lynceon pricing.

We offer a 20% discount for charitable nonprofits. To qualify, you need to provide proof of charitable nonprofit status; being a nonprofit organization alone is not enough. We do not offer a discount for government or other public entities, so a public school, university, or government agency would not qualify, though a qualifying charitable nonprofit would.

Each production org you connect carries its own license. Connecting more than one org, and comparing access across them, is part of Who Sees What Enterprise.

Sandboxes are priced at 50% of the org’s rate, added on to a licensed production org. So if you license a production org on Enterprise, you can add its sandboxes at half price to compare access between them and catch changes before they reach production. Any non-production org (full, partial, or developer) counts as a sandbox at the same 50% rate.

For multi-year agreements, any price escalators are agreed up front and written into your contract when you sign, and they do not change during the contract term, so you know your pricing for the life of the agreement. On a month-to-month plan you are on the current standard rate with no long-term commitment. If locking in your pricing matters to you, a multi-year agreement with its agreed escalators is the way to do that.

For a limited time, a longer contract earns a larger introductory discount off the per-org rate:

• one-year contract: 33% off
• two or three-year contract: 50% off

Month-to-month is at the standard rate. The discount applies to both Who Sees What and Who Sees What Enterprise. See the pricing page for the current introductory rates.

Yes. Consultants and AppExchange partners can enroll as resellers and earn a partner discount, then resell Who Sees What to their clients or set up and pay for client orgs themselves.

On access and who pays: each org carries one license, and access is separate from who pays for it. You can give your consultant a login to your licensed org, and a consultant can set up and pay for an org while you still log in. Either way the org is licensed once and never charged twice. If you were given a referral or partner code, you can enter it when you start, and the discount applies to your plan.

No. Who Sees What is strictly read-only. It inspects how access is configured. It never changes your configuration, your data, or your records, and it never writes to your org.

Who Sees What reads your access-configuration metadata (profiles, permission sets, field-level security, org-wide defaults, sharing rules, roles, public groups, queues) and your user directory. It does not read the contents of your business or customer records.

It stores the access metadata needed to build and retain your audit reports, the encrypted credential needed to re-read your configuration, and account plus usage telemetry. It does not copy or store your business-record contents. For the full detail, see our Data scope and handling page.

Your Salesforce refresh token is encrypted at rest with AWS Key Management Service (KMS) and stored only in encrypted form. Audit data is retained while your account is active (the default audit-history retention is 12 months, configurable from 1 to 120 months). When you close your account, all stored data, including backups, is deleted within 90 days. See the Privacy Policy and Data scope and handling for more.

The access audit is computed by deterministic software, with no AI involved. Separately, Who Sees What offers an optional in-product assistant, Horton, that uses a third-party AI model (Amazon Bedrock) only to answer the product questions you type, drawing on our public product documentation. Your Salesforce data (your configuration, your user directory, and your records) is never sent to the AI model, and your data is never used to train any model. The questions you type to the assistant may be logged to improve the Service. See the Data scope and handling and Privacy Policy pages for detail.

We’re happy to be transparent about this.

Horton, the in-product assistant, is built on leading large language models (currently Anthropic’s Claude family). There isn’t one fixed model: the specific model varies by the type of request, because our products dynamically select the model best suited to each task (for example, a fast model for a simple classification, a more capable one for a detailed explanation). So “which model” depends on what you asked.

Just as important: Who Sees What does not use AI models to access or analyze your Salesforce data. Your access analysis, who can see which record or field, and why, is produced from your org’s configuration, not by an AI model. We use AI only to help you use the product: Horton answers questions about Who Sees What (like this one) and helps you navigate it. Horton does not read, analyze, or train on your customer data.

You can disconnect Who Sees What at any time, either from within the app or from Salesforce Setup (Connected Apps OAuth Usage), which immediately invalidates its access. Our Revoke access page walks through both paths step by step.

Salesforce Setup shows you access one piece at a time: a profile here, a sharing rule there, a permission set somewhere else. It does not answer the real question, which is “who can see this specific record or field, and through which path?” Who Sees What consolidates every access layer (profiles, permission sets, roles, groups, sharing rules, field-level security) into one answer and shows the reason for each grant. It turns a manual, multi-screen investigation into a single, audit-ready report.

An audit gives you a prioritized view of exposure: overexposed profiles and permission sets, who can reach sensitive fields and objects, dormant access that outlived its purpose, and for any record or field the list of users who can see it with the reason each one can. Findings come with severity and the affected users, plus remediation guidance your admin team can act on. The result is concise and audit-ready, built to hand to security, compliance, or an auditor.

Yes. You can connect either a production org or a sandbox with read-only Salesforce OAuth, so you can try Who Sees What safely against a sandbox first and run it against production when you are ready. Either way the connection is read-only: it reads access-configuration metadata to build the audit and never changes your org.

Ask the “Who can see this record?” question and give it the record. You can paste the record’s 15- or 18-character Salesforce Id, or pick a recent record, and Who Sees What returns every user who can see that record along with the reason each one has access (the deciding grant, such as record owner, role hierarchy, an org-wide default, a sharing rule, a public-group or queue share, or a “View All” permission). You can also ask “Who can edit this record?” to narrow the list to people with edit access.

“Who can see this record?” is a free question on the trial. It answers at the record level: it tells you who can see the record and why, without changing anything in your org.

Every answer leads with a plain verdict, then shows the “why” behind it.

• For “who can see” questions: you get the list of people who have access. Each person shows their access level (for example, Read or Edit) and the deciding reason they have it, with the full grant path when there is more than one step (for example, “Role hierarchy, because they are above the owner”).
• For “why can (or can’t) someone see this” questions: you get a yes or no verdict plus the single binding reason. When access is blocked, the binding reason is the one layer that stops it: no Read on the object, no record-level sharing, or field-level security hiding the field. When access is granted, the binding reason is the grant that provides it, followed by any other paths.
• Supporting evidence names the metadata behind the answer, such as the record owner, the org-wide default, and any groups, queues, or roles involved.

The verdict is the ground truth (it reflects what Salesforce actually enforces); the binding reason and full path explain it. Who Sees What never changes your org to produce these answers.