Salesforce sharing and access, answered

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 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. Who Sees What reads your access-configuration metadata and user directory to build the audit. The one change it can make is optional and happens only if an admin chooses to run it: a one-time setup that creates a least-privilege auditor permission set and, if you ask, assigns it to your integration user. You can connect a production org or a sandbox, and you can disconnect at any time.

No. Who Sees What is built specifically for Salesforce. It connects only to Salesforce orgs (production or sandbox) and audits access within Salesforce. It does not connect to other CRMs, databases, or applications.

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

The name Horton comes from Horton, a friendly, big-eared elephant who is known for hearing the small, quiet voices that everyone else misses, and that is why the Who Sees What AI assistant is named Horton. It is a fitting image 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.

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.

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.

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.

Field exposure is judged on field-level security alone, which is the question admins actually mean when they ask “who can see this field”. You get the population whose FLS lets them read the field, separate from the record-level question of which rows they can reach. Keeping the two layers separate is what makes the answer usable: mixing them hides a field that is wide open at the FLS layer just because few people happen to own matching records today.

Fields also leak sideways through formulas. A formula field does not enforce the field-level security of the fields it references, so anyone who can read the formula can effectively read what it is built from. Who Sees What evaluates that, including cross-object formulas that surface a field from a related object, and reports a confirmed leak when at least one person who can see the formula cannot see the field behind it.

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 Professional: $499 per org per month. Access visibility: the question library, the audit explorer, full risk-finding detail, exports, audit history, and on-demand scans.
• Who Sees What Enterprise: $1,299 per org per month. Everything above, plus who-can-edit audits, loading inactive users on demand, itemized external and Experience Cloud user detail, permission-change simulation, access-change tracking over time, org-wide access drift, scheduled report exports with email and signed-webhook delivery, and API report export (CSV, XLSX, PDF, JSON) via REST and MCP. Cross-org compare is coming soon to Enterprise and is not included yet. Extended audit history and retention, and priority support, onboarding, and an SLA, are coming soon to Enterprise too.
• Lynceon (coming soon): the next product in the Digadop security family. Where Who Sees What shows you the facts of access, Lynceon (coming soon) is designed to judge them and help you act, adding risk remediation, continuous monitoring, and code-security scanning. It is coming soon and not yet available for purchase; the planned price is $2,499 per org per month. Choose “Learn more” to follow it.

There is introductory pricing right now: 17% off with a one-year contract, 25% off with a two-year contract, and 33% off with a three-year contract, locked flat for the whole term and billed annually. For Who Sees What Professional that is $414.17 per month on a one-year term, $374.25 on a two-year term, and $334.33 on a three-year term; Who Sees What Enterprise is $1,078.17 on a one-year term, $974.25 on a two-year term, and $870.33 on a three-year term. See the pricing page for the current numbers and to start a free trial.

We offer a 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, so you can connect your org with Salesforce OAuth and run real audits before you decide. You start the trial yourself from the app: no sales call and nobody to email first.

There are two ways to trial. Without a credit card you get about 3 days to explore, and export stays locked on that path. Add a card and the trial runs about 10 days with export unlocked (CSV, multi-sheet Excel, and print-ready PDF), and it converts to a paid plan automatically when the trial ends unless you cancel first. Either way it is one trial per org.

When you are ready to buy, checkout is self-serve as well. You pick the edition and term and complete the purchase in the app.

When the trial ends you choose a plan: plans are tiered (see Pricing), so some detail like the full risk findings and export moves to a paid 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. Committed terms cannot be cancelled: both a one-year and a multi-year contract remain in effect for the full term you agreed to, and prepaid fees are non-refundable, even if you stop using the service. If staying flexible matters to you, the month-to-month plan is the better fit.

There is no minimum term required. Who Sees What is available month-to-month at the standard per-org rate, so you are not locked into a long contract. If you want a lower rate, you can optionally commit to a one-year term (17% off), a two-year term (25% off), or a three-year term (33% off), but that longer commitment is your choice, not a requirement.

Who Sees What Professional answers “who can see what, when I ask.” You use the audit explorer, the core question library, full risk-finding detail, exports, audit history, and on-demand scans.

Who Sees What Enterprise adds the parts that go beyond seeing access:

• who-can-edit audits for records, objects, and fields
• loading inactive (deactivated) users on demand, beyond the active-user audit
• itemized external, Experience Cloud, community, and guest-user detail
• permission-change simulation: what access would change if you changed a role, group, or sharing rule
• access-change tracking over time: what changed in a user’s access to a record since a date
• org-wide access drift: what changed in your org’s access model since a date, from snapshots a scheduled access change check takes; the check delivers its change report by email or to a signed webhook, by default only when access changed (a scheduled check, not continuous monitoring with alerting, which is Lynceon, coming soon)
• scheduled report exports: a question’s report on the schedule you set, delivered by email or to a signed webhook
• API report export (CSV, XLSX, PDF, JSON) via REST and MCP, with API credentials you create and revoke in the app

Connecting more than one org is not the dividing line. The multi-org roster and one-click switching are available on every plan, including the free trial. Cross-org compare is coming soon to Enterprise and is not included yet. Extended audit history and retention, and priority support, onboarding, and an SLA, are coming soon to Enterprise too.

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.

Three things are coming soon to Who Sees What Enterprise and are not included in any plan today. Cross-org compare, which compares two connected orgs’ access models in a single view, is coming soon. Extended audit history and retention are coming soon. Priority support, onboarding, and an SLA are coming soon. Integrations that feed a SIEM, data warehouse, or ticketing system also stay coming soon as built-in connectors; today you point a scheduled export’s signed webhook at an endpoint on your side.

Lynceon (coming soon) is a separate product, the next one in the Digadop security family, not part of Who Sees What Enterprise, and it is not yet available for purchase. Continuous monitoring with alerting is a Lynceon capability.

What Who Sees What Enterprise includes today: who-can-edit audits, permission-change simulation, access-change tracking over time, org-wide access drift from scheduled access snapshots, loading inactive users on demand, itemized external and Experience Cloud user detail, scheduled report exports with email and signed-webhook delivery, and API report export (CSV, XLSX, PDF, JSON) via REST and MCP.

Who Sees What is priced per production org and is billed monthly at the standard rate, with no commitment required. You can also commit for a longer term to lock in a lower flat rate for the whole term: a one-year commitment is 17% off, a two-year commitment is 25% off, and a three-year commitment is 33% off (introductory pricing). Committed terms bill annually. So you can stay month-to-month, or choose an annual or multi-year term for the discount. See Pricing for current rates.

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

Lynceon is the next product in the Digadop security family, and it is coming soon. Where Who Sees What shows you the facts of access (who can see what and why), Lynceon (coming soon) is designed to judge those facts and help you act on them. The direction we are building toward includes:

• remediation guidance for each finding, so you know how to fix it
• continuous monitoring and scheduled scans
• code-security scanning across Apex and dependencies
• a security posture score and trend over time
• risk prioritization, so you fix the most important things first
• compliance mapping for your access posture
• threat and anomaly detection for unusual access patterns

Lynceon (coming soon) is a separate product. It is not yet available for purchase, and its capabilities are not sold today. Choose “Learn more” to follow it.

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. The multi-org roster and one-click switching are available on every plan, including the free trial, so connecting more than one org is not what makes Enterprise different.

Sandboxes attach to a licensed production org, and any non-production org (full, partial, or developer) counts as a sandbox. On Enterprise, the sandbox of your primary subscribed org is free, and a sandbox of any other org is billed at 50% of that org’s rate. On Professional, every sandbox is billed at 50% of the org’s 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: 17% off
• two-year contract: 25% off
• three-year contract: 33% off

The rate is locked flat for the whole term, and committed terms bill annually. In dollars, Who Sees What Professional is $414.17 per month on a one-year term, $374.25 on a two-year term, and $334.33 on a three-year term; Who Sees What Enterprise is $1,078.17 on a one-year term, $974.25 on a two-year term, and $870.33 on a three-year term.

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

Not yet. Our partner and reseller program isn’t open for sign-up. If you’re a consultant or AppExchange partner and want to work with us, tell us through the contact page.

A consultant can already help with your org today. 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, or 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.

Our pricing is set to be fair, and based on our own market analysis it is one of the highest values available for what it does. The return on investment is naturally variable: the value to a given organization depends on factors like your security maturity, the number of employees, contractors, and third parties with access to your systems, how many integrations you run, your DevOps process, how sensitive your data is, and the impact a failed security audit or a breach would have on you.

For an organization with real exposure, getting a clear, audit-ready answer to who can see what across every layer can pay for itself the first time it catches something. Pricing is per production org, not per seat, so your whole team is covered, and every plan starts with a free trial, so you can see the value on your own org before you pay.

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. Each finding comes with its severity, the affected users, and the reason for each grant, so your admin team knows exactly what is exposed and how.

Alongside the core audit you also get the exposure views most orgs have never run:

• Who can export, the bulk data-egress report: every user holding Export Reports, View All Data, API Enabled, or another permission that lets data leave the org, and the profile or permission set granting it.
• Connected app and OAuth inventory: every connected app with live OAuth authorizations in the org, who authorized it, how often and how recently it was used, and a flag on the ones that are dormant or were never used. It does not list the individual OAuth scopes each app holds.
• Sensitivity-ranked field exposure, so a widely-readable national ID sorts above a widely-readable industry code.
• Over-permissioned and dormant-access findings across the whole org, not just the object you happened to audit.
• A dependency map of the Apex, Flows, Visualforce, and formulas that touch an object, including cross-object formula exposure reported as a confirmed leak when a user who can see the formula cannot see the field behind it.

The result is concise and audit-ready, built to hand to security, compliance, or an auditor. Export it as CSV, as a multi-sheet Excel workbook (the first sheet carries the audit provenance), or as a print-ready PDF.

Yes. You can connect either a production org or a sandbox, so you can try Who Sees What against a sandbox first and run it against production when you are ready.

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, pick a recent record, or search for one by name, and Who Sees What returns every user who can see that record along with the reason each one has access. You can also ask “Who can edit this record?” to narrow the list to people with edit access.

The reasons cover the deciding grant: record owner, role hierarchy, an org-wide default, a sharing rule, a public-group or queue share, a “View All” permission, and relationship-derived sharing where access comes from a related record rather than this one (implicit parent sharing, implicit child sharing on a parent account, and person-account sharing). A small number of paths, such as some territory and team shares, are reported as granted by a mechanism that could not be itemized. We say so on the finding rather than guessing.

One thing worth being precise about: the list of who has access is authoritative, because it is checked against what Salesforce itself enforces. The why is our best explanation of that answer.

“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.

Horton is an AI assistant, not a person, and it is the way to get an answer without learning the product first. Ask in plain English, for example who can see this account or who can export contact data, and Horton runs the audit and shows the result with the reasoning behind it.

Three things make that work in a real org:

• It knows your schema. Horton reads your org’s own object metadata to work out which object you meant, so a custom object with an internal nickname resolves correctly instead of being guessed at from a generic list.
• It finds records for you. You do not need a Salesforce Id in your clipboard. Search by name and Horton matches against the records you are asking about, ranking the likely ones first rather than filtering out anything it is unsure of.
• It hands you to a person cleanly. Ask to talk to a human and the whole conversation travels with the request, along with a note on what you need, so the person who picks it up already has the context. You never have to retype your problem into an empty form.

The access analysis itself is computed by deterministic software from your org’s configuration. See what AI model Horton uses for the detail on that split.

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.

It depends on the size of your Salesforce org. A simple scan can take a few seconds. For a large org, generating the full report may take as long as a few minutes.

There are no fixed org size limits. Who Sees What works with Salesforce orgs of any size. Larger orgs simply take longer to scan: a simple scan takes a few seconds, and for a large org, generating the full report may take as long as a few minutes.

Yes. A Person Account is a Salesforce record type that combines an Account and a Contact into a single record, and Who Sees What audits who can see Person Account records the same way it does for other objects. You see who has access to them and why.

Yes, on Who Sees What Enterprise. Enterprise orgs create and revoke their own API credentials in the web app (organization menu, then API access) and call the REST API with the credential as a Bearer token, so a pipeline can run audits against your org and export reports as CSV, XLSX, PDF, or JSON. Professional does not include API access. See Pricing for the plans.

Yes, on Who Sees What Enterprise. Who Sees What has a hosted MCP server at https://whoseeswhat.com/mcp: create a credential in the web app (organization menu, then API access), point your MCP client at that address, and your AI agent can run audits, search for users, objects and records, compare orgs, and export reports. Professional does not include MCP access. See the MCP server reference for the tools, and Pricing for the plans.

Today Who Sees What runs in your web browser, so you can use it on any device that has a browser. There is no dedicated Who Sees What mobile app: no iOS app, no Android app, and nothing to download. A cross-product mobile effort is on our roadmap and it names Who Sees What screens, but it is at intake and specification, so treat it as a direction rather than a date. Phones and tablets work through the browser today, with one caveat worth saying out loud: only the People table reflows, so the field detail, audit history and gallery preview tables are still desktop-width.

Who Sees What connects through the standard Salesforce API, so it works with any edition that has API access enabled. That includes Enterprise, Unlimited, and Performance editions, as well as Developer edition. Professional edition works if your org has the API access add-on enabled.

The connecting user needs the API Enabled permission (along with View Setup and Configuration, View All Data, and Manage Users for a full org-wide audit). If you are unsure whether your edition has API access, your Salesforce administrator can confirm it.

Yes. Who Sees What audits access for both standard objects (such as Accounts, Contacts, Opportunities, and Cases) and custom objects, along with their custom fields. For any object, standard or custom, it evaluates the full access configuration that decides who can see a record: org-wide defaults, the role hierarchy, sharing rules, profiles, permission sets, and field-level security.

So you can ask who can see a given custom-object record and why, exactly as you would for a standard object.

Yes, with Who Sees What Enterprise. Experience Cloud, community, and guest-user coverage is part of the Enterprise plan, so you can audit access for external-facing users alongside your internal ones, including how the Experience Cloud sharing model (such as sharing sets) grants access.

On the Professional plan this external exposure is detected and flagged, and the full details are available when you move up to Enterprise.

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 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. For the full detail, see our Data scope and handling page.

Who Sees What runs entirely on Amazon Web Services (AWS) in the United States, inside Digadop’s own AWS environment.

The one credential kept (the encrypted Salesforce refresh token behind the optional keep-me-signed-in feature) is encrypted at rest with AWS Key Management Service (KMS) and never stored in plaintext. Connections use TLS, and every saved audit is isolated per Salesforce org with PostgreSQL row-level security, so one customer’s data is never readable in another customer’s session.

Yes. Every record Who Sees What stores is keyed to your Salesforce organization id and isolated using PostgreSQL row-level security. That isolation is enforced at the database, because the application connects with a non-privileged database role, so one customer’s data can never be read by another customer’s session.

On top of that, what is stored (such as your encrypted Salesforce refresh token if you choose to stay signed in, and the fingerprints of risks you have ignored) is encrypted and scoped to your organization.

No. Digadop does not sell your data, and does not share it for cross-context behavioral advertising. Who Sees What uses no analytics, advertising, or session-replay vendors.

We rely on a small, disclosed set of trusted sub-processors strictly to run the service: Amazon Web Services for hosting; GitHub only for the feedback you choose to submit through the in-product assistant (used for support triage); and Amazon Bedrock for Horton, the assistant, which only ever sees your typed question and public product documentation, never your Salesforce data. Each sub-processor is bound by our Data Processing Addendum, and we give at least 30 days notice before adding or replacing one. The current list is at /legal/sub-processors.

Your Salesforce refresh token is encrypted at rest with AWS Key Management Service (KMS) and stored only in encrypted form; it is deleted when you sign out and on detected revocation of the connection. Audit-history snapshots, preferences, and account and telemetry data are retained while your account is active, for as long as needed to provide the Service, and you can ask us to delete them sooner at any time by emailing privacy@digadop.com. When you close your account, we delete your stored data, including backups, within a commercially reasonable period. See the Privacy Policy and Data scope and handling for more.

Who Sees What is not GovCloud certified, and is not currently in the certification process. GovCloud support is on our roadmap (planned), and Digadop describes the status of certifications accurately as it changes. If you have a Government Cloud or specific compliance requirement, reach the team through whoseeswhat.com/contact and we can walk through where that stands for your org.

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 large language models accessed through Amazon Bedrock. 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.

Penetration testing is planned as part of Lynceon, Digadop’s dedicated Salesforce security product, which is coming soon. For security diligence on Who Sees What today, Digadop is happy to provide security materials to prospective customers under an appropriate confidentiality agreement (NDA). Reach the team through whoseeswhat.com/contact.

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.

We build to WCAG 2.1 Level AA. That is the bar most enterprise, government, education, and healthcare procurement teams ask for, and it is the standard behind Section 508 in the US, EN 301 549 in the EU, and AODA in Ontario.

In practice that means the audit interface is operable from the keyboard alone with a visible focus indicator, the interactive parts of a result (including the record-access sections you expand to see why someone has access) open and close in both directions and announce their state to a screen reader, text and interface elements meet the AA contrast ratios, images carry alternative text, and form fields carry real labels and readable error messages.

We do not use an accessibility overlay widget. Overlays claim instant compliance, do not achieve it, and have drawn regulatory action for saying otherwise. Accessibility is remediated in the product itself, and accessibility issues are tracked and fixed like any other defect rather than papered over at the surface.

If you need an accessibility conformance report (VPAT) for a procurement review, contact us and we will work through it with you.