The gear icon (top-right) opens the dedicated Settings page (it used to be an inline panel). Per-folder settings are inside the folder/graph itself. This document covers everything across both.
Stood Flows resolves sf and gh in this order:
Custom override — a path you've explicitly set in Settings. Persisted to ~/StoodFlows/cli-paths.json. Shown in blue.
Auto-detected — found in PATH, Homebrew, nvm, Volta. Shown in green.
Fallback — neither found. Shown in red. The corresponding CLI-bound features (Refresh for sf, GitHub issues for gh) are disabled.
To override: click Browse… next to the CLI, point at the binary (the system file picker filters to executables). The app verifies the path by running <cli> --version and shows the version on success.
To clear an override, click Clear next to the path. Auto-detection resumes.
This is the lever you pull when you've installed sf in a non-standard location (corporate-managed install, Volta-isolated Node, sandboxed terminal). The override survives upgrades of Stood Flows itself.
Each folder you've created shows here with its current licence status:
Green check + expiry date — key is valid.
Amber — key expires within 14 days.
Red — no key or expired.
Paste a new key into the row; Stood Flows verifies it offline (Ed25519 signature against the embedded public key + folder-alias match + expiry) and writes it to workspaces/<alias>/license.key on success. The verification is local — no network call.
See License keys for the full picture.
Point Stood Flows at an S3 (or S3-compatible) bucket here to publish analysis versions for others to pull. Publishing is on demand — you click Publish to push (or refresh) the current versions to the bucket; it is not a continuous background sync. Bucket credentials are stored in the OS keychain, never in the plain-JSON config files.
Which of Publish and Refresh you get is decided by the folder's own Settings, where you choose how the folder is shared and what your role is:
Admin — you refresh graphs from the org and Publish the results. Needs a licence key.
Contributor — you Refresh (pull) the shared data and work on issues. No key needed.
See Sharing and roles for the full picture and License keys for what the key covers.
The version number is shown at the bottom. When a newer version is available, a download link appears with the changelog URL on github.com/Hway-Digital/stood-flows-releases. Updates are install-via-DMG/installer (no in-place auto-update).
Each folder's own Settings page asks two questions at the top, and shows only the fields the answers need:
Sharing — No sharing (solo, everything stays on this machine), GitHub (the folder is a git repo you sync yourself; its issues live in GitHub), or S3 (Stood Flows publishes and pulls the whole analysis).
Your role — Admin (refreshes graphs from the org and publishes) or Contributor (reads the analysis and works on issues).
A summary at the bottom of the page names the buttons your choices produce, so you can check a folder's setup without leaving it. Full details in Sharing and roles.
Choose GitHub as the sharing method and give the repository as owner/name, or leave it blank to let Stood Flows detect it from the folder's git remote (gh repo view, which works when the folder is itself a git repo). From then on every issue operation in the folder routes through gh issue ….
Stood Flows does not move graph files over GitHub — you pull and push the folder yourself, as you would any repo. Only the issues are handled by the app.
gh must be installed and gh auth login must have been completed once. If gh is in a non-standard location, set the path in Global Settings.
See Issue management for how issues work end-to-end.
The amber OFFLINE banner at the top of the window means the app has decided to operate in a degraded mode. Three independent signals can light it up:
Shell fell back to the bundled renderer at startup. Happens when the user-interface bundle at stood.hway.io (the technical hosting URL Stood Flows pulls its UI from on launch — not our website, which is https://stoodcrm.com) was unreachable when the app started. The bundled local copy takes over automatically. Refreshes still need network to talk to Salesforce — but the UI itself runs from disk.
The OS reports no network. navigator.onLine === false. Catches the "user pulled the Wi-Fi cable mid-session" case.
You've forced it. A file flag, described below.
The banner copy adjusts to the cause. If signal 3 is the only one active, it reads Forced offline mode.
Edit ~/StoodFlows/config.json and set offline: true:
{
"defaultOrg": null,
"offline": true
}The change takes effect on next app launch. Restart Stood Flows; the banner appears.
When forced offline, the app no longer attempts to load its user-interface bundle from the network at all. The Electron shell reads config.json before opening the window and loads the bundled local UI directly. This matters in two scenarios:
Corporate proxies and web filters (e.g. Symantec BlueCoat, Zscaler, Forcepoint) sometimes intercept stood.hway.io and replace the page with a block notice. Without offline: true, the shell would unwittingly load that block page (a successful HTTP response, from the proxy's perspective) and you'd see the proxy's branding instead of Stood Flows. With offline: true, the shell never even tries the cloud URL — it goes straight to the bundled copy.
Demonstrating the read-only posture. Forced offline removes the only outbound network call the app itself makes, so a network monitor will record nothing but the deliberate Salesforce CLI traffic during a refresh.
If something looks off — blank window, wrong page, fallback didn't trigger — the Electron shell writes a timestamped append-only log of every startup decision to:
~/StoodFlows/logs/main.log
A typical clean startup looks like:
[2026-05-20T09:14:02.110Z] [Shell] config.json offline=false[2026-05-20T09:14:02.111Z] [Shell] Loading cloud renderer https://stood.hway.io/desktop.html[2026-05-20T09:14:03.022Z] [Shell] did-finish-load url=https://stood.hway.io/desktop.html[2026-05-20T09:14:03.041Z] [Shell] post-load probe: title="Stood Flows" hasRoot=true
A proxy-blocked startup looks like:
[…] [Shell] did-finish-load url=https://stood.hway.io/desktop.html[…] [Shell] post-load probe: title="Access blocked" hasRoot=false[…] [Shell] Loading local fallback (post-load probe: page is not our renderer (title="Access blocked")): app://stood/desktop.html
A forced-offline startup looks like:
[…] [Shell] config.json offline=true[…] [Shell] Forced offline at startup — loading app://stood/desktop.html directly (bypassing https://stood.hway.io/desktop.html)
If you need help debugging a connectivity issue, email the main.log to support and we'll walk through it with you.
This is useful when you want to:
Inspect a cached graph on a trip without the app ever attempting network calls.
Demonstrate the app's read-only nature to a customer (no risk of any sf invocation hitting the org).
Catch any code path that wrongly assumes network is available.
The flag is sticky until you flip it back to false (or delete the line — missing attribute is treated as false). New config.json files seed offline: false.
Most of the panel UI:
KPI, Volumes, Complexity, Custom Objects columns (read from cached version JSONs).
Apex tab + the dependency tree + source view (reads apex/classes/*.cls from disk).
Licensing tab (reads licensingAnalysis from the version JSON).
DML, I/O tabs as long as a previous Analyze run wrote the aggregates to disk.
Apex package generation (the migration handoff bundle — reads from apex-panel.json cache, writes locally).
Issue browsing in CSV mode.
Refresh — needs sf against the org.
Any "Analyze X" button that needs fresh org reads.
GitHub issue operations — gh needs network.
Firestore-based licence validation (we don't do that anyway, but worth noting — licence checks are 100% local crypto).
The point of offline mode is to make the read-only nature of the app obvious and testable. If you flip the flag and any feature you care about breaks, that's a bug — please file it.
Setting | File |
Default org, offline flag |
|
CLI path overrides |
|
Per-folder licence key |
|
Per-folder sharing method, role, GitHub repo |
|
Per-graph GitHub repo, refresh history, RT tags, integration patterns, currency |
|
Per-graph version snapshots |
|
All of it is plain JSON or CSV. Back it up with the rest of your project files. Nothing's in the system registry, nothing's in a database, nothing's stored remotely by Stood Flows.