Here's the thing you came for: a free template for documenting Salesforce flows, plus how to fill it without opening the flow's XML. Flows are where the most important, least documented logic in your org lives — this is how to write down what they actually do.
Flows are the hardest thing in a Salesforce org to document, and it's not your fault. A field has a type and a help-text slot; a flow has a canvas of elements and, underneath, a block of metadata XML. There is no export that says "when an Opportunity is won, this flow creates a renewal task and updates the account tier." That sentence — the only thing anyone actually wants — lives nowhere until a human writes it. Which is why flow documentation is usually missing, and why an inherited org's automation is such a black box.
What to capture for each flow
You don't need to read the XML. Open the flow, and for each one write down the handful of things that make an inventory genuinely useful:
- Name and purpose. The plain-language sentence: what business outcome does this flow produce? If the name doesn't already tell you (
Opportunity After Save - Set Renewal TaskbeatsFlow_17), that's a naming problem worth fixing while you're here. - Object and trigger type. What object does it run on, and is it record-triggered, scheduled, screen, platform-event, or autolaunched? Record-triggered is the one that participates in the save.
- When it fires. For record-triggered flows: before-save or after-save, and on create, update, or delete. This is what places it in the order of execution — and it's the difference between a flow that cheaply sets a field and one that touches related records.
- What it does to data. The records it creates, updates, or deletes, and on which objects. This is the part that ripples across your org, so it's the part worth being precise about.
- Fields it reads and sets. Especially the fields it writes — those are the ones another automation, or a person, can collide with.
- Active or not. An inactive flow that still looks live in a list is a documentation trap. Note it.
The template gives you a column for each of these, one row per flow, so the inventory is scannable and you can sort by object to see what touches what.
The honest catch — this is real work, and it decays
Everything above is doable by hand, and for a handful of flows it's worth doing directly. But be honest about two things. First, it's slow — genuinely understanding what a branchy, subflow-calling flow does can take real time per flow, and a mature org has dozens. Second, and worse, it decays the moment you finish — the next admin edits a flow, adds a new one, deactivates another, and none of that updates your spreadsheet. A flow inventory is accurate the afternoon you write it and drifting by the next deploy.
That's the honest boundary, and it's a specific one: the tedious part — reading each flow and describing what it does — is exactly the part that can be automated, while the judgment part — is this flow still needed, is it doing the right thing — stays yours. That's what SchemaForce does here: it reads a flow's logic and drafts the plain-language "what it does" for you (never storing the flow's internals, only the summary), and its Process Map places each flow in the order of execution for its object. You still decide what's right and what to retire; what you stop doing is the manual transcription that never stays current. The template is the right tool for documenting five flows by hand. Past that, the work has outgrown the spreadsheet — which is the same lesson every hand-maintained Salesforce document eventually teaches.
Start here
Download the template and document your five most important flows — the ones you'd most hate to inherit undocumented. Fill the "what it does" and "what it changes" columns first; those are the ones no export can give you. And when five becomes fifty and the spreadsheet starts drifting faster than you can maintain it, that's not a discipline failure — it's the signal to let the flows describe themselves.
