Making a workflow

This page walks one workflow from the first sentence to the first rows, the way it actually goes in chat. The example is a table, because tables have the most steps; an Email, Schedule or Follow-up rule is the same conversation with fewer of them.

The whole thing takes a few minutes. The parts that matter are the test before the backfill, and knowing which of two levers to pull when something's off.

1. Say it

You, on any tab:

Every class registration from Formhive — save the student, their email, the class, the date, and what they paid.

Dustav will usually ask one or two things. Which Formhive email — the registration or the reminder it sends later? Is the amount the class fee, or the total including the clay pack? Answer in a sentence. If a registration is already in your inbox, Dustav reads it to get the sender and the columns off a real example instead of guessing.

Then it proposes the rule back in one line:

I'll watch for Formhive emails with "New registration" in the subject and save Student, Email, Class, Date, Amount — the class fee, not the total. Sound right?

Say yes. The rule is live from that moment — there's no activate step — but going live costs nothing until mail arrives.

2. Test it on the sample

Before anything else, Dustav runs the rule on that one real email and shows you the row it would save. Nothing is written; it's one read.

From Priya's registration it'd save: Student Priya Anand · Email priya@… · Class Wheel Throwing 101 · Date 2026-10-06 · Amount $285. Look right?

This is the step that makes a workflow trustworthy. The reader that fills rows is a different, narrower reader than the one you were just talking to — it sees the email, the columns, and the definition, and not a word of your conversation. The test shows you what that reader does with your rule, on your own email, before you spend a backfill finding out.

Two things can come back:

• A row. Check the cells. A wrong or blank one means a hint on that column — "the amount on the class line, never the order total" — and Dustav tests again.
• A decline, with a reason. "It declined Priya's: 'a Formhive booking confirmation — nothing in it says registration'." The reason tells you what the reader couldn't see. Usually the fix is the table's definition — one sentence saying what counts as one of these — and Dustav tests again.

If the test comes back right, the rule is right. Every future email like this one reads the same way.

3. Backfill the mail that already came

A new rule catches mail from now on. For what's already in your inbox, ask:

Back fill this year's registrations.

Dustav turns that into a search over your mail, tells you what came back — the count, the search it used, that each email gets a close read — and waits for your go. Emails the rule has already read are left out. If the set looks wrong, the fix is a better search, never hand-picking emails; if it looks right, say go and the whole window runs. Each email is one metered read, same as any other.

When it finishes, the report is honest by construction: how many read, how many rows landed, and each email it declined by name with the reason. A decline isn't a failure — it's the reader saying "this one wasn't one of those" — and because the same email always reads the same way, the fix for a wrong decline is the rule (the definition), then re-run just the ones that didn't land.

A backfill is for tables only. It fills rows from old mail; it never drafts an email. So an Email, Schedule or Follow-up workflow starts from the day you make it, and if you want the old cases covered (last month's new members who never got the code), ask Dustav to draft them in chat, one at a time, so you decide on each.

4. It's running

From here, every matching email files itself during the sync it arrives in. The card on the Workflows tab counts the rows; the rows themselves are on the Tables tab. Ask the table questions in chat instead of scanning it. Turn on Ping me if you want arrivals mentioned to you.

The two levers

Almost everything that goes wrong with a table is one of two things, and each has exactly one fix:

What you see	What it means	The fix
A cell is wrong or blank, and it keeps happening	The reader can find the email but reads a value the way you wouldn't	A hint on that column
Emails that should land keep being declined	The reader can't see the meaning the table's name carries	The table's definition

There's no third lever, and there's no point re-running an unchanged rule: the same reader reading the same email with the same columns gives the same answer. Dustav will tell you that rather than spend your balance to demonstrate it.

Things that aren't workflows, and what they are instead

• "Keep a list of people I meet at markets." A workflow table is fed by email — Dustav adds a single row by hand only when you ask for one that has no email behind it, never a whole list. A hand-curated list is a document. If some of those people also email you, a table workflow catches those; Dustav will offer both.
• "Remember that Tuckahoe is our clay supplier." A fact. Say it and it's known; an Email workflow that forwards orders to Tuckahoe will use it.
• "Here's the exact email we send when a piece is ready." A template. Save it; then decide when it goes — an Email workflow, a Schedule, or by hand.
• "Send this Thursday at 9." One email at one time is Schedule send on the composer, not a workflow.

Changing one later

Everything about a rule is changed by asking: "add a Rental column", "the print shop moved to orders@…", "make the reminder go at 8 instead of 7", "pause the registrations one for the summer." Dustav edits the rule and the card updates. One caution worth knowing: on a rule that recognises a kind of email, "also match this sender" replaces the recognition with a sender match — it's one or the other — so say what you mean and Dustav will confirm which you've got.