Your flow data never leaves your browser
Flowscope makes no network requests after the page loads — no upload, no server, no telemetry. The page is served with a Content-Security-Policy that forbids any outbound connection, so this is enforced by the browser, not just promised. It matters because Okta does not scrub exports: hardcoded values stay in them.
The one thing remembered between visits is your Recents list, stored by your own browser so the tool can re-open exports you looked at before. Remove any entry with the ✕ beside it.
.flow (a single flow), .folder (a folder of flows), .flopack (a packaged export). These come out of the Okta Workflows console — open a flow or folder, then ⚙ → Export.
You can open more than one file at once. This matters more than it sounds; see Multiple files.
To load several files, select or drag them together. You can also drop a second file onto an already-loaded one; it joins the same workspace rather than replacing it. ↺ Start over clears everything.
Filters the list as you type, and it searches more than names: type a system (okta, slack, salesforce) or an action (suspend, delete, deactivate) and you get every flow that touches it. This is the fastest way to answer “which of these 40 flows can suspend a user?”
📁 Whole-export overview steps back from individual flows to the whole picture. Theme swatches sit in the sidebar footer — Midnight (default), Light, Dark, J.A.R.V.I.S. — and are purely cosmetic.
Click a flow and the sections render in a fixed order. The order is deliberate: the most consequential information sits at the top, so reading downward is reading in descending order of how much it can hurt you.
The flow name, then five buttons: Copy (the whole summary as Markdown, ready for Confluence or a ticket), .md (the same as a file), Spec (a platform-neutral portability spec — see below), Compare, and View as graph.
Below the title, one dense line: how the flow starts · how many cards (and how many are hidden inside branches) · how many systems · who calls it · which file it came from.
The number worth understanding
Okta stores the contents of each If/Else arm as a complete sub-flow nested inside the branch card. The console shows a collapsed branch; Flowscope counts what is inside it. A flow that looks like 10 cards in Okta can genuinely be 116. A large “(N inside branches)” means the flow is far more complicated than it appears.
One bold sentence saying what the flow does, written around the systems it affects (“deactivates a user in Salesforce and posts to Slack”) rather than listing steps. If you read nothing else, read this.
Every write to an external system, grouped by system, with the connector logo. This is the blast radius — what would actually happen in your tenant if the flow ran right now. Destructive actions (delete, suspend, deactivate) are highlighted in red.
If a flow makes no changes it says so outright — “This flow only reads data” — which is a useful answer, not a blank space. Use it: first stop before editing anything, and the most useful section in a change-approval or audit conversation.
The same idea for reads: what data the flow pulls in, and from where. Reads break nothing, so they sit below writes.
The Okta Workflows Tables this flow reads or writes. Tables are the quiet way two flows become coupled without either calling the other — this section is what lets the impact analysis catch that later.
The flow broken into phases, in order, so you can follow the logic without reading every card.
Check the small note beside the heading. “from your comments” means the phases came from comment cards the original engineer wrote — their own account of the design. “auto-segmented” means nobody left comments and Flowscope grouped the steps itself. The first is far more trustworthy, which is a decent argument for leaving comment cards in your own flows.
The tricky bits — recursion, loops, missing error handling, and anything else worth knowing before you touch the flow.
The helper flows this one hands off to — Call Flow, Call Flow Async, and loop cards (each, map, reduce and friends) that pass records to a helper. Click a name to jump to it.
The section that answers “what will I break?” Ranked, colour-coded risk lines first, then the detail:
Every name is clickable. If nothing depends on the flow it says so plainly — “Nothing else depends on this flow, so changes here are contained.” It does not invent risks to look busy.
When a flow calls one that is not loaded, this lists what is missing, with the internal flow id and its name where the file records one. Open the export containing the missing flow and it resolves automatically.
Literal values typed into cards — email addresses, group names, URLs, thresholds, region codes. These are what break when something is renamed, and what a migration or tenant move has to account for.
Press View as graph for a full-screen diagram. Three layouts: ↓ Top-down (a conventional flowchart, the best starting point), → Left-right (better for long linear flows), and ✷ Web (a force-directed cluster, better for seeing shape than reading order). fit re-centres if you get lost. Branch arms and error handlers are drawn as labelled groups.
What it is for: writing the flow down in a form that does not depend on Okta — for a migration, a disaster-recovery record, or an auditor who needs something readable. Press Spec in the summary header to download it.
It is not the summary in another format. The summary is deliberately lossy: prose, optimised for someone skimming it in thirty seconds. The spec is the opposite — complete, structured, detailed enough to rebuild from, and explicit about anything it cannot decide for you.
Nothing is guessed
Where an endpoint cannot be verified, the spec says a human has to decide rather than inventing a plausible-looking one. A 95%-correct instruction for a flow that deprovisions people is worse than an admitted gap. The spec also reports its own coverage: how many cards it described, and how many input fields were wired, literal, or left unset.
What it is for: you have a flow from before and after a change, or from staging and production, and you need to know what genuinely differs — not which JSON keys moved.
Setting it up: open both exports at once. They merge into one workspace and you will see two flows with the same name, one from each file. Click either, press Compare, and pick the other version from the dropdown. Swap reverses which side counts as “before”; Copy copies the comparison as Markdown for a change ticket.
If two versions are functionally identical it says so: “No functional differences — these two versions do the same thing.”
One known limitation
Cards are matched by internal id. If someone deleted a card and rebuilt it from scratch rather than editing it, the id changed — so it reads as a removal plus an addition rather than a modification. Not wrong, just noisier than it needs to be.
The bird's-eye view of everything loaded, rather than one flow. Use it when you first inherit a folder and do not yet know what is in it.
Okta exports are per-flow or per-folder, but real automation routinely spans several. Open one file and a call into a flow living elsewhere shows as a missing dependency — correct, but incomplete. Open the second file and that same call resolves into a real link, the impact analysis extends across the boundary, and cross-file dependencies appear in the overview.
When the impact section matters, load everything related — not just the file you are editing.
Open everything → Whole-export overview → read Systems used and Everything this export changes → work down the flow list reading only headlines.
Open the flow and every related export → Changes it makes → If you change this flow, watching for Shares tables with and any Not loaded warning.
Open both → Compare → read What it changes in external systems first; the rest is detail.
Open the flow → Spec, or Copy / .md for the summary → paste. The Markdown carries the headline, the changes, the walkthrough and the dependencies.
Flowscope reconstructs meaning from Okta Workflows exports — in your browser, with nothing sent anywhere.
Open a .flow / .folder / .flopack export. For each flow you get a plain-English summary of what it does, what it changes, and the tricky bits — reconstructed from the cards themselves (your comments enrich it, but aren't required). Then open the floating graph to see the shape.