How districts and agencies get a workflow no vendor sells
Flow Forms · Built around your process
The short answer
When a school district or government office needs a workflow that doesn't match any off-the-shelf software category, from a homeschool intent registry to a multi-department county approval chain, the process gets built directly around the organization's actual steps rather than the organization reshaping its process to fit a generic tool. That build starts with a real conversation about how the process currently works, not a form template or a settings menu. No in-house developer or formal IT project is required to get there. A process that has never existed as a product before is the starting point for a build, not a reason it can't be done digitally.
Why the existing system doesn't cover it
Off-the-shelf workflow and form tools are built around a generic version of a process, whichever process that is. Some of what a school district or government office needs doesn't exist as a category anywhere, a homeschool intent registry, an educator licensure registry, so there's no template to start from at all. But just as often the process is a completely ordinary one: a personnel action, a leave request, a routing chain through three county offices. The tool has a template for that. What it doesn't have is the organization's own specific protocol, the exact sequence, the exact conditions that change who approves what, the exact steps that make it this district's version of the process rather than a generic one. Whether the category is brand new or completely common, the gap is the same: the tool assumes one shape fits every organization's version of it, and it doesn't.
How districts and agencies handle it now
Without that option, most organizations combine whatever they already have. A request moves by email, gets logged in a shared spreadsheet or a paper file, and travels from one office to the next by hand. Annette Young at the Montana Office of Public Instruction described exactly this combination before Flow Forms: a mix of digital forms, email, and files kept on an internal hard drive, workable but slow enough that a document could sit stuck in the process for days before anyone could say where the hold-up actually was.
Where it goes wrong
This goes wrong two different ways, depending on which gap it is. When the process is genuinely new, most organizations don't force it into the wrong tool, they just don't attempt it digitally at all, it stays as ad hoc as it started. When the process is a common one, a more familiar failure shows up instead: a tool gets adopted, but it enforces its own generic shape rather than the organization's actual protocol, so the steps get skipped under pressure, or two people end up following two different versions of "the process," and nobody can say which one is actually the rule. Lois Lopez, HR Generalist at Belgrade School District, described the shift once protocol actually got enforced: "Flow Forms requires everyone to follow protocol, this affects accountability." Either way, the tell is the same: a process that technically has a tool behind it, but nobody would call it settled.
What doing it well actually requires
Building around a real process instead of a generic template takes a few specific things, and the build stories on record show each one in practice.
The build starts from what doesn't exist yet, not from a form library
Gallatin County Superintendent of Schools needed to move homeschool intent registration and educator licensure online, neither of which existed as a workflow product anywhere. Both got built from scratch, described in the county's own words as something that "had not been done before."
It follows the actual chain, not a simplified version of it
Montgomery County, Kansas routes nine separate form types through a sequence that starts at the Appraiser's office, passes through the Clerk's office, and ends with the Treasurer, an order dictated by how county government actually processes property and records, not by what a generic form builder assumes a chain looks like.
It reaches whoever is actually doing the work, not just the organization that bought it
School Bus Incorporated, the transportation contractor school districts hire, runs its own driver time-off requests through the same build, alongside a student incident report built directly for one of its district partners. The build follows the relationship, not the org chart.
It deepens instead of staying fixed at delivery
The Montana Office of Public Instruction started with requisitions and has since expanded into broader managed services. Some of what OPI processes now lives in the system as the actual record, not a form that hands off to somewhere else once it's signed.
It keeps adjusting after launch, not just responding to the original build request
Big Horn County School District #1 and Harlowton Public Schools, independently, describe the same thing: forms that keep getting tuned as needs change, not a one-time delivery that's done once it ships.
It's precise enough to change how long the process actually takes, not just how it feels
The City of Apopka, Florida used to route a Personnel Action Request through a chain of emailed PDF forms, a process that took 10 to 12 business days and left nobody able to say where a stuck request actually was. Once the routing logic branched by the type of action, a pay adjustment following a different path than a new hire, which needs added IT and security steps, the same process took 2 to 3 days.
Common questions
Questions we hear before every build.
- Does this only work for large districts, or can a small office get a custom build too?
- Some of the strongest build stories on record come from small offices, a single county superintendent's office, a single transportation contractor. The build scales to the process, not to the size of the staff running it.
- Does this work for a large state agency or a bigger city government, or is it really built for smaller offices?
- State agencies and larger city governments already run through this model, and the way it happens is the more honest picture than a flat yes or no. Montana's Office of Public Instruction started with one requisitions workflow and has since expanded into broader managed services across departments. Montgomery County, Kansas started with a handful of forms in one office and is now on nine forms spanning three departments, with a fourth in active scoping. City government scales the same way too, the City of Apopka, Florida runs its Personnel Action Request workflow through the same model. The size of the organization changes how many workflows there eventually are, not whether the model works.
- What happens if our process changes after the build is live?
- The build changes with it. A process that only gets built once, at the moment it launches, isn't actually built around the organization's real process, it's built around a snapshot of it.
- If we already run some workflows through another platform, does everything have to move over at once, or can a new build run alongside what we have?
- No. A new build addresses the specific process it was built for. Whatever else is already working stays exactly where it is.
- How long before something that's never existed as a workflow before is actually ready to use?
- Long enough to build it properly, not a fixed rollout timeline. There's no six-month IT project here, the build happens around the organization's actual process, and it's ready when that process is actually captured, not on a preset schedule.
How Flow Forms handles it
Flow Forms builds directly around whatever process is actually happening, whether that's a form that's never existed before or a routing chain unique to one office, and stays involved after it's live to keep adjusting it as the process changes. Nothing about the model depends on the organization being a school district specifically. A county office, a state agency, or a contractor working alongside a district gets the same build, done the same way.