Forms approval: turning submissions into decisions without a queue

Forms approval is what happens after someone hits submit: a request for leave, a purchase, access to a system, a new supplier. The form is the cheap part. The expensive part is that a submission with no owner and no deadline sits in an inbox until the person who asked gives up and messages someone directly — which is exactly the behaviour the form was meant to replace.

So design the approval before the fields. A request type is worth a form only if you can say who decides it, within how long, and how the requester learns the answer. If you cannot answer those three, you are building a collection point, not a process.

What a forms approval process needs

• One named decider per request type, by role. Two deciders means each waits for the other.
• A stated turnaround — two working days for most internal requests — published on the form itself so expectations are set before submission.
• Enough fields to decide without a follow-up. Every missing field costs a round trip and doubles the elapsed time.
• A decision vocabulary of three: approved, declined, needs more information. Anything richer becomes ambiguous in practice.
• A reason attached to declines. Unexplained refusals generate appeals, and appeals cost more than the explanation would have.
• A visible status for the requester, so "has anyone looked at this?" never has to be asked.
• A retention rule, because approvals for access, spend and leave are exactly what an audit asks about.

Ask for the decision criteria at the same time you ask for the fields. If the approver's real question is "does this fit the quarter's budget", the form should ask for the cost centre and the amount — not for a paragraph of justification the approver will not read.

Running the queue

1. Triage on a fixed rhythm — once a day is enough for most request types, and predictable beats fast.
2. Decide in the order received, except where a stated priority rule applies. Ad hoc reordering is how the polite requesters end up waiting longest.
3. For anything you cannot decide, use "needs more information" with the specific question, and put the request back on the requester's side of the fence with a clock.
4. Record the decision against the submission itself, not in a reply that only two people can see.
5. Close the loop with the requester in the same message where you record the decision.
6. Review weekly: how many are open, how old is the oldest, which request types generate the most follow-up questions.
7. Fix the form when a question recurs. A recurring clarification is a missing field, not a communication problem.

Why forms approval beats approval by email

Email approvals fail in three predictable ways. The request lands in one person's inbox, so when they are away nothing moves. The thread forks, so two people approve slightly different versions of the ask. And the record is scattered across mailboxes, so the answer to "who approved this and when" depends on who still has the thread. A form with a shared inbox fixes all three, and does it without asking anyone to learn a process — the requester fills in fields, which they already know how to do.

The trade is that a form is rigid: it collects what you asked for and nothing else. That is usually an advantage, but leave a free-text field for context, because the one request in twenty that does not fit the fields is often the one that matters.

Doing it in Ettex

In Ettex Forms, a request form takes the fields above — including file uploads for quotes or supporting documents — and every submission lands in one searchable, timestamped inbox with a live summary of what has come in and export to CSV or XLS when finance wants the quarter. Because the inbox is shared rather than personal, cover during holidays is a question of who opens it, not of who has access to whose mail. The policy behind the form belongs in Ettex Docs, and anything that ends in a binding commitment — a supplier agreement approved through the form — goes on to Ettex Signature.

The honest limitation: Ettex Forms does not route submissions automatically to different approvers based on the answers, and it does not send an approval reminder on a schedule. Forms approval here is a shared inbox worked on a rhythm, with the decision recorded against the submission. For a team where one or two people decide each request type that is enough; conditional routing across many approvers needs a dedicated workflow tool.

Signals your forms approval is failing

• People message the approver directly instead of submitting. The form is slower than the workaround.
• The oldest open request is measured in weeks, which means nobody owns the queue.
• The same clarification is asked on most submissions — a field is missing.
• Declines are appealed often, which usually means the criteria were never published.
• Two approvers give different answers to similar requests, which means the rule lives in their heads.
• Nobody can produce last quarter's approvals when asked, which means the record was never the system.

Forms approval is a promise that submitting is better than asking. Name one decider, publish a turnaround, work the queue on a rhythm and record the decision where the request lives — and the form stops being a place where requests go to wait.