Cases & case data
A case is one durable unit of work that holds files, extracted data, history, and generated outputs; each template field writes its value into the case under a stable key, so renaming a field or column later never disturbs the data already saved.
Filling one form is The Filler: you upload a document, autofill stamps it, you download the PDF, done. The moment you need to keep that work, or reuse the values it captured, a single fill stops being enough. That is where a case comes in, and it is the heart of the Pro chapter, The Operation: instead of a template just painting a PDF and forgetting, the template molds a case: every field it fills writes a value into a record that sticks around. (Free and Lite hit an upgrade preview here; the full dashboard pipeline is Pro.)
A case is the record
A case is one durable unit of work: an invoice, a permit, a contract. It is the instance of a workspace's blueprint, and it gathers everything that happens to that work in one place: the Files that arrived (Received) and that you produced (Generated), the Case data extracted or entered, the Activity history of notes and submissions and generations, the Outputs that were assembled, and the Team/Clients who can see it.
Every case carries one identifier that is unique within its workspace (for example an Invoice Number), set by giving a template field the ID type. The identifier is how files route to the right case: when a new document ingests and extraction reads an identifier that already exists, the file merges into that case; an unclaimed identifier starts a new one. Because cases are scoped to a single workspace, two workspaces can safely reuse the same identifier value. Cases are durable: finished ones move to Archived rather than disappearing.
Most cases are created for you, the instant a file ingests from Gmail, Drive, or a manual upload. You can also make one by hand with + Create New, which opens a blank draft in your browser: set a Case ID (auto-generated if you leave it blank), add one-off key/value fields via + Add field, then Create case (or upload a file, which auto-saves and attaches). Nothing reaches the workspace until you save; untouched drafts vanish, edited ones prompt "Discard new case?" on leave. Editing a saved case works the same way: leaving with unsaved edits prompts "Discard unsaved changes?", and a hard refresh triggers the browser's "Leave site?" warning. When a later extraction surfaces an identifier that differs from the current Case ID, a Use as case ID action in the case's Documents section re-points the case to that value in one tap. To create many cases from a roster at once, drop a CSV, XLSX, or DOCX roster into the AI chat assistant and it builds them.
Fields write to stable keys
The connection between a template and a case is the key. Each field's output writes its value into case.data under a stable internal key, not under its display name. This split is what makes the whole system safe to evolve: the key is the wiring, the name is just a label. Rename a field, relabel a dashboard column, change how it reads in prose, and the value already saved on every old case stays exactly where it is, still reachable under the same key. Names are display-only; keys never move on a rename.
That stability is also why a field can build on values that already exist within the same case. A fromCaseData field reads another field's saved value, by key, and uses it to fill or derive its own. A computed expression can sum a column. A prompt field can take an extracted date and turn it into "days remaining." All of this reads from the one case it lives on.
Case data groups by where each value came from: User Input (form-question fields, sticky, never overwritten), Extracted (AI-populated from source files), Computed (read-only, derived at read time from an expression over other fields), and Static (fixed at design time, plus system or company-profile bindings like today's date that resolve at read time). Editing an Extracted field keeps it in that bucket with an "edited" marker, a history popover showing the diff, and a sticky override so the next extraction skips it; the reset (↺) button clears the override so a future run can repopulate it.
Value types
A field's value type decides more than how it validates: it also decides which dashboard views the case can appear in (address feeds the Map, dates the Calendar, numbers Analytics), covered in the dashboard. The dashboard table builds one column per field that writes case data. When you need a field that captures repeating rows (line items, multiple inspections), reach for a batch field, which stores an array of rows under one key.
Related
- Track the invoices: see it in action
- The dashboard
- Core concepts
- Output naming