Stood Flows treats every finding as a candidate for an issue — something the team has to act on, comment on, close, or come back to. Every panel supports issue creation through a right-click menu on a row or cell, and every issue carries an anchor that pins it to the exact thing it's about.
Where those issues are stored follows the folder's sharing method, set in its Settings — you pick how the folder is shared, and the issues go with it. See Sharing and roles. The Issues tab looks and behaves the same in all three cases.
Every issue is in one of three states, and the folder dashboard reports all three plus the total:
Open — raised, not yet looked at.
Qualified — confirmed as real and worth doing. This is the step that separates a list of findings from a plan of work.
Closed — dealt with, or dismissed.
Anything the app cannot read as qualified or closed counts as open, so an issue is never lost by having an unexpected value in it.
With GitHub as the sharing method, the middle step comes from your repository's labels, so qualification stays where your team already does it.
All issue operations go through the gh CLI:
Listing — gh issue list
Creating — gh issue create
Editing, commenting, closing, reopening — the corresponding gh issue ... commands
The repository is taken from the folder's Settings, where you can type owner/name. Leave it blank and Stood Flows detects it from the folder's own git remote (gh repo view), which works when the folder is itself a git repo — the usual case, since with GitHub sharing you keep the folder in sync by pulling and pushing it yourself.
You'll need the gh CLI installed and authenticated (gh auth login). The CLI status (green / red / browse) is in Global Settings, same place as sf.
GitHub issues are real GitHub issues — labels, milestones, assignees all work. They show up in your repo's normal Issues tab. You can act on them on GitHub directly and Stood Flows picks up the changes on the next fetch.
Issues are stored in a file inside the folder:
workspaces/<alias>/graphs/<slug>/issues.csv
Same operations — create, edit, comment, close, reopen — all done locally. The file has a stable header so it's safe to open in a spreadsheet.
This is the offline-by-default mode. Use it when:
The org's audit work is private and you don't want a GitHub repo for it.
You're early in the analysis and don't yet know who'll own which finding.
You want issues to stay with the folder and go nowhere else.
Issues are kept in the same file as above, but it is published and pulled along with the rest of the analysis, and merged rather than overwritten in both directions.
This matters because issues are the one thing everybody writes. An Admin publishing a fresh analysis doesn't wipe out the issues a Contributor raised in the meantime, and a Contributor pulling the latest analysis doesn't lose their own. If two people gave an issue the same number while working apart, one of them is renumbered so neither is lost.
Contributors also get a Publish issues button, which sends their additions, comments and closures back on their own — without republishing an analysis they didn't produce. See Team sharing (S3).
An anchor is a tiny block of metadata embedded in the issue body. It looks like:
<!-- stood-anchor:graph=acme-prod-q3,rt=01234000000xyz,col=score,obj=Opportunity,name=New Business -->The five fields are:
graph — the graph slug. So an issue created in acme-prod-q3 knows it belongs to acme-prod-q3 even after you've created acme-prod-q4.
rt — the record-type ID it relates to (where applicable).
col — the column (or analysis dimension) the issue was created from.
obj — the object type (Lead, Opportunity, Apex class name, profile name, etc.).
name — a human label (RT developer name, profile label, app name).
Anchors are HTML comments — they're invisible in the rendered issue body on GitHub and ignored when reading the file in a spreadsheet. But Stood Flows reads them and uses them to:
Filter — the Issues tab shows a count next to each KPI/DML/IO/Apex node that has open issues anchored to it.
Navigate — clicking View on an issue jumps to the right tab, expands the right tree node, applies the right filter, and highlights the row.
Survive refreshes — record-type IDs and column names stay stable across versions, so an issue anchored to Opportunity.NewBusiness.complexity last quarter is still findable after a refresh that adds new RTs.
You don't write the anchor yourself. Every "Create issue" entry point in the app constructs one for you and pre-fills the body with a sensible title and a description that includes the metric value at creation time.
Three entry points:
Right-click any KPI cell → "Create issue". Anchor records the (object, RT, column) for that cell.
Right-click a row in DML / Licensing / I/O / Apex → "Create issue". Anchor records the drill path.
Issues tab → New issue (with the form). Used for issues that aren't tied to a specific cell.
The pre-filled body is usually enough — review, tag with labels if needed, save.
Every issue row in the Issues tab has a View button. Clicking it:
Reads the anchor from the body.
Switches to the appropriate panel (KPI, DML, IO, Apex, or Licensing based on col and obj).
Walks the panel state to the anchored target — expanding tree nodes, applying filters, scrolling.
Briefly highlights the destination row so you can spot it.
This is the muscle behind "every finding is verifiable". You don't lose the link between a comment from three months ago and the data that caused it.
Run a fresh Refresh + analyses.
For each high-complexity, low-volume row in the KPI table: right-click → "Create issue" with label retire-candidate.
For each integration in the DML integration bucket you don't recognise: right-click → "Create issue" with label unknown-integration.
For each callout destination with errors >20%: right-click → "Create issue" with label broken-callout.
Hand the resulting Issues tab to the team — every row is grounded in a specific number on a specific version of the data.
After a release:
Refresh.
Open the Issues tab and walk down. For each open issue, click View and confirm the metric has improved (or moved as expected).
Close issues that are resolved; comment on issues that have moved differently than expected.
The anchors mean the metric is always one click away — no copying URLs, no remembering which RT was which.
Switching between No sharing and S3 keeps your issues: it's the same file, which simply starts (or stops) travelling with the analysis.
Switching to or from GitHub moves you between two genuinely different systems, and Stood Flows does not copy issues across. Turning GitHub on leaves the local file untouched and starts writing new issues to the repo; turning it off leaves the GitHub issues where they are, readable on GitHub, and goes back to the local file. Copy anything you want to keep across by hand before you switch.