Skip to main content

Routing documents for sign-off across departments

Flow Forms · Government and public agency operations

The short answer

A document that needs sign-off from more than one department does not usually stall inside a department. It stalls in the handoff between them, at the moment when one office has finished its part and the next office does not yet know there is anything waiting. Email hides that moment completely: a sent message looks identical whether it was acted on an hour later or never opened at all. Doing it well means the sequence is defined once rather than re-created per document, each office is notified when the work becomes theirs, a step that stalls can be moved rather than waited on, and the record of who acted and when builds itself as the document travels instead of being reconstructed afterward.

Why the handoff is where things stop

Inside a single office, a stalled document is visible. Somebody walks past the desk. The person waiting on it is ten feet from the person holding it, and the social cost of sitting on something is immediate.

Across departments, none of that applies. The person waiting cannot see the queue, does not know whether anyone has picked it up, and often does not know which individual in the other office is supposed to act. So they wait a respectable interval and then send the email that everyone in a public agency has written: just checking on the status of the transfer paperwork I sent over last week. That email is not a communication problem. It is a system asking a human being to perform a lookup it should have been able to answer itself.

The compounding version is worse. When the chain is three offices long, the second office frequently does not know whether the delay is upstream or downstream of them, so the checking-in email goes both directions, and two departments spend the morning establishing a fact the process should have held.

What email is actually doing in the chain

It is worth being precise about this, because email is not a failure. It is the only tool everybody in every department already has, which is exactly why the work migrated there. What email cannot do is keep track of the process itself.

An email thread does not know it is step two of four. It does not know that the next action belongs to Payroll rather than to whoever happens to reply. It does not know that the person it was sent to has been out since Thursday. And it does not know that the version attached to the third message is not the version the first approver actually saw. Every one of those facts has to be supplied by a person, which is why cross-department approval by email quietly converts into one staff member's job of remembering things on behalf of several departments.

What doing it well actually requires

Cross-department sign-off works when the sequence itself is a defined object rather than a series of individual decisions to forward something, and that comes down to a few specific parts.

  • The order is defined once, and every document follows it

    The sequence is built into the process rather than assembled per document. In Montgomery County, Kansas, the chain runs from the Appraiser's office to the Clerk's office and ends with the Treasurer, in that order, every time. Nobody re-decides who is next, and no document skips a step because the person sending it was in a hurry.

  • Each office is notified when the work becomes theirs, not before

    An office does not need to watch for arrivals or check a shared folder. The step arrives when the prior step completes, which is also the moment the waiting starts being measurable. At the Montana Office of Public Instruction, Annette Young, a CSPD Specialist, described the effect on exactly this seam: moving from one OPI department to the next to task completion now takes a fraction of the time.

  • A stalled step can be moved rather than waited on

    An approver who is out of office can reassign their step to another person so the chain keeps moving. This matters more than it sounds like it should, because the single most common cause of a multi-department delay is not disagreement or workload. It is one person being away, and no mechanism existing to route around them without starting the whole thing over.

  • The path can change based on what the request actually is

    Not every request through the same departments deserves the same path. The City of Apopka, Florida runs personnel actions through a single form whose routing branches on the type of action, so a new hire who needs system accounts and access set up follows a different path than a straightforward pay adjustment, without asking the submitter to choose correctly.

  • Nobody in the chain has to know who comes next

    The routing determines the approver from rules set when the process was built. The submitter does not need to know the chain, which matters most in exactly the situation that breaks email chains: a new employee, a reorganized department, or a position that changed hands last month.

  • The record accumulates as the document moves

    Every submission carries a chronological history: who acted, what they did, and when, to the minute. It is a byproduct of the routing rather than a separate documentation task, which is the only version that survives contact with a busy office. A submission also stays bound to the process definition that was live when it was submitted, so a later change to a step does not rewrite what an earlier approver was actually looking at.

  • Each department keeps its own systems

    Nothing about a shared chain requires a shared system of record. The finance office keeps its finance system, the clerk keeps the records system, and what crosses between them is the document and its history. A chain that requires every department to adopt one platform is a chain that stops at the first department that says no.

Common questions

Questions we hear from agency and district offices.

What happens when an approver is out of office and the document is sitting on their step?
They can reassign the step to someone else, and the chain continues from there. The step does not have to be restarted, and the reassignment is part of the record rather than an untracked favor. This is the failure mode worth designing for, because absence is far more common than disagreement as a cause of multi-department delay, and it is the one email handles worst: a message sitting in an inbox nobody else can see looks exactly like a message being worked on.
Can two different requests take different paths through the same departments?
Yes, and most real processes need that. The path branches on the content of the request, so a request that requires an extra review picks it up automatically and one that does not skips it, without anyone at the front of the chain having to know which case they are in. The branching is defined once, when the process is built, and applies every time rather than when someone remembers.
Does every department have to be using the same system for this to work?
No, and requiring it is usually what kills cross-department projects. Each office keeps whatever it already runs. What is shared is the routed process and its record, not a system of record. Steps that touch people outside the organization entirely can be sent as a link rather than requiring an account.
How do we know where a document is right now without asking?
The status is a lookup rather than a question. Any submission shows which step it is on, who it is waiting on, and how long it has been there, which changes the nature of the follow-up conversation: instead of asking whether anything ever happened to it, the office already knows it has been sitting on Payroll's step since Tuesday. That is a materially different conversation to have with another department.
Is the record enough if someone questions the approval later?
The routing produces a timestamped history of who acted and when, captured as it happened. Whether that record satisfies a specific audit, dispute, or public records request is a separate question with its own answer, and worth reading about on its own terms rather than assumed.

How Flow Forms handles it

Flow Forms builds the chain as the organization actually runs it: the sequence defined once, each office notified when the step becomes theirs, branching where the request type calls for it, reassignment when someone is out, and a history that accumulates as the document moves. Each department keeps the systems it already uses. The same team that builds the chain stays on to change it when a step, a position, or a policy changes, which is what keeps a cross-department process from drifting back into email.

See how it would work across your offices →

Related