Policy version 2026-07-23

Privacy notice

What the maintainer receives

The sf-deck application does not send the maintainer Salesforce records, metadata, results, credentials, tokens, usernames, org identifiers, usage analytics, crash reports, machine identifiers, or profiling data. The maintainer therefore does not host, sell, share, profile, or otherwise control your Salesforce customer data.

If you email the project or interact through GitHub, the information you choose to provide is received through that service and used to respond, maintain the project, and address security or support questions.

How Salesforce data is processed

sf-deck uses Salesforce orgs already authenticated through Salesforce CLI. It may request the current access token from the CLI, hold it in process memory, and use it for direct Salesforce REST or SOAP requests. It does not write the token to its own databases or logs.

Salesforce record payloads are not persistently cached. Record lists and details, SOQL and report result rows, list-view results, Salesforce RecentlyViewed rows, and related-record lookups remain in process memory and disappear when the process ends.

Local data

Working state under ~/.sf-deck/ can include settings, safety levels, chips, recently visited item references, org catalogue details, metadata/schema caches, saved SOQL text and history (not returned rows), saved Apex and history, dev projects, tags, bundle registrations, usage counters, logs, and optional update-check state.

Exports and SFDX bundles are written to paths you choose. The default bundle path is ~/sf-deck-bundles/. Local files are intended to be readable only by your operating-system user.

Network requests

Normal data traffic goes directly from your computer to the selected Salesforce instance. When enabled, the update checker makes at most one request every 24 hours to GitHub Releases. It sends no installed version, Salesforce data, credentials, or sf-deck identifier and never installs software. GitHub may receive ordinary network information such as an IP address under its own privacy terms.

Inspect, delete, and revoke

sf-deck data inspect
sf-deck data erase --yes
sf-deck org logout --org <alias-or-username> --yes

Close every sf-deck process before erasing. Add --include-bundles to delete the default bundle directory. Custom export and bundle paths must be deleted manually. Local deletion does not revoke Salesforce sessions elsewhere; administrators can revoke sessions or connected-app access in Salesforce when needed.

Changes and contact

Material changes receive a new policy version and require acknowledgement before sf-deck contacts a real org again. Questions can be sent to hello@jacobstokes.com. Security issues should follow the security policy.