Back to Reports & Documents

Report Primitives: Data Tables, Snippets, and Computed Defaults

A beginner-friendly tour of the three building blocks AwardLettr uses to compose reports: data tables for structured sections, narrative snippets for reusable prose, and computed defaults for auto-filled fields.

Advanced7 min readUpdated 2026-05-23
All roles

You'll learn

  • What each of the three report primitives does at a high level
  • How the three primitives compose to produce a finished report
  • When to reach for each primitive vs. just typing prose into the report
  • Where to find the deep-dive article for each primitive once you are ready

Why this matters

You are about to dive into custom report templates. The deep-dive articles keep throwing around words like "data tables," "narrative snippets," and "computed defaults" as if you already know what they are. You do not, yet.

Without orientation, every advanced article reads like the middle chapter of a book you never opened. You bounce, decide custom templates are not for you, and stick with whatever ships out of the box. That is fine until you need a report layout that the default templates do not handle, and then you are stuck.

This primer is for anyone customizing report templates for the first time. Skip it if you are only using the out-of-the-box templates and have no plans to build your own. Read it if any of the deep-dive articles on data tables, snippets, or computed defaults felt like they were missing the first chapter.

AwardLettr reports are not Word documents you fill in by hand. They are composed from three building blocks: data tables, narrative snippets, and computed defaults. Once you understand the three primitives, the deep-dive articles on each one will click much faster. This article is the primer.

The three primitives at a glance

Data tables

Structured data sections in a report. Loss description, adjuster scope, settlement timeline — anything that is "fill in these fields, render them as a table or formatted block".

Narrative snippets

Reusable text blocks with variants. Your "wind loss intro paragraph" stored once, picked from a dropdown on every relevant report. Edit it once, every report using it updates.

Computed defaults

Auto-populated values pulled from the appraisal data. Insured name, claim number, carrier address, party signatures — fields that should never require typing.

When you are ready to go deeper

Each primitive has its own advanced article with the full schema, template syntax, and edge cases. Start with "Data Tables: Repeating Sections in Your Templates", "Narrative Snippets: Reusable Boilerplate Prose", and "Computed Defaults: Auto-Fill Custom Fields". This overview gives you the mental model first.

Primitive 1: Data tables

A data table is a named, structured section of a report. Each table has columns (e.g. "Item", "Quantity", "Unit Price", "Total") and you add rows to it. The template controls how it renders in the finished PDF.

  • Loss description: a list of damaged areas with descriptions and photos.
  • Adjuster scope: line items from the carrier estimate with notes.
  • Settlement timeline: dates, events, and parties on each step.

You fill in the data on the appraisal Reports tab. The template references the table by name and renders it however the template author defined (usually a styled table, sometimes a bullet list, occasionally a custom layout).

Why not just type the table into the report?

Because the same data table can be referenced by multiple templates and exported to multiple formats. Type the loss description into a structured table once, and your Award Letter, Umpire Brief, and Final Report all pull from it. No copy-paste, no drift.

Primitive 2: Narrative snippets

A narrative snippet is a chunk of reusable prose that you have written once and can drop into any report. Snippets can have variants, so you store one "wind loss intro paragraph" snippet with three variants (wind only, wind + hail, wind + tornado) and pick the right one on each report.

  • Standard introductory paragraph that explains the appraisal process.
  • Boilerplate disclaimer language at the end of an award letter.
  • Methodology paragraphs that vary by loss type (wind, hail, fire, water).

Snippets live in Settings → Narrative Snippets. You can edit the default body and add variants. Templates reference the snippet by ID, so renaming a snippet later does not break anything.

Primitive 3: Computed defaults

A computed default is a custom field whose value is calculated from other fields rather than typed manually. Two flavors:

  • Pulled from appraisal data: insured name, claim number, carrier address, party signatures, inspection date. These fields auto-fill from the appraisal record.
  • Aggregated from other custom fields: total damages (sum of itemized field values), depreciation percentage (calculated from RCV and ACV), etc.

You set these up in template fields. AwardLettr detects the dependencies and refreshes the computed value any time a source field changes.

A simple workflow: generating a report

Here is how the three primitives interact when you actually generate a finished report:

1

Open the template

Template defines which primitives it uses and how to render them

2

Fill data tables

Add rows to loss description, scope, timeline tables

3

Pick snippet variants

Choose the right intro paragraph for this loss type

4

Computed defaults auto-fill

Insured name, claim number, party info populate automatically

5

Generate PDF

Template composes the primitives into the final document

Old way vs. AwardLettr

The old way

  • Copy-paste from your last similar report; hope you remember the formatting
  • Re-type the boilerplate intro paragraph (and forget to update the date)
  • Manually transcribe the claim number into 12 places in the document
  • Tweak the loss description in the Word doc, forget to update the Award Letter

AwardLettr

  • Primitives compose into a clean report every time
  • Snippets stay consistent — edit once, everywhere updates
  • Computed defaults pull from the appraisal record — no transcription
  • Same structure across all your work, no per-report drift

When to use each primitive

Diagnostic walkthrough

What kind of content are you trying to add?

Start small, compose over time

You do not need to design all your primitives upfront. Start with one template and one data table. Add snippets when you notice you are typing the same paragraph twice. Add computed defaults when you catch yourself transcribing the claim number into a field. The library grows organically with your workflow.

Common pitfalls

  • Trying to use data tables for one-off content that will only ever appear on a single report. Just type it into the report directly.
  • Building a snippet with no variants when the content actually varies by loss type. You will end up editing the snippet body for every report. Use variants from the start.
  • Setting up a computed default that aggregates from fields that are themselves computed defaults of computed defaults. Cycles are detected and skipped, but the result is rarely what you wanted. Keep computed defaults one layer deep when possible.
  • Renaming a data table or snippet and being surprised when reports break. They do not — references are by ID, not name. But if you DELETE a primitive that templates reference, those references become no-ops.
Suggest an editLast updated 2026-05-23
Report Primitives: Data Tables, Snippets, and Computed Defaults | AwardLettr Docs