Table workflows

A Table workflow turns a recurring email into rows. Every time a matching email arrives, it's read and its facts land as a row in a table you can search, sort, count, and export as CSV. The person stops retyping the registration into a spreadsheet; the spreadsheet fills itself, and every row links back to the email it came from.

It's the shape most people start with, and the one with the most to know. Everything below is about tables.

The sentence

"Every class registration from our booking form: save the student's name, their email, the class, the date, and the amount."

That sentence has the three parts of a table workflow in it:

• Which emails — registrations from the booking form.
• What counts as one — the registration itself, not the reminder the same form sends later.
• Which columns — student, email, class, date, amount.

Dustav settles each of those with you in the conversation, then creates the rule. If one of these emails is already in your inbox, it reads it first, so the sender and the columns come from a real example rather than a guess.

Which emails: a sender, or a kind?

The first thing Dustav decides is how the rule recognises its email, and there are two ways.

A known sender. The Square receipt, the booking form's notification, one supplier's invoice. The rule matches on the sender's address (usually the domain is enough) and, if that sender sends more than one kind of email, a word from the subject. It can also carry an exclude word: match "order", skip "cancelled". This is exact and cheap, and it's right whenever the email always comes from one place.

A kind of email, from anyone. Shipping notices from whichever carrier, invoices from any supplier, "I'm interested in a commission" from a stranger. Here the rule is a sentence in your words — "a supplier or carrier saying a shipment is on its way or has arrived" — and Dustav judges each email against it as it reads. This is what to use for anything open-ended. A sender list would silently miss every new supplier you start buying from; a sentence catches them. Nothing needs a form: a vague human note from someone you've never heard of is a perfectly good match.

A rule has one or the other. There's a small cap on how many judgment-based rules a business can run at once, so Dustav uses the sender route when the sender is genuinely fixed.

Or what you send. A table can fill from your own sent mail too: "every quote I email a customer: who it's for, the amount, the date I sent it." Dustav reads each message you send right after it goes out, and a quote lands as a row. On this side the rule always recognises a kind of email (you're the sender of all of it), and older sent quotes can be backfilled from your Sent folder.

What counts as one: the definition

Every email the rule catches is checked once more by the sealed reader that fills the row: is this really one of these? It answers from the email and the table's name. That works when the name is the email's own type — a "Class orders" table over order emails. It fails when the name is a meaning you assign and the email never states. A "Comped seats" table over registration emails that just say "new registration" gets declined every time, correctly from where the reader sits, because nothing in the email says comped.

The fix is one sentence, the table's definition: "Every registration from the booking form with a $0 total is a comped seat; paying students show an amount." Dustav asks for it whenever the table's name is a role, a status, or a category the emails don't carry. The definition has to name something in the email — the email type, a line item, a zero total. If the only thing that makes an email one of these is the folder you filed it in or something you know in your head, a live rule can't see that; Dustav will say so and offer the nearest honest thing.

The columns

Each column has a name and a type: text, date, money, number, email, or a fixed set of options. Types matter: a money column totals, a date column filters by day, a text column doesn't. Only the columns you asked for — nothing is added for you.

A column that plain reading would get wrong gets a hint: plain words attached to the column that tell the reader where the value hides or how to compute it. "The amount on the clay-pack line, never the order total." "Divide the clay-pack total by 40 — the line-item quantity is not this count." A hint fixes a systematic misread once instead of you correcting the same cell every week. Hints and the definition are the only two things you say that reach the reader filling the row; the rest of the conversation doesn't, on purpose.

One row, or many

Most emails are one row: a payment, a signup, a receipt. But an email that is a list becomes many rows, one per line — a class roster, an order with line items, a season's schedule of dated sessions. You still pick the columns; the reader pulls every row the email holds. A schedule email with a dozen dated sessions is exactly what this is for, and if it's dated things you'd also like on the calendar, Dustav offers both.

Events, or things that get updated

Most tables log events: each email is its own fact and gets its own row. Some tables track a thing that several emails talk about over time — a parcel that ships and then arrives, a purchase order that's placed, invoiced, paid. There the emails are updates about one thing, and they belong in one row that fills in and moves along.

Dustav asks the one question that tells them apart: will a later email about this same thing show up? If yes, the table gets a key — a number the source issues that appears verbatim in every email about it (a tracking number, a PO number, an invoice number) — and a list of stages in order (ordered → shipped → delivered). A later email finds its row by the key and moves it forward; it can never drag a row backwards. Names and dates are never keys; they aren't identifiers, and keying on one merges things that aren't the same. A row whose email didn't carry the key is still saved, with its key cell blank, never dropped.

Where rows come from

Rows are written by a sealed reader — a single-purpose pass that sees the one email, your definition, and your columns with their hints, and nothing else. Not the conversation you had, not your business facts, not the folder the email sits in. The narrowness is the point: it's what keeps the amount in a row being the amount from the email and not a plausible guess. The Dustav you chat with never writes the rows an email yields, and never fills a table in bulk. The one row it adds by hand is a single one you ask for that has no email behind it — a booking someone phoned in. If you want a whole list you curate yourself, that's a document.

Rows arrive two ways. As mail lands — a new email that matches goes through the reader during the sync it arrived in, and the row is there when you look. By backfill — for the mail that already came. "Back fill last month's orders" is the question that follows every new rule, and it's covered in Making a workflow.

A cell the email doesn't answer is left blank rather than guessed — often exactly right (no clay pack on the order, no clay-pack amount). On a keyed table a blank can simply mean not everything has arrived yet — the ship notice came with a tracking number and nothing else; the invoice will fill the rest.

When something happens to a row

A row that was real stays real. When someone cancels, gets a refund, withdraws, or picks up their order, the row is closed: it stays on the table, struck through, with what happened and why ("cancelled — phoned in, moved to a credit"), and it stops counting. Ask Dustav who's coming and the answer leaves the closed rows out — and says how many it left out, so a cancellation is never mistaken for a missing booking. Email does this on its own, too: when a customer writes that they've cancelled or won't need the clay pack, Dustav strikes or updates their row — found by the email address they wrote from, never by name — and when your own reply confirms a change ("I've moved you to the 14th"), it updates the row to match. Each change shows on that email in Dustav's read, with an Undo. Only a row that was never real — a misread, a duplicate — is dismissed and hidden. Either one can be reopened, and every row keeps its history: when it was saved, from which email, and every change since, with who made it and why.

Fixing rows

To fix a single value yourself, click the row to open it, then click the cell, type, and press Enter. For anything more — "the tracking number on the Tuckahoe one is wrong", "Jenny cancelled, she got a credit", "Marcus moved to the Thursday class" — tell Dustav, and it fixes the cell, closes the row with what happened, or records the change. Either way the fix sticks: re-reading the email later never overwrites what you or Dustav set by hand, and the row's history shows who changed what. If the same mistake keeps landing, the fix is the rule, not the row: a wrong cell means a sharper hint; an email that should have landed and didn't means a better definition. Re-running an unchanged rule reproduces the same result, and Dustav will say so rather than spend your balance to prove it.

Ask the table, don't scan it

"Who's in Thursday's Wheel Throwing class?" "How many clay packs this month?" "How is the class column spelled?" Dustav queries the table — find, filter, count, group, total — and answers with the store's own numbers. A search finds a name no matter how old the row; a grouped column shows both spellings of a class side by side; a count comes from the store, never from reading seventy rows by eye.

On the tab

The rows live on the Tables tab — it appears in the menu once you have a table workflow. Each table gets its own page: sort, search, page through, export to CSV, and every row's ✉ opens the email it came from. The workflow itself is the rule behind it: on the Workflows tab a table's card shows when it fires, what it keeps (the key column and how many columns), whether it pings you, and how many rows so far, and opening it links straight to its table. Its toolbar has two switches — Active (paused means matching mail files nothing until it's back on) and Ping me (off by default; on, and arrivals come to you as one quiet, specific note rather than a buzz per row). And if the rule ever breaks — an email matched but couldn't be collected — that always surfaces, whatever the switch says.