Who Sees What: Data Scope and Handling
Effective Date: June 27, 2026
This page explains, in plain terms, exactly what the Who Sees What Service reads from your Salesforce org, what it stores, how long it keeps it, and how it is protected. It is published by Stony Point, Inc., a Florida corporation, doing business as (“d/b/a”) Digadop (“Digadop,” “we,” “us,” or “our”), 8742 Peachtree Park Ct, Windermere, FL 34786, and it supplements the Digadop Master Privacy Policy and the Who Sees What Product Schedule. Where this page describes a fact specific to the Who Sees What Service, this page controls for that Service.
1. What the Service does
Who Sees What is a read-only Salesforce access and permission auditor. After an authorized user connects a Salesforce org by OAuth, the Service reads that org’s access-configuration metadata (profiles, permission sets, field-level security, organization-wide defaults, sharing rules, roles, public groups, queues, and user records) and presents reports and dashboards that show who can see what in the connected org. The Service inspects how access is configured. It does not change that configuration and it does not read the field values inside your business or customer records. When you audit a specific record, the Service reads that record’s name and its sharing and ownership information so it can label and explain who can see that record; it does not read the record’s business field values.
Today, the Who Sees What base Service operates read-only against your Salesforce org. If we introduce write capabilities in the future (for example, automated remediation of access issues, or installing and updating Digadop components in your org), they will be optional, require your explicit separate authorization, and be disclosed to you before you enable them.
The access audit itself is computed by deterministic software and uses no artificial intelligence (AI) or large language models. Separately, the Service offers an optional in-product assistant (“Horton”) that uses a third-party AI model (Amazon Bedrock) solely to answer the product questions you type, drawing on our public product documentation. The request sent to the AI model is only your typed question; your Salesforce org data (your configuration metadata, 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 are processed to generate an answer and may be logged to improve the Service. If the assistant cannot help and you ask to be contacted by a person, the contact details you choose to provide (your name and email address, and optionally a phone number and postal address) are stored only so our team can follow up with you (see the Privacy Policy).
2. The OAuth scopes we request, and how we use them
When you connect a Salesforce org, the Service requests the OAuth scopes below. Salesforce’s api scope is broad by design, and grants both read and write capability at the platform level. The Service is designed and implemented to use these scopes only for read operations against your org. We do not write, create, modify, or delete data or configuration in your connected org.
| Scope | How the Service uses it |
|---|---|
api | To call the Salesforce REST and Metadata APIs to read access-configuration metadata (profiles, permission sets, field-level security, organization-wide defaults, sharing rules, roles, public groups, queues, and user records) so the Service can build the access reports. This scope is broad at the platform level, and the Service uses it for read operations only. |
refresh_token | To obtain a refresh token so the Service can re-read the access configuration and keep audit results current without requiring you to re-authenticate on every run. The refresh token is encrypted at rest and is deleted on sign-out or on detected revocation (see Sections 5 and 6). |
offline_access | To maintain the authorized session and perform scheduled or background re-reads of the access configuration while you are not actively signed in, for the same read-only auditing purpose as api. |
openid | To authenticate your identity at connection time, so the Service knows who connected the org and can associate the session with the correct tenant. It is used for identity, not to access business data. |
3. What we read versus what we store
| Category | Read from the connected org? | Stored by the Service? |
|---|---|---|
| Profiles | Yes | Yes, as access-configuration metadata used to build and retain audit reports |
| Permission sets | Yes | Yes, as access-configuration metadata |
| Field-level security (FLS) | Yes | Yes, as access-configuration metadata |
| Organization-wide defaults (OWD) | Yes | Yes, as access-configuration metadata |
| Sharing rules | Yes | Yes, as access-configuration metadata |
| Roles | Yes | Yes, as access-configuration metadata |
| Public groups | Yes | Yes, as access-configuration metadata |
| Queues | Yes | Yes, as access-configuration metadata |
| User records (names, usernames, profile, permission-set, and role assignments) | Yes | Yes, as access-configuration metadata. This is personal data of your users. |
| Your business or customer records (the data inside standard and custom objects, such as Accounts, Contacts, Opportunities, Cases, and custom-object rows) | No | No |
| Encrypted Salesforce refresh token | Issued by the OAuth flow | Yes, encrypted at rest with AWS KMS. Deleted on sign-out or on detected revocation (Section 6). |
| Account data (login identifiers, organization identifiers, contact details) | Provided at sign-up | Yes, for account, security, and support purposes |
| Usage and telemetry (counts of audits and logins, feature usage, and in-product upsell events) | Generated by the Service | Yes, to operate, secure, and improve the Service |
| Feedback and support submissions (the message you type in the in-product assistant, plus organization and user identifiers, the identifiers of any audited object or record, the application version, the last client-side error, your user-agent, and your IP address) | Provided by you, not read from the connected org | Yes, in a feedback table for product triage and support. This table is operational backlog data and is not isolated by Row-Level Security. The feedback context may be transmitted to our issue-tracking provider, GitHub (see whoseeswhat.com/legal/sub-processors). |
The Service reads access-configuration metadata and the user directory. It does not read the field values inside your business or customer records; when you audit a specific record, it reads only that record’s name and its sharing and ownership information to label and explain who can see it. For Who Sees What, the data we hold is therefore primarily configuration, metadata, and access information rather than your underlying business records.
4. Cookies we set
The Service sets only strictly-necessary, first-party cookies. They are all HttpOnly and SameSite=Lax, and they are marked Secure on HTTPS connections.
| Cookie | Purpose | Lifetime |
|---|---|---|
wsw_session | Maintains your authenticated session. The value is HMAC-signed, not a stored password. | Session (2 hours), or 30 days if you choose “remember me” |
wsw_orgs | Remembers which orgs you have connected so the sign-in screen can pre-fill them | 30 days |
wsw_pkce | Protects the sign-in flow against cross-site request forgery (OAuth PKCE) | Ephemeral (under 5 minutes) |
We do not set analytics, advertising, or third-party tracking cookies. Service-improvement analytics is first-party and handled server-side. If we ever introduce non-essential cookies, we will obtain consent where consent is required.
5. Data minimization
We collect and keep only what the Service needs to do its job. The Service reads access-configuration metadata and the user directory rather than the contents of your business records; it stores the access information needed to build and retain your audit reports, the encrypted credential needed to re-read your configuration, the account and telemetry data needed to operate and secure the Service, and the feedback you choose to send us. We do not collect business-record contents we do not need, and we do not set tracking cookies.
6. Retention and deletion
- 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.
- The encrypted Salesforce refresh token is deleted when you sign out and on detected revocation of the connection (for example, an
invalid_grantresponse indicating the connection was revoked). - On account closure or termination, we delete your stored data, including backups, within a commercially reasonable period.
You can ask us to delete your data at any time by emailing privacy@digadop.com, and you can disconnect the Service’s access to your org at any time at whoseeswhat.com/legal/revoke-access.
7. How your data is protected
The Service is designed to protect your data with the following measures:
- Encryption of stored credentials at rest. The Salesforce refresh token is encrypted at rest using AWS Key Management Service (KMS) and stored only in encrypted form.
- Encryption in transit. TLS is designed to protect all connections to the Service and all API calls to your connected org.
- Per-tenant isolation. Customer data is isolated per tenant in PostgreSQL using Row-Level Security (RLS) enforced through a non-superuser database role, so one tenant’s data is not readable in the context of another tenant.
- Session integrity without a password store. Sessions use an HMAC-signed
wsw_sessioncookie verified in constant time. Authentication is by Salesforce OAuth; the Service maintains no server-side password store. - Hosting. The Service is hosted on Amazon Web Services (AWS) in the
us-east-1region.
Operationally, access to production data is restricted to authorized personnel on a least-privilege basis, data is encrypted in transit and at rest, backups are maintained and encrypted, and Digadop performs vulnerability management and maintains an incident-response process. We notify affected customers of a personal-data breach within 72 hours of becoming aware of it.
8. Contact
Questions about how Who Sees What handles your data can be sent to privacy@digadop.com (Data Protection Officer: Steve Wasula) or to legal@digadop.com.
© 2026 Stony Point, Inc. d/b/a Digadop. Effective Date: June 27, 2026. Version 1.0.