Prerequisites and the Salesforce CLI

Stood Flows is an Electron desktop app that does not speak to Salesforce directly. Every read goes through the Salesforce CLI (sf) running as a subprocess on your machine. If sf works in your terminal against an org, Stood Flows works against that org.

Where to get Stood Flows

Stood Flows is distributed as a signed installer — one DMG for macOS, one MSI/EXE for Windows. Grab the current release from:

https://github.com/Hway-Digital/stood-flows-releases/releases

Install it like any other desktop app (open the DMG, drag into Applications; or run the installer on Windows). There is nothing to build, nothing to compile, no Node toolchain to set up. The installer carries everything Stood Flows itself needs to run.

What you need installed alongside

Installing the Salesforce CLI

The CLI is published by Salesforce and updates itself.

• macOS / Linux: brew install salesforce-cli (Homebrew) or download from https://developer.salesforce.com/tools/salesforcecli.

• Windows: download the MSI installer from the same link.

• NVM / Volta users: sf is a Node binary; if you use a version manager, install with npm i -g @salesforce/cli inside the active Node version.

Verify with:

sf --version

You should see something like @salesforce/cli/2.x.x.

Windows: follow the official performance tweaks

Out of the box, sf on Windows is noticeably slower than on macOS / Linux — primarily because of real-time AV scanning and an unconfigured PowerShell profile. Every Stood Flows refresh runs many sf invocations in parallel, so a one-second per-invocation slowdown turns into minutes of difference across a backbone refresh, an Apex dependency walk, or an ELF download.

If you're on Windows, please follow Salesforce's CLI performance guide before running a Refresh:

https://developer.salesforce.com/docs/atlas.en-us.sfdx_setup.meta/sfdx_setup/sfdx_setup_perf_windows.htm

The two highest-impact items in that page:

1. Add a Microsoft Defender exclusion for the sf install directory (typically %LOCALAPPDATA%\sfdx or C:\Program Files\sfdx\). Real-time scanning of every Node module load is the single biggest performance hit.

2. Pre-compile the PowerShell profile (the page walks you through Add-Type against System.Management.Automation.dll) so subsequent shell starts are cached.

There are a couple more tweaks on the same page (long-path support, terminal of choice); apply them as needed. On a tuned Windows machine sf performance is comparable to macOS; un-tuned, it can be 3–5× slower.

Configuring sf for your org

For each org you want to analyse, authenticate once on the command line:

sf org login web --alias my-prod-org

A browser window opens, you log in to the org, the alias is saved locally. From then on Stood Flows can talk to that org via the alias — it never sees your credentials. The OAuth token is stored by sf in your home folder (~/.sf/) under the OS keychain when possible.

Useful follow-ups:

sf org list                          # show every alias you've logged into
sf org display --target-org my-prod-org    # confirm an alias is alive

If a token expires, re-run sf org login web for that alias. Stood Flows will surface the auth error in its progress panel.

Permissions the connected user needs

Stood Flows is read-only. The connected org user needs visibility on what you want to analyse, nothing more:

• View Setup and Configuration (system permission). Required for metadata reads.

• API Enabled (system permission). Required to make any SOQL or REST call.

• Read access on the standard CRM objects (Lead, Opportunity, Case, Account, Contact, Campaign) and any custom objects you plan to enable in the graph.

• View All Data or View All on objects with millions of rows is convenient but not required — Stood Flows scopes queries by record type when it can.

• For Event Log File reads (used by DML and I/O analyses): View Event Log Files permission. This unlocks the EventLogFile object so Stood Flows can pull yesterday's hourly logs for Login, DatabaseSave, API, RestApi, CalloutRequest, ExternalCustomApexCallout, ExternalODataCallout, ExternalCrossOrgCallout, etc.

• For Apex source bodies: the user needs to be able to query ApexClass.Body and ApexTrigger.Body via the Tooling API. A System Administrator profile or a permission set granting Modify Metadata / Author Apex works.

A dedicated read-only integration user with these permissions is the cleanest setup. Anything Stood Flows writes lands on your local machine — never on the org.

What Stood Flows actually invokes

For full transparency, the only shell commands the app runs against the org are:

• sf org list — list orgs you've authenticated.

• sf org display --target-org <alias> — fetch instance URL, user ID, version.

• sf data query --target-org <alias> --query "<SOQL>" — read SOQL data.

• sf data query --target-org <alias> --query "<SOQL>" --use-tooling-api — Tooling API for Apex bodies, MetadataComponentDependency, record-type details.

• sf api request rest --target-org <alias> --method GET <endpoint> — REST GETs (used for /services/data/limits/... and Event Log File downloads).

• sf org login web --instance-url <url> — kick off an interactive login flow when you ask for one in the app.

There is no sf project deploy, no sf apex run, no sf data create, no sf data update anywhere in the codebase. The IPC bridge that hands shell commands to sf literally has no path for write operations. See the security posture section for the technical detail.

When sf is in a non-standard location

Stood Flows tries to locate sf via your PATH, then via common install locations (Homebrew, Volta, nvm). If autodetection fails, the gear icon → "Global Settings" shows you the CLI status and lets you Browse… to point at the binary explicitly. This override is persisted to ~/StoodFlows/cli-paths.json and used for every subsequent invocation.

If the CLI is missing or broken, the app surfaces a red status. Refreshes will refuse to run — there is no fallback.