Automations: when this happens, do that

Automations watch your data and act on it: when a record is created, updated, deleted, enters a matching state, on a schedule, or when an outside system posts to a webhook URL, they run steps — update fields, create records, send emails, call webhooks, or generate text with AI. Every run is logged with a per-step breakdown, and you can rehearse a rule against your own history before you switch it on. Pick a trigger Open Automations from Manage workspace at the foot of the rail and press New automation. Choose when it fires: a record is created, updated (optionally only when specific fields change), deleted, matches conditions, on a schedule, or a webhook is received. Matches conditions is the “status becomes Done” trigger: it fires only when a record enters the matching state — editing a record that already matches won't re-fire it. Schedules run every N minutes (5 minimum), daily, or weekly at a UTC time. With a table chosen, the schedule runs once per record matching your conditions (up to 100 per fire); without one it runs once per fire. Trigger from anywhere: a webhook is received Pick A webhook is received and, once saved, the automation gets its own inbound URL — shown in the editor with a copy button. Paste that URL into any system that can send a webhook (a form tool, a payment provider, Zapier, your own code) and every JSON POST to it fires the automation. The payload is available to every step as {{webhook.<path>}}: a body of {"status": "paid", "customer": {"email": "a@b.com"}} gives you {{webhook.status}} and {{webhook.customer.email}}, and array items use numbers — {{webhook.items.0.name}}. The whole raw body rides along as {{webhook.body}} for forwarding. Conditions work too, checking payload paths with the same operators — only run when status equals paid. A post that doesn't match is logged as a Skipped run, so "why didn't it fire?" is always answerable from Run history. There is no trigger record on a webhook fire, so the steps that write into "the record" (Update the record, Generate with AI, Generate a PDF) aren't available — Create a record with {{webhook.…}} values is the usual shape: "when the payment provider posts, create a Payment record." The URL is unguessable and acts as the credential — treat it like a password, and it stays stable across edits so the system you pasted it into keeps working. Add conditions Conditions narrow any trigger: field equals / contains / is empty / greater than…, matched all or any. Numbers and dates compare properly (“due date less than 2026-08-01” works on Date fields). Use Name (display name) to test the record's name. Stack the steps Steps run top to bottom. If one fails, the rest are skipped and the run is marked Failed or Partly failed. The editor offers these steps: • Change your data. Update the record (the one that triggered the run, a record it links to, or each found record) and Create a record in any table of the workspace. • Tell somebody. Send an email and Send a text, up to 10 recipients each, and Call a webhook, which POSTs JSON to your URL. Send a text only appears when this server can send texts. • Work in another app. Do something in another app runs an action through an account connected on the Integrations page: open a GitHub issue, create a Stripe payment link, add a HubSpot contact. • Use AI. Generate with AI writes model output into a field. Point it at a choice list and it picks one of the field's options; an answer that matches none is not written, and the run log says why. Ask the AI to… reads your data with the permissions of the admin who saved the step, and answers. • Make a document. Generate a PDF fills a print template, then saves the file on the record, emails it, or both. • Control the run. Wait pauses it for a set time, up to 30 days, or until a date on the record, however far off that date is. Only continue if… ends it quietly when its condition doesn't hold. Find records looks records up, and can run every step below it once per record it finds. Request approval asks a person to decide. Every text box accepts template tokens that render per run: {{record.name}}, {{record.id}}, {{record.url}}, and {{record.<field_key>}} for any field, plus {{table.name}}, {{workspace.name}}, {{trigger.summary}}, {{now}}, and {{today}}. Unknown tokens render as empty text, and field keys are the same slugs the API uses. A link field prints the linked records' names, and a dot reaches through it: {{record.company.region}}. A People field prints the people's names; add .email for their email addresses, so {{record.owner.email}} in an email step's Reply to box sends answers to whoever owns the record. Add .ids to either kind when a step copies the link or the people into another record. Steps that produce something hand it to the steps below them: {{approval.url}} and the other approval tokens after Request approval, {{found.count}} and {{found.names}} after Find records, {{item.name}} and {{item.<field_key>}} inside its per-record run, {{ai.answer}} after Ask the AI to…, and {{connector.result}} after a step in another app that returns something. Keep what another app sends back A step in another app that creates something also returns it: the new issue's link, the payment link, the invoice number, the text a model wrote. What it returns is printed just under its inputs. To keep it, choose a field under Save the result to. The list is limited to fields that can hold the value, which is usually a link or an id: a link goes into a Url or Text field, an id or an invoice number into a Text field, and the stock level Shopify returns into a Number field. Below a Find records step that runs per record, the value is saved on each found record rather than on the one that triggered the run. Saved or not, the steps below can use it as {{connector.result}}, so you can create a payment link and email it in the same run. The token is lost at a Wait, so save the value to a field when a step after one needs it. The save is checked before anything is sent. If the field is gone, can't hold the value, or the record is posted, the step stops and nothing is created in the other app. A link made and then lost would tempt somebody to run the automation again, and that makes a second one. Send the record's own file, and choose who replies A step that takes a file, such as saving to Google Drive or OneDrive or attaching one to an email, offers a choice under the file's box: A web address, or The newest file in one of the record's Attachment fields. The newest file is the one added last, usually the PDF that a Generate a PDF step earlier in the same run has just made. If the field is empty, the step fails and names the record that had no file, and nothing is sent. The Postmark, Resend, SendGrid and Outlook email steps take a Reply to address, and it can be a token: {{record.owner.email}} sends answers to whoever owns the record. Google Drive saves only into folders RowFold made, so Create a Google Drive folder makes one per client or job and hands back its id to save on the record. OneDrive takes a folder path such as Clients/{{record.client}} and makes any folder that is missing. For a Teams channel message, paste the channel's link from Get link to channel into Channel ID. RowFold reads the team and the channel out of it, so Team ID can stay blank. Rehearse it before you switch it on Press Rehearse at the top of the editor and RowFold replays your table’s own history through the rule as it stands on screen — saved or not — and tells you what it would have done. Nothing is sent and nothing is written. No emails, no texts, no record changes, no webhook calls, and no entry in the run history. It answers the questions a rule can’t answer any other way: how many times it would have fired, over which days, how many different records it touched, and — if it sends anything — who would have heard from you, and which of them more than once. Watch the bar chart: a rule that looks calm at a few fires a day often turns out to have done almost all of its work on one morning, which is usually the morning somebody imported a spreadsheet or made a bulk edit. Those are called out by name. Change the window with the Over picker — 30 days up to a year — and rehearse again after you tweak a condition. Two triggers can’t be rehearsed and say so: a schedule fires on the clock rather than on a change, so use Run now instead, and inbound webhook payloads aren’t stored, so send a test request to the rule’s URL. What a rehearsal can’t know Anything the replay can’t be sure about is printed under the numbers, headed What this cannot know — it is worth reading, because the whole point is to be able to trust the figure. The usual ones: a field kept out of history leaves no trace to replay, so a condition on it is judged against the value the record holds today. Conditions on lookup, rollup and formula fields are the same — those are computed from other records, and what those records held at the time was never recorded anywhere. Records deleted for good since then can’t be rebuilt at all. One note can push the real number up rather than down: if the rule writes back to the same table, a real run would have produced changes of its own, which could have set this or another rule off again. The rehearsal only sees changes that actually happened. Very busy tables are capped, and when that happens the panel says which date the figures really start from rather than quietly reporting a short count. Watch it run Run history shows every execution with status (Succeeded, Failed, Partly failed, Skipped), duration, the triggering record, and each step's result. Use Run now in the editor to test against the table's newest record. Changes made by automations appear in the audit log as Automation · its-name. Chains are guarded: an automation whose changes trigger another automation works (to 3 levels deep), then the loop guard stops the chain and logs a Skipped run explaining why. Run history is kept for 90 days. Update a linked record, and do arithmetic An Update the record step doesn't have to change the record that triggered it. Which record to update also lists the relations on that table, so you can follow one and write to what it points at — “when a dispatch is created, update the linked part”. Each assignment also picks an operation: Set to, Increase by or Decrease by. For the last two the value is the amount, and it can be a token — {{record.qty}} — so a dispatch of three units takes three off stock. That combination is what lets automations do real inventory work: decrement on hand when something ships, add it back on a return, roll a counter forward. Increases and decreases are applied by the database in a single operation, so two runs firing at the same time can't both read the same starting number and overwrite each other. Stock stays correct under concurrent dispatches. Tick Never let it go below zero and a decrease that would go negative writes nothing and fails the step instead — you get a failed run to look at rather than a quietly negative balance. Draft automations by asking You can describe a rule to Ask RowFold instead of building it by hand: “when a dispatch line item is created, reduce that product’s stock by its quantity”. Ask drafts the trigger, conditions, and steps on a card; confirming creates the automation switched off, with a link straight into this editor to review and enable it. Cross-table rules use the Update a linked record step, including safe increment and decrement arithmetic. Tips • Matches conditions fires only when a record enters the state — reach for it for "when status becomes Done," not "while status is Done." • Test any rule with Run now in the editor — it runs against the table's newest record without waiting for a real trigger. • Drop tokens like <code>{{record.name}}</code> into email subjects, webhook URLs, and AI prompts; <code>GET /api/v1/tables</code> lists the field keys for <code>{{record.<field_key>}}</code>. • Automation changes show in the audit log as Automation · its-name, so you can always see what a rule touched. • A webhook-triggered automation plus Create a record turns any outside system into an intake: point your form tool or payment provider at the inbound URL and rows appear. Good to know • Email steps need the server's email service (Mandrill) configured, and the Generate with AI step needs an AI model configured — without them, those steps fail with a clear message. • A scheduled automation with a table chosen fires once per matching record, capped at 100 records per fire. • Steps run top to bottom and stop at the first failure — later steps are skipped and the run is marked Failed or Partly failed. • Automation chains are guarded at 3 levels deep: past that, the loop guard stops the chain and logs a Skipped run. • Run history is kept for 90 days, so older runs age out of the log. • A numeric increase/decrease is applied straight to the database, so it does not itself trigger other automations — a “low stock” rule won't fire off a decrement. • “Decrease by” expects an amount, not the new value. Leaving a plain number in a field switched to Decrease by will subtract that number every run. • An inbound webhook URL accepts a JSON object body (up to 128 KB) and answers 202 immediately — the steps run in the background, so check Run history for the result, not the HTTP response. • The inbound URL is the credential: anyone holding it can fire the automation. Don't paste it anywhere public; disabling the automation makes the URL answer 404 until it's re-enabled. • <code>{{connector.result}}</code> is empty after a Wait, because a paused run keeps only what was saved to a field. Save the value if a step after the Wait needs it. Who can do what • Creating, editing, enabling, and deleting automations is Admin-only; any workspace member can open the Automations list and Run history. • Automations run at the workspace level — their changes appear in the audit log as Automation · its-name rather than under a person.