Analysing
Nothing counts until someone signs it off.
With approvals switched on, a submitted response waits for an approve or reject decision, with an optional comment, before it counts as complete. You can name an approver list per survey; if you do not, any editor in the organisation can decide. The person who decided and the moment they decided are recorded by the database from the authenticated session, not supplied by the browser — which is the difference between an audit trail and a claim.
Approvals are single-step only. One decision per response, with no chains, no delegation, no absence cover, no escalation and no automatic reminders. If your process needs a three-stage chain, better to know it on this page than in week three of an implementation.
How the state actually moves
A response arrives in a waiting state. It is a complete submission — every answer, every upload, every signature stored as it would be otherwise — but flagged as not yet decided. An approver opens it and approves or rejects it, with an optional comment either way. That is the whole state machine, and the shortness is deliberate: there is no "returned for amendment" and no re-submission loop that reopens the record for the respondent. A rejected response stays in place and stays readable inside the organisation.
The decision does not alter the data. The results view still counts the response in its per-question charts. Approval is a decision recorded against a submission, not a filter that hides one.
What gets written, and who writes it
Four things are stored against each decision. Two of them are the reason this feature exists.
Decision
Approved or rejected. There is no third state once a decision is made.
Decider
Taken from the authenticated session by the database, not from a field the browser sent.
Timestamp
Written server-side at the moment the decision lands, not read from the reviewer’s clock.
Comment
Optional on both approve and reject, stored with the decision and visible only inside the organisation.
Plenty of tools will tell you who approved something. The question worth asking a vendor is where that name came from. If the client sends the approver's identity with the decision, anyone able to call the endpoint can write any name and any time into the audit log.
Here the identity and timestamp are taken from the authenticated session by the database itself. A browser cannot offer them, so it cannot get them wrong. That is the same footing as the rest of the platform: row-level security throughout, organisation isolation pinned server-side, and rules such as the close date and response cap enforced by database triggers rather than by the interface.
The respondent never sees the decision
Approval state is invisible to the person who filled the form in. They submit, they get the thank-you screen, and that is the end of it. No status tracker, no automatic email telling them they were turned down.
This is a choice rather than an omission. A rejection is usually procedural — the wrong evidence attached, a request outside the scheme, a duplicate — and a bare automated "rejected" is a poor way to say that to a resident. Councils already have processes for delivering decisions, with the wording, the appeal route and the reference number that go with them. An internal sign-off queue should not quietly become an unregulated decision letter.
Where this fits in local government
The common shape is a form that is not really a survey: a small grants scheme, a pitch booking request, a change-of-circumstance notification, a licence variation. Something arrives, one officer looks at it, and it is either in or it is not. That single decision is the whole workflow, which is the case approvals are built for. More on sector fit is on the local government page.
Two things pair with it. File uploads, because these forms carry evidence — a quote, an invoice, a photograph — held in a private bucket and readable only by the organisation through short-lived signed URLs. And e-signatures, which store the mark, the method, the exact agreement text and a SHA-256 hash of that text, so changing the wording later changes the hash. A recorded decision on top of a hashed declaration gives you a record of who agreed to what and who approved it. Those are simple electronic signatures, not qualified ones, so whether that is sufficient evidence for a particular scheme is a question for whoever owns the scheme.
What approvals do not do
Four things fall outside the single-step limit, and they are worth naming.
- No chains. You cannot route a response to a team leader and then on to finance. One decision closes it.
- No delegation or absence cover. An approver cannot hand their queue to a colleague while they are away.
- No escalation and no reminders. Nothing chases an approver after three days. A waiting response waits.
- No conditional routing. Which questions a respondent sees can depend on earlier answers via conditional logic; who reviews the result cannot.
The reason is surface area. Chains, delegation, cover and escalation bring deadlines, out-of-office states, reassignment rules and a notification engine with them, and each is somewhere for a decision to get lost. One reviewer with approve, reject and a comment covers the common case and can be explained in a sentence. If you need a real chain, use a case management system for the workflow and this for the intake, or tell us what your chain looks like.
Getting the decision into your other systems
The timing matters. A webhook fires
when the response arrives — signed with HMAC-SHA256 in an
X-NumoForms-Signature header, using a per-webhook secret —
which is before anyone has reviewed anything. A system receiving that
payload is receiving an application, not an approved application, and
should treat it as one. Email notifications behave the same way. Neither
carries the decision, and neither does the
CSV export, which has a column per
question and no column for sign-off. The decision lives in the results
view, so today it travels to another system through the person who made
it.
Questions people ask about approvals
What is an approval step on a survey response?
An approval step holds a submitted response in a waiting state until someone approves or rejects it, with an optional comment. Until then it does not count as complete. The decision, the decider and the timestamp are written by the database from the authenticated session rather than supplied by the client.
Who is allowed to approve a response?
You can set a named approver list per survey. If you do not, any editor in the organisation can decide. There is no separate approver seat type — approvers are people who already have workspace access.
Does the respondent find out that their response was rejected?
No. Approval state is never shown to the respondent, who sees the normal thank-you screen on submitting. A rejection is an internal decision about the record, not a judgement delivered to the person, so you contact them yourself in whatever way suits the case.
Are multi-step approval chains supported?
No. Approvals are single-step only: one approve-or-reject decision per response. There are no sequential stages, no parallel sign-off, no delegation, no escalation and no automatic reminders. A process that needs a three-stage chain is not served by this today.
What happens if the only approver is on leave?
Nothing happens automatically — there is no delegation or out-of-office cover. Name more than one approver on the survey, or leave the approver list empty so that any editor in the organisation can decide.
Put a decision behind the form.
Turn approvals on and each submitted response waits for one approve or reject, with an optional comment, before it counts as complete. The decider and the timestamp are written by the database from the authenticated session, so the audit trail is not something the browser supplied.
- Single-step sign-off: approve or reject, with a comment
- Named approvers per survey, or any editor in the organisation
- Respondents never see the decision
