Validate the public form before the clerk inherits the mess
The resident hit submit. Required fields were empty in the payload. The portal showed a green check. Three days later a clerk is calling about a blank address line.

Public-sector portals that celebrate submit without server-side validation hand incomplete cases to clerks. Validate on the server, show field-level errors before the case id exists, and never treat a client-only check as the gate.
Walk the happy path that is not happy
Open your own portal as a resident. Fill the easy fields. Leave the required address line 2 empty if your UI marks it optional-looking, or disable JavaScript and post anyway. Hit submit.
If you get a confirmation number and a green banner while the case record has nulls the clerk needs, you do not have a form—you have a drop box with a receipt printer. A green check on a blank required field is not a successful filing—it is a future phone call.
Step 1: Decide what "required" means for the clerk
Sit with the person who opens the queue. List the fields they cannot process without. That list—not the designer's guess—is required. Optional-for-marketing is different from optional-for-processing.
Document each required field with: why the clerk needs it, the error message in plain language, and whether an upload can substitute (for example a deed PDF instead of a typed parcel id).
Step 2: Validate on the server before case create. Client-side checks are a courtesy for fast feedback. They are not the gate. Every submit path—browser, mobile web, accessibility tools, future agent clients—must hit the same server rules before a case id is minted.
Return field-level errors. A single toast that says "something went wrong" trains residents to call. Name the field. Say what format you need. Keep their other inputs.
If you must create a draft case for save-and-resume, label it draft in every clerk view and exclude it from SLA clocks until the resident completes required fields. Drafts that look like filings are how queues fill with ghosts.
How the work moves
Submit path that protects the clerk
- Clerk list
Name fields required to process—not just to look complete.
- Server rules
Same validation for every client before case id exists.
- Field errors
Plain-language messages; preserve other inputs.
- Hostile tests
No-JS, big files, double submit, expired session.
- Missing-info path
Deep link back to incomplete fields with SLA clarity.
A green check on a blank required field is not a successful filing—it is a future phone call.
Step 3: Test the hostile paths
Before launch (and after every form change), run:
- Submit with JavaScript off
- Submit with required file missing
- Submit with file over size / wrong type
- Double-click submit (idempotency—one case, not three)
- Session expiry mid-form (restore without blanking silently)
- Partial paste from a PDF that includes hidden characters in phone or zip
Log which checks failed in staging. If staging only tests the sunny path with a perfect persona, you will discover blanks in production on Monday morning.
Decision guide
Client-only check vs server gate
| Consideration | Client-only validation | Server validation before case create |
|---|---|---|
| Bypass | Trivial with no-JS or crafted POST. | Every path hits the same rules. |
| Clerk view | Confirmed cases with nulls. | Filings arrive complete or stay draft. |
| Resident UX | Surprise phone call days later. | Immediate field-level fix. |
| SLA | Clock starts on junk. | Clock starts when required fields exist. |
Step 4: Close the loop when something still slips
Incomplete filings will happen—migrations, new programs, mixed paper intake. Give clerks a one-click "request missing info" that emails the resident a deep link to the incomplete fields, not a generic "contact us." Track how often each field triggers that path; high frequency means your validation or labeling is wrong.
Accessibility matters here. Error summaries at the top of the form with links to each field help screen-reader users more than red outlines alone. Keep error text specific: "Enter a 5-digit ZIP" beats "Invalid input."
Multilingual portals need validated messages in every supported language before launch—not English-only errors under a Spanish UI. Incomplete translation is how residents abandon filings and call the clerk anyway.
Paper intake that gets keyed later should use the same required-field rules. A clerk typing a paper form should hit the same blockers, or you will recreate blank digital cases by hand.
Save-and-resume without lying
Residents start forms on phones in parking lots and finish on laptops at home. Save-and-resume is kindness—unless a draft is indistinguishable from a submitted filing in the clerk queue. Use explicit states: draft, submitted, needs info, in review, closed. Show the resident the same state words the clerk sees.
When you migrate from a PDF mail-in process, do not recreate the PDF as a single file upload with no field validation. That pattern rebuilds the clerk as a human OCR engine. Extract the fields that matter; validate them; attach the PDF as supporting evidence only.
Audit bots and agents will eventually POST to the same endpoints residents use. Server validation is how you stay ready without a special "human only" fantasy.
Measure clerk callbacks tagged "missing information" per form version. Ship a validation fix, wait a week, and look for the tag to drop. If it does not drop, your required list still does not match clerk reality—or residents cannot understand the error text.
For appointments and licensing portals, validate date logic too: no past dates where future is required, no Tuesday slots when the desk is closed. Format-only validation leaves schedule nonsense for humans to unwind.
When a third-party identity or payments widget sits inside the form, validate your fields before you hand off, and again when you return. Residents who bounce from a bank widget back to a cleared form will abandon or call. Preserve state across the handoff like you would for any checkout.
Publish a short "why we ask" note beside sensitive fields (SSN fragments, medical, immigration). Clarity reduces garbage data better than another red asterisk. Clerks inherit whatever fear or confusion the form created.
Train clerks to bounce incomplete paper with the same field list the portal uses. Dual standards recreate the phone queue. If a field is required digitally, it is required on paper—or you consciously waive it with a documented exception code the analytics can see.
After each program launch, sit with two clerks for an hour and watch them open new cases. The curses you hear are a better requirements list than the workshop slide deck. Fix those fields next.
If your portal vendor swears client-side validation is enough, ask them to show the server rules in writing. If they cannot, you do not have a filing system—you have a browser suggestion. Put the acceptance test in the contract: no case id without required fields.
Add monitoring for submit responses that return 200 with a case id while required fields are null in the database—those are silent corruptions, not user errors. Page on that signal the way you page on 500s.
Put this into practice
Pick your highest-volume public form. Export last month's cases with nulls in clerk-required fields. That count is your defect backlog. Fix server validation for the top three fields before you add another program to the same portal shell.
We build government and public sector services where submit means the clerk can act. If your green check keeps shipping blank address lines—talk to us.
Related work: Wellthie.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.