Automations: Automate Your Banks, Feeds and Tables

Automations let your workspace react on its own: tell the team when a bank needs signing in again, log every delivery a feed could not make to a table, post a note on a row when its status becomes Paid, or read an account's transactions every Monday and add a summary row. You build an automation on a canvas, publish it, and a member approves what it may do before it ever runs.

What an automation is#

An automation is a trigger followed by steps, drawn as cards on a canvas and wired in the order they run.

• The trigger says when a run starts: when someone presses Run, on a schedule, when a request reaches a secret link, when something happens in BankSync (a bank needs signing in again, a feed fails, a row is added, support replies), or when someone presses a button on a dashboard. One automation can have more than one trigger.
• The steps say what happens. Each step is handed a list of items (a transaction, a row, an event) and hands on its own. Some read your data (a bank's balance, a table's rows), some shape it (filter, sort, set a field, write some text), some decide (branch, loop, wait for an approval), and some act (add a row, notify the workspace, run a feed).
• The grant says what the automation may touch. It is worked out from the steps, never written by hand, and a member who holds every permission it asks for approves it. Until then the automation does not run.

A run is pinned to the version that was published when it started, so publishing a change never alters a run that is already going.

Where to find them#

• The Automations tab. Lists your workspace's automations with their status (not published yet, waiting for approval, on, off, paused) and last run. New automation asks for a name and what starts it; Import brings one in as a draft; Approvals opens what approval steps are holding for a person. Below the list, the templates start from something that happens in BankSync. See Templates.
• Folders, on the left. The panel beside the list (and beside every automation in the builder) holds your automations in folders. Make a folder, rename it, give it an icon, drag an automation into it, star the ones you use most, or send one to the trash and bring it back from there. [ opens and closes the panel.
• An Automate menu appears on a table's toolbar, a bank's page, a feed's header, the Clients list and the Support page. It offers the triggers that fit there ("When this feed fails", "When a row is added", "When support replies"), the templates that start from them, and the automations already attached to that bank, feed or table. Picking one makes a draft with the trigger in place and the bank, feed or table already bound, and opens it in the builder. Nothing runs yet.
• A feed's page. A sync feed offers Convert to an automation: the feed's work as steps you can add to. See Steps for banks, feeds, tables and mailboxes.

How an automation comes to life#

1. Build. Add steps from the library on the right and wire them on the canvas. The builder checks the draft as you go and lists anything that would stop it from publishing. Build your first automation walks through it.
2. Test. Give each trigger some sample data and run the draft without sending or writing anything, or test one step on its own. See Testing, running and run history.
3. Publish. Publishing saves a version. A draft with a blocking problem cannot be published until it is fixed. See Publishing, versions and going back.
4. Approve its grant. A published automation asks for the permissions its steps need. A member who holds every one of them approves it from the builder. See Approvals and grants.
5. Turn it on. An automation that is on starts on its triggers. You can also run it by hand and follow each run in the runs panel.

Who can do what#

• Viewers can open automations and their runs, but not change them.
• Editors create, edit, publish, turn on and off, rename, move, copy, export, import and trash automations, and can withdraw a grant.
• Approving a grant, deciding an approval, going back to an earlier version and running a run again are a person's decisions: a member signed in to BankSync makes them in the app. An API key or an agent never can.
• Reading what a run produced needs its own permission (automation_outputs:read) as well as every permission the run's grant held, and each read is recorded.

Good to know#

• Events arrive shortly after they happen. Bank, feed and support triggers are recorded just after the fact, so a run can start a little late. A support reply is relayed from BankSync support and usually arrives within a minute. Table triggers are recorded with the row write itself.
• A trigger names what happened, not the details. A bank or feed trigger carries ids, never credentials, amounts or free text; add a step that looks up what you need.
• Your data is data, not instructions. What a webhook sends, what a bank or a table holds and what a run produces may have been written by a stranger. BankSync marks it untrusted, and a step that cannot be undone will not take its target from it.
• An automation never starts itself, and a chain of automations calling each other stops at three.
• A removed bank or deleted feed pauses what depends on it. Every automation bound to it is turned off and marked paused, with what went away and what brings it back. Restoring a removed bank within its undo period turns those automations back on.

The rest of this guide#

• Build your first automation: a template to a running automation, step by step.
• Triggers: everything that can start a run.
• Steps and shaping data: items, expressions and the shaping steps.
• Branches, loops, parallel paths and failures.
• Approvals and grants.
• Testing, running and run history.
• Publishing, versions and going back.
• Templates.
• Steps for banks, feeds, tables and mailboxes.
• Webhooks and signing secrets.
• Building with an agent, the CLI or the API.