Stood Flows is designed around one simple promise: a tool that audits your Salesforce org must never be able to change that org, and must never see your org data outside your own machine. This page explains what that looks like in practice — what Stood Flows can and cannot do, where the boundaries live, and how you can verify those boundaries yourself.
The full, formal statement is published at https://stoodcrm.com/security — anything legal or operational lives there. What follows here is the user's view of the same posture.
Stood Flows only reads from Salesforce. It never writes, deletes, deploys, or executes anything against your org.
In plain terms:
It does not create, update, or delete records.
It does not modify metadata — no field changes, no validation-rule edits, no flow modifications.
It does not deploy code or change configuration.
It does not run Apex on your org.
It does not enrol the org into any service or schedule any background job.
If something were to go wrong inside Stood Flows itself — a bug, an unexpected behaviour — the worst it can do is read more than you intended, or fail to read what you wanted. It cannot leave a footprint on the org. There is no "write" capability anywhere in the application that connects to Salesforce.
Every byte Stood Flows ever pulls from your org ends up in a folder under your home directory:
~/StoodFlows/workspaces/<your-org-alias>/
That includes the version snapshots, the Apex source bodies, the Event Log File downloads, the issue records, the analysis caches — everything. Nothing is uploaded to Hway Digital. Nothing is sent to any third party. There is no analytics tracking, no telemetry, no crash reporting, no phone-home.
When the app starts, it loads its own user-interface bundle from a hosted URL (stood.hway.io — the technical hosting domain, not our company website, which is https://stoodcrm.com). That single fetch is the only outbound call the app itself makes — and it carries no information about your org, your machine, or your usage. If that URL is unreachable (you're on a flight, your firewall blocks it), the app falls back to the bundled local copy of the same UI and keeps working. See Offline mode for how to force this and verify it.
Licence checks are done locally too: your key is verified on your machine using cryptography, with no call out to a licensing server. Once you have a valid key file, the app does not need to contact us to confirm it.
Stood Flows does not handle your Salesforce credentials. It uses the official Salesforce CLI (sf) that you've installed and authenticated separately. When you run sf org login web on your terminal, Salesforce's OAuth flow stores a refresh token under your user account — controlled by the CLI, protected by your operating system's keyring where available.
The implications:
We never see your password or any token. The CLI holds it; Stood Flows asks the CLI to perform reads on its behalf.
You can revoke access at any time by logging the alias out of sf (sf org logout) or by revoking the connected app in Salesforce Setup. The next time Stood Flows tries to read, it fails — and there's no path for it to silently re-authenticate.
A "Stood Flows" connected app doesn't exist. The connection uses the standard Salesforce CLI's own OAuth registration, which you can audit in Setup → Connected Apps OAuth Usage.
Stood Flows can only read what the Salesforce user it's connected as is allowed to read. That user is the real boundary you control:
Give the connected user read access only to the objects you want analysed. Anything they can't read, Stood Flows can't see.
Withhold View Event Log Files if you don't want ELF-based analyses (DML user activity, I/O traffic) to run.
Withhold access to managed packages or sensitive custom objects you want excluded entirely.
A dedicated, read-only integration user with narrow object access is the cleanest setup for an audit. See the connected-user permissions section in Prerequisites for the minimum permission set that lets the app work fully, and dial it down as appropriate.
The macOS and Windows installers are both signed and verifiable:
macOS — signed with an Apple Developer ID certificate and notarised by Apple. Gatekeeper rejects any tampered copy on first launch.
Windows — signed via Azure Trusted Signing using a Microsoft-trusted certificate.
Installers are distributed exclusively through https://github.com/Hway-Digital/stood-flows-releases/releases. Each release lists checksums you can verify. If a copy of Stood Flows came to you from anywhere else and the signature doesn't pass, do not run it.
The app does not update itself silently. New versions are released as fresh installers — you choose when (and whether) to install them.
Three practical checks anyone can do, no source-code reading required:
Force offline mode and try a Refresh. Edit ~/StoodFlows/config.json, set "offline": true, restart the app, then attempt to refresh. The app cleanly surfaces a network-related failure rather than reaching any back-channel. This proves there's no hidden alternative path to your org or to us.
Watch the network and the filesystem. Use the OS tools you already trust — Little Snitch, Activity Monitor, Resource Monitor, a Wireshark capture — and run a full refresh. The only outbound destinations you should see are: (a) stood.hway.io (the UI bundle, once at launch), (b) your Salesforce instance via the sf subprocess, and (c) GitHub if you've enabled GitHub-backed issues. Nothing else.
Audit the Salesforce side. In Salesforce Setup, look at Connected Apps OAuth Usage — the only entry for the user Stood Flows connects as will be the Salesforce CLI itself. In Setup Audit Trail, you will find no entries attributable to the connected user during or after a Stood Flows refresh, because Stood Flows never makes a setup change.
If a check produces something unexpected, treat it as a security report — see below.
If you find anything that looks like a way Stood Flows could write to an org, read across orgs it wasn't authorised for, exfiltrate data, or otherwise behave outside what this page describes, please get in touch privately first:
Use the contact route listed on https://stoodcrm.com/security.
Don't open a public GitHub issue with reproduction details until a fix is shipped.
We treat security reports as the highest priority of work.
The formal, legally-binding statement of Stood Flows' security posture — including data handling, incident response, and operational details — is at https://stoodcrm.com/security. If anything on this page conflicts with that page, the statement on stoodcrm.com is the authority.