A claim nobody can reconstruct six months later

The situation

A claim is not one record. It is a claimant, an incident, a variable number of damage line items, photographs and documents attached to each of those, an adjuster who approves or refers it, and a payment that has to reconcile. The requirements differ by region, the structure changes when a new product launches, and an auditor will eventually ask who approved a specific claim, what they saw, and whether anything moved afterwards.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model the claim as it arrives

   Build the Claim record type on the canvas: sections for the claimant and the incident, a repeating section for line items, and a further repeating section for evidence nested inside each line item. The count of line items is not known in advance and does not need to be — a repeating section is what a variable list is. The claimant section is defined once and reused wherever a claimant appears.

   What it uses: Sections that nest and repeat to any depth, shared across record types

2. 2

   Make the loss codes one list

   Category on a line item is a choice field whose options come from the Loss codes record type rather than a hardcoded list. It resolves when the field is read, so adding a code is a change in the record type that owns it — not a coordinated edit across the form, the API and a lookup table.

   What it uses: Choice options sourced live from another record type

3. 3

   Turn on history before the first claim

   History is enabled on the Claim schema, so every write keeps a snapshot to the depth you choose. This is the step that decides, months ahead of the question, whether "what did this claim say on the fourteenth" is a lookup or a project. It has to be on before the data exists.

   What it uses: Snapshot per write, restore to any retained point

4. 4

   Take the claim through the API and the screens

   Publishing the version gives the Claim its own REST URL space — list, read, create, update, bulk, search — and a form and table rendered from the same definition, including the nested repeating sections. The intake portal writes through the API; the claims team works in the screens. Neither was built.

   What it uses: Its own API on publish, plus forms and tables rendered from the schema

5. 5

   Attach the evidence without routing files through the API

   Photographs and reports upload straight to storage through a short-lived signed link and are then attached to the evidence field. Large files never travel through the application, and download, preview and PDF viewing are signed links too.

   What it uses: Direct-to-storage upload with short-lived signed links

6. 6

   Start the assessment workflow when a claim is created

   A trigger on the Claim record type starts a run whenever one is created, filtered so that only claims above a threshold enter the referral path. The workflow is drawn on a canvas. Each link out of a step carries its own condition, and one link is marked as the path to take when none of the others do. A malformed condition does not fall back to a best guess: it refuses to match, and the run stops there. That is louder than a claim quietly taking the wrong branch.

   What it uses: Record triggers with filters, conditional links with an explicit default

7. 7

   Let the workflow check the claim rather than the payload

   Before routing, a step re-reads the claim: the total of the line items, whether evidence is attached. A claim that sat in a queue for two days is routed on what it looks like today, not on the snapshot that started the run. The result is written back onto the record.

   What it uses: A step that reads and writes the record mid-run

8. 8

   Stop and ask the adjuster, with a signature

   A human decision step creates a task in the adjuster inbox. Approving requires re-authentication at that moment, with a second factor where the amount warrants it, and a reason chosen from your own codes. The signature is appended and chained so alteration is detectable, and the decision payload is immutable once recorded. The options and the form are fixed when the task is created, so editing the workflow later never reshapes a task somebody has already opened.

   What it uses: Human decision steps with re-authenticated, chained signatures

9. 9

   Call the payment system without holding the run open

   The payout step hands work to the payment provider and parks, with a deadline. The provider posts its result back, authenticated with a token issued for that run. If a worker restarts in the middle, the run resumes — its state is in the database, not in a process. If the provider degrades, that one action is throttled live rather than in a release.

   What it uses: Callback steps with a deadline, and per-action live throttling

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.