Filling forms from the portal
Clients open Forms to fill on their portal case view, answer the question fields (pre-filled with case data they may see), and submit. Answers write into the case and the team is notified in-app.
Forms are how clients contribute data without ever touching the dashboard. A worker exposes one or more form templates to a specific client on a specific case — either by ticking them in the Forms to fill picker when adding the client, or any time later via Manage forms in the client's ⋯ menu (see Per-case collaborators for both flows). This article covers what happens from there: the client's side of the fill, and what lands on the case for the team.
What the client sees
On the client's case view at /portal, exposed forms appear in a Forms to fill section above the rest of the case. Each form is a card showing its name and a status: Open for forms not yet submitted, Submitted for ones already done. The section only renders when at least one form is exposed to this client on this case.
Clicking Open expands the form inline — no separate page. The client answers the questions and clicks Submit; a Cancel button backs out without saving. Required questions are marked, and the form won't submit until they're answered (the server enforces the same rule).
What a form asks
A form presents the template's question inputs — the fields a worker configured with the Question value source in the template editor. Each question input becomes one entry in the form, carrying its label, placeholder, help text, and required flag. Fields the template extracts from documents or sets statically never appear; the client only sees what was explicitly written as a question.
Answers are pre-filled from the case's existing values when the client is allowed to see them — so a client re-confirming details sees what's already on file rather than a blank form.
Where submissions land
Submitting does three things on the case, atomically from the team's point of view:
- Case fields update. Each answer writes to the case data field its question is keyed to — the same fields workers see in the dashboard case detail. Blank answers are skipped, so an unanswered optional question never erases an existing value.
- The activity timeline gets a
form_submissionentry. Workers see a row attributed to the client's email reading "Filled" plus the form's name, with an expandable View N answers list showing every submitted value. Each updated field's provenance also links back to this entry. - The case team is notified in-app. Workspace members get a bell-icon notification about the submission. No email goes out for form submissions — see How notifications work.
Submitting again, or fixing a mistake
Each client gets one submission per form: after submitting, the card flips to Submitted and can no longer be opened by that client. There's no portal-side edit-after-submit. Two consequences worth knowing:
- Mid-fill progress isn't saved. Clicking
Cancelor leaving the page discards the answers — encourage clients to finish in one sitting. - Corrections happen on the dashboard. If a submitted value is wrong, a worker edits the case field directly; the original submission stays on the timeline as the record of what the client sent.
The once-per-form rule is per client, not per case — if two clients on the same case are exposed to the same form, each can submit it, and later answers overwrite the same case fields.
Visibility still applies
Forms don't widen what a client can see. The portal filters case fields through the workspace's per-audience visibility rules (fields default to hidden from clients unless explicitly made visible) plus any per-collaborator scope, and files through category visibility. Pre-filled answers draw only from that filtered set — a question keyed to a field the client can't see simply starts blank. The full scoping model is in The collaborator portal.