How does approval routing know who the approver is?
Flow Forms · Built around your process
The short answer
When someone submits a form, the routing determines who needs to approve it from rules set up when the workflow was built: what role approves this kind of request, whether anything in the submission changes the path, and what order the steps happen in. The person submitting doesn't have to know any of that. They fill out the form, and it goes where it's supposed to go, because the knowledge of who approves what lives in the workflow itself instead of in the submitter's head. That's the difference between approval routing and forwarding: forwarding means every submission depends on someone knowing the process, and routing means the process is the thing that knows.
Why the existing system doesn't cover it
Form tools collect responses; they don't hold a map of the organization. There's no place in a basic form builder to record that purchase requests go to the business manager, that requests over a certain amount also need the superintendent, or that a different building has a different principal approving. At most, a submission triggers a notification to one fixed email address, which means someone at that address becomes the router, reading each submission and deciding where it goes next. The organizational knowledge that makes approvals work, who approves what, in what order, with what exceptions, stays where it's always been: in people.
How districts and agencies handle it now
The submitter is usually the router. The form or the email template comes with instructions: send this to your principal, then business office, unless it's over the threshold, in which case add the superintendent. Every person submitting has to know the chain, or guess at it, or ask. New staff get it wrong for a semester. When the process has exceptions, the exceptions live in a paragraph of instructions nobody reads, so requests regularly arrive at the wrong desk and get bounced backward. And when the chain changes, updating it means updating every person's understanding of it, one correction at a time.
Where it goes wrong
Two moments expose it. The first is the wrong-path discovery: a request travels its whole chain, gets to the end, and only then does someone notice it needed a second signature it never got, so it starts over, with the delay compounding at each re-step. The second is turnover: the routing knowledge was in the person who left, and their replacement inherits a job where who-approves-what is folklore, reconstructed from old emails and asking around. A process that lives in people's heads is only ever one retirement away from not existing.
What doing it well actually requires
Real routing means the workflow holds the organization's approval map, and that comes down to a few specific things.
Approvers are roles, not names
The routing sends a request to whoever holds the role, the business manager, the building principal, not to a hardcoded individual. When someone leaves, whoever fills the role becomes the approver, and the workflow doesn't get rebuilt; nothing changes except who holds the role.
The submission itself can change the path
Conditional routing reads what was entered and adjusts: a request over a set dollar amount picks up a second approver, a different building routes to that building's administrator, a different request type follows a different chain entirely. The exceptions that used to live in a paragraph of instructions become rules the workflow enforces on its own.
Order is part of the routing, not a suggestion
Steps that must happen in sequence happen in sequence; steps that can happen at the same time run in parallel. The chain built into the workflow is the office's actual chain, which is exactly what gets established when the workflow is built live in the working meeting, so approvals happen in the order the process requires rather than the order emails get answered.
A stalled request is the workflow's problem, not the submitter's
If an approver doesn't act within a set number of days, escalation rules move the request onward instead of letting it sit. An absence delays a step, not the process, and it's the workflow's job to notice, not anyone else's.
The submitter never needs the map
All of the above means the person filling out the form needs to know exactly nothing about who approves it. They submit; the routing does the rest. In an office where the approval path differs by building, amount, and request type, that's the difference between a form anyone can use and a form that generates its own support questions.
Common questions
Questions we hear before every build.
- Who decides the routing rules in the first place?
- The office does, in the working meeting where the workflow gets built. The rules come from a conversation about how the process actually works, who approves what, what the exceptions are, and get built into the workflow right there, live on the video call.
- What happens when our approval chain changes, say a new position gets added between two steps?
- The routing gets updated to match, by the same people who built it, and every submission after that follows the new chain. Nothing about the change depends on staff re-learning the process, because the process was never in their heads to begin with.
- Can one form route completely differently depending on what's in it?
- Yes. That's conditional routing doing its normal job: the same request form can send a small purchase down a two-step path and a large one down a four-step path, without the submitter doing anything differently.
- What if two different people need to approve at the same stage?
- Chains can run steps in parallel where the process allows it, so two approvals that don't depend on each other happen simultaneously instead of one waiting behind the other.
- Does the approver have to go look for requests waiting on them?
- No. Approvers get notified when a request reaches them and can act directly from the notification, and reminders follow if it sits. The request finds the approver, not the other way around.
How Flow Forms handles it
Everything above is what routing means in a Flow Forms workflow: roles instead of names, conditions read from the submission, sequence and parallel steps matched to the office's real chain, and escalation when something sits. The rules get built live in the same working meeting as the form itself, from the office's own description of its process, and the same team adjusts them whenever the process changes. The map of who approves what finally lives somewhere that doesn't retire.