Resources / How Flow Forms Works / After submission

What happens after someone fills out the form?

The short answer

In most form tools, what happens after someone hits submit is an email notification and a new row in a spreadsheet, and everything from there is a person's job: noticing it, deciding who needs to see it, forwarding it, and remembering to follow up. In an actual workflow, submission is where the system's work starts, not where it ends. The submission routes itself to the right approver based on what's in it, moves through each approval step in order, sends reminders when it sits too long, answers "where is it?" without anyone having to ask, and lands as a complete, searchable record of who approved what and when. The difference between a form and a workflow is everything that happens after the submit button.

On this page

Why the existing system doesn't cover it How districts and agencies handle it now Where it goes wrong

What doing it well actually requires Common questions How Flow Forms handles it

Why the existing system doesn't cover it

Form builders are built to collect responses, and that's where their job ends. Submission produces a notification email and a stored response, and the tool considers the transaction complete. There's no concept of the submission having a next step: no routing based on what was entered, no sequence of approvals, no reminder when something stalls, no status anyone can check, no record of the approval chain, because in a response-collection tool, there is no approval chain. Everything that makes a submission move is assumed to happen outside the tool, in email, in memory, in whoever notices.

How districts and agencies handle it now

The submission arrives in one inbox, and a relay begins. Someone reads it, decides who's next, and forwards it. The next person does the same. Status lives in people's heads and sent folders: finding out where a request stands means asking someone, who often has to ask someone else. When a step stalls, nothing surfaces it, the request just goes quiet until the person who submitted it gets impatient enough to start the "just checking on this" emails. Annette Young at the Montana Office of Public Instruction described the before-state exactly: if a document snagged in the process, it sometimes took days just to find out where the hold-up was.

Where it goes wrong

Two failure points show up over and over. The first is the out-of-office problem: the relay depends on every link being at their desk, so one absence stalls everything behind it, silently, with nothing prompting a backup. The second is the "where is it?" tax: because status isn't visible anywhere, answering that question becomes someone's recurring job, interrupting real work every time a submitter, an approver, or an auditor needs to know what happened to a request. Both failures share a root: the process exists, but nothing is carrying it except attention.

What doing it well actually requires

Turning a submission into a settled record without anyone shepherding it takes a handful of things the form builder never had.

The submission decides its own route

Where a request goes next depends on what's in it: a purchase over a set dollar amount picks up a second approver, a different building routes to a different administrator. The submitter never needs to know who their approver is; the form figures it out. How that routing knows who the approver is gets covered in depth in its own article.

Approvals happen in sequence, or in parallel, as the process requires

Some steps have to wait for the one before; some can happen at the same time. The chain matches the office's actual process, not a fixed template of one-approver-then-done.

Nothing is allowed to go quiet

Automated reminders go out when a step sits too long, and escalation rules move a request onward if an approver doesn't act within a set number of days, so an absence delays a step, not the whole process.

Approving doesn't require logging into anything

Approvers can act directly from the email notification, on a phone, which is where most approvals actually happen.

People outside the organization are part of the chain, not an exception to it

A parent or an employer receives a secure link by email and signs without creating an account, so the steps that leave the building don't fall out of the system when they do.

Status is visible, not asked about

Anyone with access can see exactly where a submission sits in the chain, which step it's on, and who it's waiting on, without emailing anybody.

It ends as a record, not a loose end

The completed submission lands in a searchable filing cabinet with a full audit trail: every action, by whom, timestamped. Answering "who approved this, and when?" eight months later is a lookup, not an investigation.

Common questions

Questions we hear before every build.

Can the person who submitted the form see where it is, or just the office staff?

Submitters can check status themselves, which is most of the point: the "just checking in on this" emails stop because the answer is visible instead of held by whoever handled the request last.

What happens if an approver is on leave or leaves the job entirely?

Escalation rules keep a request from waiting indefinitely on any one person, and routing follows the role rather than the individual, so whoever takes over the role becomes the approver without the workflow being rebuilt.

Does the submitter have to know who their approver is?

No. The routing determines that from what's in the submission. In offices where approval paths differ by building, department, or amount, that's the difference between a form people can just use and a form that generates its own questions.

What if a request needs to go back for a correction instead of being approved or denied?

A request can be sent back to the submitter with what needs fixing, and it re-enters the chain when corrected, documented like every other step, rather than the fix happening in a side email that never makes it into the record.

Where does the completed form actually end up?

In a searchable digital filing cabinet, along with every other submission of every form type, retrievable by anyone with permission to see it. Not an inbox, not a shared drive folder, and not dependent on how consistently people file things.

How Flow Forms handles it

Everything above is what a Flow Forms workflow does on its own once someone hits submit: the routing, the sequence, the reminders, the escalations, the outside signatures, the visible status, and the final record are all built into the workflow itself, matched to the office's actual process. Nobody's attention is what carries a request from submitted to settled. And when the process changes, the workflow changes with it, adjusted by the same team that built it.

See how it would work for your district or agency →