Digital forms: when collecting data should not end in an inbox

Most "digital" forms are paper in a different wrapper. When somebody at the far end retypes the values from a PDF into a system, the work has not disappeared — it has moved.

You know the loop: a form to download, fill in inside a PDF reader, print, sign, scan, email. On the other side sits a person who opens it and copies it into the register. Every step is a chance for a typo, and every typo is found a week later.

What makes a form digital

Not that it is on a screen. That its output is a data record a system accepts without a human touching it.

The rest follows: the form has to know which values are permissible, where to send them, and what happens when the receiving side rejects them. A PDF can do none of the three.

Validation belongs on the server

A check in the browser is a convenience for the user — it reports a mistake before they submit. It is not protection. Anything running in a browser can be bypassed, so every rule has to hold a second time on the server.

And more than format is being checked:

• Shape and range. A date is a date, an amount is positive, a company number has the right length.
• Relationships between fields. An end date must not precede a start date. Rules like this are not checked at all when someone retypes from paper.
• Authorisation. The sender may only file on behalf of the entity they named — otherwise changing one number files something on somebody else's behalf.
• Attachments. File type is verified from content rather than extension, and size has a ceiling.

Approval is part of the form, not an extra email

For most processes, submitting is not the end. Someone approves, someone returns it for completion, someone rejects it with a reason. When that runs on forwarded email, the state of a submission exists only in somebody's head, and "where is it stuck?" cannot be answered without a search.

When the form has states, the answer is immediate — and you also get a record of who approved what and when. Which, incidentally, is what an auditor asks to see.

What the sender gets out of it

Honestly: forms are usually introduced to save effort on the receiving side. But the person filling one in gets something from a well-made form too:

• Values the system already knows about them do not have to be entered again.
• Mistakes surface immediately, not two weeks later in a letter.
• They can see what state their submission is in.
• They get a receipt — with a time and an identifier, not just "sent".

A form that ignores this gets worked around. People pick up the phone instead, and the work returns to where it was supposed to disappear from.

How we build them

We design forms for official electronic communication as well as for internal and web applications. Three things carry the weight: server-side validation, an approval path with states people understand, and a direct link into the system that uses the data next — the same integration work any other data transfer would need.

If you have a process that runs on PDFs and email today, write to us. From a description of what gets retyped by hand we can say what could disappear entirely.