Architecture and Security at SFDevTools

Last Updated: February 26, 2026

SFDevTools provides deep access to your Salesforce metadata, which means we operate with an absolute commitment to security and transparency. We engineered our stack to be fundamentally ephemeral where possible, limiting our surface area and prioritizing zero-trust principles.

The SFDevTools Stack

SFDevTools runs on four core infrastructure components. All connections are secured over TLS.

Component Roles

Component	Host	Role
Frontend	Netlify	Static React app. No customer data stored by default.
Backend API	Deno Deploy	Stateless edge functions. All Salesforce API calls are proxied here.
Database	Supabase	Postgres - stores accounts, encrypted tokens, preferences, and optional query history.
Cache	Upstash Redis	Optional, user-controlled ephemeral cache. Never persists data beyond TTL.

Data Flow

1. Authentication The frontend uses Supabase Auth (PKCE flow) for user sign-in. On success, a JWT is issued and attached to every backend request, which the backend validates on each call.

2. Connecting a Salesforce Org

When connecting an org, you control the level of access by selecting your connection type:

• Session Only: Requests limited scopes (api web) from Salesforce. We receive a temporary access token that is destroyed the moment you log out. No refresh token is ever requested or stored.
• Persistent: Requests extended scopes (refresh_token offline_access) to keep you logged in across sessions. The resulting access and refresh tokens are encrypted using AES-256-GCM and stored securely in our database.

The plaintext token never leaves the backend process that encrypted it.

3. Using a Tool Every tool action flows: Browser → Backend API → Salesforce. The backend decrypts your token in-memory for the duration of that request, proxies the API call to Salesforce, and returns the result. To reduce Salesforce API load, you can opt into caching specific results (like describes) in our Redis cache. Your actual Salesforce data is never written to our database.

4. Persistent User Data A small set of user-generated data (preferences, connections, and optionally your query/Apex history) is stored in Supabase. Every table enforces strict Row Level Security (RLS) - your records are uniquely isolated to your active session at the database level.

---

How We Handle Your Data

The underlying philosophy behind SFDevTools is that your data is yours. We only persist the information technically required to make our multi-org tools functional, and we give you control over where your data lives.

1. Identity and Access

We do not ask for or store your Salesforce passwords. All authentication relies on native Salesforce OAuth 2.0. Our backend receives OAuth tokens, which are deeply encrypted using AES-256-GCM. Decryption occurs dynamically in-memory exclusively when an active session requires it to proxy a request.

2. The Scope of Our Access

When you connect an org, SFDevTools inherits your exact permission boundaries. We cannot bypass your Salesforce profile restrictions. If your user cannot query an object or run Apex in Salesforce, you cannot do so via SFDevTools.

3. Ephemeral Operations and User-Controlled Caching

Salesforce API calls can be slow. To improve performance, we use an Upstash Redis cache to reduce round-trips. You are in control of this cache.

By default, caching is toggled ON for SObject describes and global describes. If you turn this setting off, all requests route directly to Salesforce. Cached entries are keyed per-user and per-org - you will never share a cache state with another user.

What can be cached	TTL	Notes
SObject describe (single object)	1 hour	Compressed (Gzip)
SObject global describe (full list)	1 hour	Compressed (Gzip)
Entity/Field definitions query results	1 hour	Compressed (Gzip)
Salesforce access tokens	90 minutes	Encrypted (AES-256-GCM)

Note: All cache entries have a hard expiry. On account deletion, all Redis keys belonging to your user are explicitly purged before database records are removed.

4. What We Do Persist (and What You Control)

To provide a seamless experience, we store a well-defined set of data in our database.

Your Execution History is up to you: You can choose whether to save your SOQL queries and Apex execute snippets to our database (for cross-device access) or toggle this feature off. If turned off, your queries and scripts are stored strictly in your browser's Local Storage and never touch our servers.

For data saved to our database, we store:

• User Profiles: Name, timezone, and default org preferences.
• Salesforce Connections: Org details, aliases, connection type (Persistent vs Session), and encrypted OAuth tokens (only if Persistent is selected).
• Execution History (Optional): SOQL queries, Apex scripts, and SOSL searches you have explicitly opted to sync.
• Dashboard Preferences: Which objects are pinned and their display order.
• Data Import Logs: Metadata about bulk jobs (object name, operation, record counts, status/errors).

Your Salesforce records and field data are never written to our database.

5. Data Removal

• Automated Session Cleanup: If you connect to an org using a "Session Only" connection, logging out of SFDevTools automatically purges that connection and immediately busts all associated cache keys.
• Per-item deletion: Query history, dashboard tiles, and import logs can be deleted individually from within the app at any time.
• Account deletion: SFDevTools provides a self-serve account deletion option in your profile settings.

Triggering account deletion is immediate and irreversible. It will:

1. Purge all Redis cache entries for your user and connected orgs.
2. Delete your account from our Auth provider.
3. Cascade automatically through the database, permanently removing your profile, synced query history, dashboard preferences, import job logs, and session state.

Sub-Processors Overview

SFDevTools relies on industry-leading platforms to ensure stability and security. For a complete, up-to-date breakdown of the vendors we use to process requests, please refer to our dedicated Sub-Processors List.