Most teams carry their processes in scattered heads, half-finished docs, and a whiteboard nobody photographed. This walkthrough follows a logistics team turning that fragmented operational knowledge into a living, shared model. You capture the work however it arrives, get the diagrams that match it, and refine it together until everyone reads it the same way.
A goal-driven companion to the feature reference. About 15 minutes end to end.
We will follow a small logistics team setting up their first shared process library in Storm2Flow. The names and processes are a synthetic demonstration scenario, but the journey is the one your team takes.
Between them they hold the whole picture. None of them holds it alone, and that is exactly the gap Storm2Flow closes.
Mara opens Storm2Flow and signs in with her work email. If your organisation's domain is registered for Microsoft single sign-on, Storm2Flow sends you to your company's Microsoft login automatically; otherwise a password field appears so you can sign in with an email and password account. The reference covers first-time setup and connecting Microsoft sign-in for a whole team.
Every account starts with a private Space that only you can see. To build something the whole team reads and evolves together, Mara creates a shared Space. She opens the Space switcher at the top-left of the header, picks Create shared space, names it Logistics, and confirms. She is now the Space's first owner.
A Space is the team's shared library of living process understanding. Think of it the way you would think of a Confluence space, except the contents are not pages you write and maintain by hand: they are structured, generated process models the team refines over time. The Spaces reference covers roles, moving processes in and out, and leaving a Space.
A shared model is only as good as the people refining it. With the Logistics Space open, Mara opens the Space switcher and picks Manage members. The invite field autocompletes colleagues from her organisation as she types, so she adds Tom and Lena as Contributors (read and edit) and David as a Viewer (read only, since he reviews rather than edits). Each teammate gets an email letting them know they were added, with a link straight into the app.
Roles map cleanly to how the team actually works: owners manage membership, contributors shape the processes, viewers follow along. You can change a role or remove a member at any time, and a Space always keeps at least one owner.
This is the part most tools get wrong. Writing a clear, shared process description is usually the hardest thing a team has to produce. Storm2Flow makes it the easiest part by accepting your knowledge however it arrives, no matter how messy, and interpreting all of it into one refined description.
Mara creates a process called Inbound receiving. Whichever path the team uses below, the new content lands in the same review modal: Storm2Flow shows the updated description with a short change summary and a diff against the previous text, you can edit it in place, and Accept saves it as a new version. Nothing is committed behind your back.
Mara types the first draft straight into the rich text editor. She gives it a heading, makes the key terms bold, and lists the steps as a numbered list. The editor's toolbar (bold, italic, heading, bullet and numbered lists) means the description reads like a real document, not a flat wall of prose. What you format round-trips losslessly through Storm2Flow.
Tom already has a one-page standard operating procedure as a PDF. He uploads it (Storm2Flow also reads photos of whiteboards, hand-drawn flowcharts, .docx, and .xlsx files). The AI extracts the process from the source and routes the extracted text through the same review modal, so Tom checks and accepts it rather than re-typing it.
Lena does not have a tidy document. She has a wall of unordered notes from the last team meeting. She clicks Braindump, pastes the lot, and Storm2Flow integrates it into the description through the same review step. The raw braindump is never persisted on its own; only the accepted, enriched description is saved.
Sometimes the fastest input is your voice. Tom clicks Record and walks through inbound receiving out loud. Storm2Flow transcribes the take in the language he spoke (auto-detected across English, German, Portuguese, Spanish, and French) and integrates the transcript through the review modal. The transcript and integration reveal progressively as the AI works, so you can see the system is in motion.
Four paths, one outcome: a clear, shared description the team agreed on, with the ambiguity squeezed out. The description editor reference covers each input path in detail.
Here is the reframe most people miss: the description is the centre of gravity, and the diagrams are the output. From the one Inbound receiving description, Mara checks flowchart, swimlane, and BPMN and clicks Generate. Storm2Flow produces all three in parallel, each one a different lens on the same agreed process.
A flowchart reads instantly for anyone. A swimlane makes the warehouse-to-dispatch handoffs explicit. BPMN gives you the formal 2.0 model with lanes, gateways, and events when you need rigour. They are not competing formats: they are the notations that match different conversations about the same work. Sequence and mind map are available too. The diagram reference explains which notation fits which conversation.
Every generation is saved as a new version automatically, and when you refine the description and regenerate, Storm2Flow preserves the existing layout and only changes what is needed. Your work carries forward.
This is where Storm2Flow stops being a diagram tool and becomes a shared, evolving understanding. The first generation is a starting point, not an answer. Now the team interacts on it.
David reads the swimlane and leaves a comment anchored to the goods-inspection step: he wants a documented tolerance for damaged pallets. Lena spots a real risk and raises a Red flag on the description span about unscanned returns. Red is the one flag colour with a fixed meaning: a risk, gap, or concern the team wants to call out. The other colours are yours to use however you like.
Then Mara runs an AI Search for red flags pass over the description. Storm2Flow reads the process the way a critical reviewer would and proposes the risks and gaps it finds; Mara reviews each proposal and accepts the ones that matter. It is a second pair of eyes that never gets tired, narrowing the ambiguity the team could not see on its own.
The team resolves the threads by improving the description: a tolerance rule for damaged pallets, a mandatory scan step for returns. Each change is saved as a restorable version. When Mara clicks Generate again, the open comments and flags ride along and render directly on the diagram as the notation's native annotation, a note on a flowchart or swimlane, a text annotation on BPMN, attached to the step they are about. So the diagram now carries the conversation, and a Red flag still reads as a concern right where it lives. This is the loop that turns four partial views into one shared model everyone trusts.
Inbound receiving is now solid, so the team turns to Order fulfillment, which everyone agrees is slower than it should be. Rather than overwrite the current reality, Mara clicks ⎇ Branch into As-is / To-be. Storm2Flow keeps the As-is process exactly as it runs today and gives the team a To-be branch to redesign in parallel.
Now the conversation has a structure: here is how it works, here is how we want it to work, side by side. The team evolves the To-be description, generates its diagrams, and can show both to stakeholders. Convergence on a better process becomes a visible, shared decision instead of an argument.
Order fulfillment is really several processes wearing one name: picking, packing, and shipping each deserve their own detail. For any leaf process, the editor header offers ＋ Add subprocess. Mara decomposes Order fulfillment into those sub-steps; each hangs under its parent in the sidebar, and opening one gives a fresh editor where the team describes and generates diagrams for that slice independently.
The result is a process tree: a high-level map at the top, the detail underneath, all in one navigable model. This is the structure flat diagrams cannot give you, and it is what lets a team hold a process at every altitude at once. The editor reference covers subprocesses and how they nest inside As-is / To-be branches.
Step back and look at what the Logistics team built. Inbound receiving, Order fulfillment with its As-is / To-be split and its subprocess tree, Returns handling, Stock count: each one a clear description, the diagrams that match it, and the comments and flags that shaped it. None of it lives in one person's head anymore. It lives in a shared Space the whole team reads, questions, and evolves.
That is the difference between a one-off picture and a living model. A diagram you exported last quarter is already stale. A shared process understanding keeps moving with the work: someone raises a flag, the description evolves, the diagrams regenerate, a new version is saved, and everyone is reading the same thing again. Fragmented operational knowledge became operational clarity the team owns together.
Incident management, onboarding, approvals, hiring, compliance. The use cases show why teams structure their processes this way.
How it compares Storm2Flow vs. the alternativesWhere a living, structured process model beats a free-form canvas, a doc page, or a one-off generated diagram.
Every feature The full referenceSpaces, versioning, export, sharing, editing in BPMN and Mermaid, account settings, and keyboard shortcuts.
Common questions FAQData residency, what Storm2Flow is and is not, and how the collaborative refinement loop works.