Rollup fields: arithmetic across a link

A rollup answers a question about the records on the other end of a link: how many, how much, the smallest, the latest. The demo shop's Customers table has Total spent — the sum of each customer's order totals — and its Orders table has Items, a count of the linked plants. Nobody maintains either number.

Make one

Like a lookup, a rollup rides a link that must exist first.

1. Add a field and choose Rollup.
2. Through — the link to aggregate across.
3. Field — the linked field to aggregate. A plain count needs none: it counts linked records, not values.
4. Aggregation — the real list is Sum, Count, Minimum, Maximum, Average. Sum and Average need a number field; Minimum and Maximum take a number or a date — on a date field they read Earliest and Latest.

An optional condition — "Only linked records that match feed this rollup" — narrows the input: sum of order totals, but only paid orders is one rule away. Number rollups also take their own decimals and thousands-separator settings, so an average isn't stuck with its source's whole-number formatting.

Everything here is editable later — swapping Sum for Average is an ordinary edit.

The type follows the aggregation

Count, Sum and Average always produce a number. Minimum and Maximum keep the aggregated field's own kind — min of a number is a number, earliest of a date is a date, and filters treat it as one. Presentation carries too: a sum of a currency field reads as currency.

Derived, never synced

A rollup isn't stored and isn't kept up to date — it's computed from the linked records every time it's read. Edit a linked order and the customer's Total spent is right on the next read; there is no syncing step to lag or misfire. Records in the trash drop out of the arithmetic immediately and count again if restored.

Two consequences worth knowing:

• An empty link cell reads 0 for a count and blank for everything else — there's nothing to sum.
• A number that must not change later — the price you actually charged — should not be a rollup. Derived fields tell the present truth; invoices want history. Store that one.

Read-only, filterable, groupable, not sortable

Rollup cells are read-only on screen and refuse writes over the API — there is no column to assign. You can filter by any rollup in views and API queries (Total spent greater than 100 is a real query), and a grid groups by one: customers by how many orders they've placed, one section per number. Rollups don't sort — the value has no stored column to order by, which is a query's problem and not a grouped view's, since grouping happens over the records already on the page.

The deletion guard

A rollup depends on two things, and Tabla refuses — by name — to pull either out from under it:

• Deleting the link it rides: Can't delete "Orders" — the lookup/rollup field "Total spent" rides this link. Delete "Total spent" first.
• Deleting, or changing the type of, the field it aggregates: the refusal names the dependent the same way.

Delete or adjust the rollup first and the rest unlocks. The guard works from both sides of the link — deleting the mirror field is refused too.

Over the API

A rollup reads under its own name as a plain value of its type:

"Orders": [
  { "id": "rec_ff374pj8sbhe", "display": "ORD-1041" },
  { "id": "rec_t23a89yecn4d", "display": "ORD-1052" }
],
"Total spent": 135

Its stored config (aggregation, the link and target field ids) travels in the field's own JSON, so an integration can discover what the number means. See /docs/api.

When a lookup is the field you meant

If you're not aggregating — you want to see the linked customer's email, not do arithmetic on it — that's a lookup. The mental test from lookup vs rollup: if deleting one linked record should change this value, it's a rollup.