Resources / Government & Public Agencies / Approval workflow setup

Setting up an approval workflow in a public agency without starting a software project

The short answer

An approval workflow is a small enough thing to build that it does not require a platform evaluation, an implementation timeline, or anything installed on agency hardware. What it requires is scope: one process, defined end to end, with the people who sign it named and the order they sign in written down. An agency that starts there is having something built rather than deploying a system its technology office will own afterward, and the purchasing rules still apply to it. Doing it well means treating the first workflow as one named process with a known cost of running it by hand, built with the office in the room, on the systems the agency already has.

On this page

Why the fix looks bigger than the problem What the agency is being asked to supply What an agency is buying

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

Why the fix looks bigger than the problem

Most agencies already know exactly which approval is broken. Somebody named it out loud in a meeting, probably more than once. The reason nothing happened next is that the sentence after naming it was "that would mean new software," and everybody in the room quietly did the arithmetic on what that sets in motion. A request to the technology office. A budget line that does not exist until the next cycle. An evaluation, a demo schedule, a security conversation, a committee that meets monthly.

The fix is larger than the problem, so the problem stays, and the workaround stays with it: the folder on the shared drive, the reminder email somebody sends every Thursday, the person down the hall who always knows where a document actually is. That arithmetic is correct for enterprise software rollouts. It is not correct for a single built process, which is a different kind of thing to buy.

What the agency is being asked to supply

Almost nothing that resembles a project. The substantive input is the names of the approvers and the order they act in, along with a description of how the process runs today and what the exceptions look like. No requirements document. Nobody writes a specification. If an office can say who signs, in what order, and what happens when the second signer is out, it has supplied the hard part, and the reason that is the hard part is that most offices have never written it down.

The rest is a build the office watches happen, which is the mechanism that keeps this from becoming a project. There is no long gap between what an agency described and what it gets back, so there is nothing to discover late.

What an agency is buying

None of this removes an agency's purchasing rules, and it should not. What changes is the unit. Nothing here is priced by user seat or by feature tier, which means an office where three people sign off on one process is not being asked to fund access for everyone who might theoretically log in. The price attaches to the process itself: the form, the routing, the audit trail, and the work of building all three.

That distinction is what makes the number sizeable by the people who have to approve it. A platform license is a figure with nothing in the building to compare it against, which is why it goes to a committee. One named process has an obvious comparison sitting a few feet away: the hours that process currently consumes, the delay it currently causes, and the person whose week it currently interrupts.

The part worth settling first is scope. An agency that walks into a budget conversation asking for one named process, with the current cost of running it by hand already counted, is asking a question the finance office can actually answer this cycle.

What doing it well actually requires

Getting a first approval workflow live without opening a software project comes down to keeping the scope small enough to stay outside project machinery, and it has a few specific parts.

One process, chosen deliberately, not a category

Not "our approvals." One approval, the one people complain about, with a defined beginning and a defined end. Starting with one is the standard entry point rather than a reduced version of a real deployment, and it is how an office learns what its own process actually contains, which is usually less obvious than anyone expects.

An honest read on how long it takes, which depends on the process

A straightforward approval can be live the same day. Something genuinely complex takes a few sessions to get right, and the Montana Office of Public Instruction's requisitions workflow was the second kind. The variable is the intricacy of the process, not the size of the agency, and any answer given before the process has been described is a guess.

Nothing the technology office has to own afterward

No installation and no server to stand up. Staff work in a browser and approvers act from a notification. The systems already running stay where they are, and what gets built is the routing layer between them, which is the part none of those systems was designed to carry.

A before-state worth measuring, because it is what changes

Annette Young, a CSPD Specialist at OPI, described twenty years of moving from copy machines and file cabinets to digital forms, email, and internal hard drive storage. In her words, that second era was extremely time intensive, and a document snagged somewhere in the chain could take days to locate. What replaced it was OPI's own requisition process, built into a workflow that shows its own status: initial data entry takes minutes rather than an hour or more, and you can open a window and see where a project sits in the queue.

A go-live date rather than an implementation season

The OPI system was available to the agency the week of Valentine's Day, which is a level of precision that describes a date rather than a phase. Enly Kovis, a Research Analyst in OPI School Finance, put the expectation from a second department this way: with Flow Forms, the agency would become a beacon of efficiency. In Montgomery County, Kansas, the same shape of start produced a routed chain across the Appraiser's office, the Clerk's office, and the Treasurer, with a fourth department now scoping its own.

Somebody who stays after it is live

Processes change. A signer retires, a step gets added, the state changes a requirement in March. An approval workflow that cannot be changed without a support ticket and a queue is a workflow that will be quietly abandoned within a year.

Common questions

Questions we hear from public agency offices.

Does our technology office have to be involved?

Not to make it work. There is nothing to install, nothing to host, and no server to stand up. Staff use a browser and approvers act from a notification. Most agencies do bring their technology office into the conversation at some point, which is reasonable, but the conversation is about accounts and access rather than about a deployment they will be responsible for.

We are one office, not the whole agency. Is a single process too small to start with?

One process is the normal starting point, not a trial version of a real engagement. It is also the sensible one: an office that builds its worst approval first learns what its own process actually contains, and that knowledge is what makes the second and third builds fast. Agencies that start narrow tend to expand department by department, which is a different and easier conversation than buying agency-wide on day one.

What happens when the process changes after it is built?

Someone changes it. That is the part most software gets wrong for public agencies, where processes change because a statute changed, a position was reorganized, or a new director wants a second signature added. Changes are made by the team that built it, not filed as a request and queued.

Do we have to replace the systems we already use?

No. The finance system, the records system, and whatever else the agency already runs stay where they are. What is being built is the routing and approval layer between them, which is generally the work those systems were never designed to carry, and the reason the process is currently running on email in the first place.

How do we describe this internally so it does not get treated as an IT purchase?

Describe the process, not the software. Name the approval, name who signs it, name what it currently costs in staff time and delay, and name what you want it to do instead. A request framed as one process being rebuilt gets evaluated on whether that process is worth fixing. A request framed as a new system gets evaluated against every other system the agency owns, which is a much longer conversation and a different committee.

How Flow Forms handles it

Flow Forms builds the process with the office watching it happen, on a call rather than across a project, and the agency supplies who signs and in what order rather than a specification. The systems already in place stay in place. The same team that builds the chain stays on to change it when a statute, a position, or a director changes the process, which is what determines whether an approval workflow is still running two years later.

See what your first process would look like →