Automations

An automation is a standing instruction on a register: when this happens, do that. Open the panel from the Automations button on the view bar.

The editor is the automation, written as a sentence — "Every day at 09:00, for each record where every record, then find records, and then update the records that were found." Every underlined part of it is a control: click the trigger to change what sets it off, the middle to narrow which records it is about, an action to change what it does. The sentence rewrites itself as you edit, so if it says what you meant, the automation does what you meant.

An automation still has three parts — the trigger, the records it is about, and what it does — but they are the words of the sentence rather than three sections to assemble in your head. The common instruction is one line. Conditions and further actions lengthen the sentence only once you add them.

The ⊕ at the end of the sentence adds an action. Inside an action you can also change its kind, move it earlier or later when there is more than one, and remove it.

The Test button and the on/off switch sit directly under the sentence, side by side, because they are one progression: test it, read the verdict, arm it.

The list answers "is it alive?"

Each row in the panel's list shows what sets the automation off, when it last ran and how that went — a failure shows its reason right on the row — and, for a scheduled automation, when it next comes round. An armed automation that has never fired says so. Past a handful of automations a search box appears.

An empty register greets you with recipes — a notification on new records, a daily sweep, a run-by-hand button — each arriving pre-filled but untested, so the test-before-arming gate below applies to a recipe exactly as it does to anything you build from blank.

What can wake one up

"Starts matching" is about the moment, not the state

This is the trigger most people want and the one that behaves differently from how it reads. When a record starts matching fires on the crossing — the edit that took a row from not matching to matching. It does not fire again while the row stays there.

That is deliberate, and it is what makes the trigger usable. A rule that fired whenever a row was overdue would fire again on every unrelated edit to that row for as long as it stayed overdue — and a rule that also writes to the row it fired on would never stop. If the row later falls out of the conditions and comes back, it fires again, because that is a new crossing.

A "starts matching" trigger with no conditions is refused, and the panel says why: nothing can start matching nothing.

A schedule runs once per matching record

When a scheduled automation comes round, it reads its conditions as a search over the table and runs its actions once for each record it finds, with that record as the one the actions are about. So {Column} tokens read that row's values, "update the trigger record" means that row, and a conditional branch has something real to ask about.

With no conditions, that means every record on the table, every time. The panel says so twice — in the sentence itself, in the warning colour, and above the condition builder when you open it — because a nightly sweep over an entire register is a thing to choose, not to discover. On a schedule the sentence reads for each record where… and the condition builder is headed the same way, because there the conditions pick the rows rather than deciding whether anything happens at all.

If nothing matches when the schedule comes round, the run history records that too. A rule that has quietly stopped matching anything should not look identical to a rule that never runs.

Whose 09:00

A schedule's time is read on the workspace's clock, set once in Settings → General → Time zone and shared by everybody in it. A workspace set to Türkiye runs its 09:00 sweep at 09:00 in Istanbul, and keeps doing so across daylight saving, because the offset is worked out for the day the run falls on rather than fixed once.

A workspace that has never chosen runs on UTC — which is what every workspace did before the setting existed. If your schedules have been firing at an hour you did not expect, that is why, and setting the zone moves them to the hour you actually asked for.

What an automation can do

• Create a record — on this table or another one, with values you write as plain text, as {Column} tokens read off the triggering record, or from one of your record templates.
• Update records — the record that triggered the run, or every record the step above found.
• Find records — pick rows for the steps below to work on.
• Add a comment — on the triggering record, in the record's own comment thread, exactly where a colleague's remark would appear. The automation is named as its author, so a remark a rule left never reads as a person's.
• Notify somebody — send a message to the register's owner, to whoever turned the automation on, or to a person you name.
• Conditional — an if / otherwise fork, one level deep.

What an automation may never do

An automation cannot confirm a record. There is no action that does it, and an action that tries to reach it by writing to the record's status is refused when you save — not silently at run time. Confirming is a person vouching for a row, and it is the thing an auditor reads as evidence.

For the same reason, every record an automation creates is born as a suggestion, waiting for somebody to confirm it, and every cell it writes carries the automation's name as the one who wrote it.

Test it before you turn it on

A new automation is off, and the switch stays out of reach until you have tested it — the switch sits beside the Test button at the top of the editor, with the reason written next to it while it is locked. Press Test and you get, without anything actually happening:

• whether the trigger matches — tried against the newest record your conditions keep, or against a record you name;
• every step, resolved — the real values your {Column} tokens come out as on that record, and where each step would write;
• the reason any step could not resolve, in plain language — a column that has been deleted, a template that is gone, a message that comes out empty.

Nothing is written, no comment is posted, nobody is notified, and the test does not appear in the run history. It is a rehearsal.

Once a test comes back clean, the switch is live. Changing the automation turns the switch off again and asks for another test — a test vouches for the instruction you tested, not for its name.

This gate exists because of a specific failure: an automation that saves, arms, fires, and does nothing looks exactly like an automation that is working. There is nothing on the screen to tell them apart, so the screen makes you look first.

Where it runs, and when

Automations run on our servers, not in your browser tab. That means:

• A colleague's edit fires your automation, whether or not you have the register open.
• A scheduled automation runs at its time, whether or not anybody is looking.
• Nothing fires twice because two people had the register open.
• Run now runs on the server too, so a manual sweep does the same work in the same way as one that fires on its own.

Your own edits still take effect immediately on screen. When an automation changes the row you just edited, that change comes back with your edit, so you see the rule act on the row as you make the change. A row an automation created or changed elsewhere on the register appears within a few seconds.

A schedule starts from when you arm it

A scheduled automation owes nothing for a time that had already passed when you armed it. Arm an every day at 09:00 automation at two in the afternoon and it does not run this morning's sweep on the spot — it waits for tomorrow at 09:00. The list row shows you that moment as Next run, so you never have to work it out from the sentence and a wall clock.

The same rule applies when you change when an automation runs: a new time starts fresh, and moving a schedule from 09:00 to 08:00 in the afternoon does not fire it for an 08:00 that has already gone by.

Once it has come round, it comes round exactly once. Whatever time your schedule names, it runs a single time for that moment — the register is checked far more often than your schedule fires, and a run that has already happened is never repeated.

Reading what happened

The Run history tab lists every run, newest first, and it is kept — it is still there tomorrow, and after a reload. Opening it from inside one automation scopes it to that automation, shown as a chip you remove to see everything. Each entry says what set it off, and opens to show every step and what came of it:

• Succeeded — it did something, and each step says what.
• Nothing to do — it ran, and every record already held the values it would have written. An idle sweep is honestly idle rather than made to look busy.
• Failed — it stopped at a step, and the entry names the step and the reason in plain words.
• Skipped — it would have set itself off again, or a chain of automations had gone too deep. Automations follow each other three deep, and the fourth link is refused rather than left to spin.

One run is one entry. Pressing Run now shows you what it did straight away, and the same run is the one that appears in the history a moment later — not a second copy of it. A run is written down at the moment it happens, on the server, whether or not the tab that set it off is still open.

A failure is told to somebody. Whoever turned the automation on gets a notification naming the automation and the reason; if that is not known, the register's owner does. A rule that has been failing quietly for a fortnight is the thing this prevents.

When a run fails, what has already happened stays

A run stops at the failing step and does not attempt the ones below it. It does not undo the steps that already worked. Whatever landed, stays. Quietly rolling it back would hide from you that anything happened at all.

Undo does not reach an automation's writes

⌘Z in a register takes back what you just did in that tab. An automation runs on our servers, so its writes are not on that stack — there is nothing to press, and pressing it takes back your own last edit instead.

To reverse what a rule did, change it back the way you would change anything else: edit the cells, or send a row it created to the bin. Both are ordinary edits, and both are yours.

What you can rely on instead is that nothing it did is a mystery:

• the run history names every row the run touched and what it wrote there;
• every cell it wrote carries the automation's name as the one who wrote it, so a value you did not expect says where it came from;
• a row it created appears in the table's history attributed to the automation, and arrives as a suggestion waiting for somebody — so it cannot quietly become part of the record without a person.

Turning the automation off stops the next run; it does not undo the last one.

Notifications

The Notify somebody action sends a message to:

• the register's owner,
• whoever turned this automation on, or
• a person you name.

The message takes {Column} tokens, so it can say which record it is about. Notifications arrive in the app, in your notifications list — the same place a mention or a review request arrives. They are not emailed.

Limits worth knowing

• Automations follow one another three deep. The fourth link is refused and says so in the history.
• An automation can never set itself off, directly or through a chain.
• Undo does not fire automations. Taking something back would otherwise re-do the very work you just undid.
• A run keeps its history even after you delete the automation, so a change you are asked about later is still explainable.