Cases & case data
A case is the durable record for one unit of work, holding its files, extracted data, history, and generated outputs; each template field writes its value under a stable key, so renaming a field or column later never disturbs the data already saved.
Filling one form is simple: 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 record comes in, and it is the heart of Pro: 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 stay template-first: each run is saved as a temporary case for 14 days, and the full dashboard pipeline opens on 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 Documents that arrived and that you produced (one flat list where every file is a peer row), the Case data extracted or entered, the Activity history of notes and submissions and generations, 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. You can change a case's identifier at any time by editing its Case ID on the case detail; the new value is claimed for future file routing. 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.
Every value wears a small provenance tag on its label, so at a glance you know where it came from: Extracted (an eye, violet: the app read it from a source file), User Input (a pencil, amber: a person entered it), Computed (an ƒ, teal: derived at read time from an expression over other fields), and Static (a stamp, blue: fixed at design time, plus system or company-profile bindings like today's date that resolve at read time). It is the same tag you see on the template preview, so a field that was extracted looks the same in both places. Editing an Extracted value flips its tag to User Input (the value is yours now) and pins the field, so later extractions leave it alone. The clock icon on the row keeps the lineage one click away: what the value was before, what it is now, who changed it and when, and the document the original was read from. Extracted values also carry a small from <file> caption linking to the document they were read from.
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 for each value a field captures or derives, so a field that captures more than one thing (an address split into street and borough, say) shows as more than one column. 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