Automation Steps for Banks, Feeds, Tables, Mailboxes, Dashboards and Widgets

The library's Your apps group holds the steps that reach your BankSync data: Banks, Enrichments, Dashboards, Widgets, Tables, Feeds, Mailboxes and Support, and the Tell someone group holds the steps that notify people. This page lists them, what each needs the grant to hold, and what they will not do.

Choosing the bank, account, table or widget#

Each step that acts on one thing takes it two ways. Pick or bind it: choose a bank, feed, enrichment, dashboard, widget, table or mailbox from the picker, so the automation's grant lists it and that resource's own page shows the automation under Automate. Or take it from an earlier step: the ids a listing step returns can be passed on, for example to read the balance of every account of every bank. Set one or the other, never both. An account is picked from the bank the step names.

Ids that come from a payee name, a description or any other text a person or a bank wrote are not accepted: a step that acts on a bank, an account or a table only takes an id BankSync assigned.

Reading banks, enrichments, dashboards and widgets#

Thirteen steps read: none changes a bank, an enrichment, a dashboard or a widget, and none asks a bank for fresher data than BankSync already holds.

A published automation asks for banks:read, enrichments:read or dashboards:read, according to the steps it uses, and a member who holds each one approves the grant. An automation reads only in its own workspace and only what its grant names. What these steps return is your data, so BankSync treats it as data, not as instructions: it is marked untrusted, and bank, balance, transaction and widget data is kept for the shorter period that applies to consented data.

To start from a bank's data rather than read it — when a transaction arrives, a balance crosses a level, an expected payment has not arrived, holdings or trades change — see Triggers.

Table steps#

The Tables steps work with your BankSync tables, under tables:read and tables:write:

• List the workspace's tables and read a table and the fields it has.
• Find rows that fit a filter, a page at a time.
• Add rows to a table, or update rows that already exist, with each value mapped to a field. A template that adds a row leaves the mapping for you to pick.
• Change some fields of one row. A relation is not a field this step sets: use Link rows.
• Link rows: link a row to rows of the table a relation points at, or unlink them (below).
• Write future rows: write rows dated in the future, such as upcoming bills or a payoff plan, that running again updates instead of adding twice (below).
• Move rows to the trash (they can be restored for a while) and bring rows back. Deleting more than 50 rows at once needs an approval step in front of it.
• Read a row's conversation and post a message on it.

A row an automation writes shows the automation in the row's history, and a table trigger ignores a change the same automation made, so an automation cannot start itself by writing to the table it watches.

Linking rows#

Link rows fills a relation field, such as a receipt's Transaction. You choose:

• Which table? The table whose row you link (Receipts).
• Which row? Usually the row an earlier step gives you. After a table trigger on the same table, it starts as the row that changed.
• Through which relation? A relation field of that table, picked from its fields once the table is chosen.
• Which rows to link? Rows of the related table, usually the ids an earlier Find rows step found.
• How to link them: Add these links keeps what is linked already; Replace the links with these makes the field exactly these rows; Remove these links unlinks them; Put the links in this order reorders them.
• Which table does it link to? Optional: the table the relation points at (Transactions).

The step answers with the row ids the field now holds and how many links it added and removed. Running it again with the same rows changes nothing, so a retry is safe. A relation that holds one row refuses a second, rather than dropping one.

A two-way relation also writes the matching field on the related table, so approving the automation must cover that table too, with edit access. Choose it under Which table does it link to? and the approval lists both tables. A one-way relation only needs the related table in the automation at all, for example through a Find rows step on it. Without that, the step stops and says which table is missing. A test run shows what the step would link and changes nothing.

A common pattern for receipts: when a receipt row is added, Find rows in Transactions whose amount is within a few cents of the receipt's total and whose date is within a few days of it. Then, where exactly one transaction was found, Link rows to link the receipt to it and Change some fields of one row to set its status to Matched. Where none or several were found, set the status to Needs review instead.

Future rows: upcoming bills, forecasts and payoff plans#

A bill calendar, a 13-week forecast, a savings challenge or a debt payoff plan needs rows for dates that have not happened yet. Three shaping steps make them (see Steps and Shaping Data) and Write future rows puts them in a table:

• Repeat on dates makes one item per date: every day, week, two weeks, month, three months or year, or every few days, from a start date, for a number of dates or until an end date.
• Find repeating payments finds the payments that repeat in a list of transactions, with how often each repeats, when the next is due and its usual amount.
• Pay down debts plans paying off your debts month by month, highest interest first (avalanche), smallest balance first (snowball) or in your order, until each is zero.

Write future rows asks:

• Which table? The table the rows go in.
• Which rows? Usually the rows the step before shaped, for example Set fields after Repeat on dates, written once for the whole list.
• Keep each row's key in a text field, and Every key starts with a prefix such as bill:. Each row's key is its prefix, a name and its date (bill:Netflix:2026-11-15), so running again updates the same row instead of adding another.
• Date field and Replace rows from (usually today): this step's rows from that day on that the run did not write go to the trash, so a bill you cancelled or a date that moved leaves nothing stale behind. Rows before that day are kept as history, and rows without the prefix (your own) are never touched.

It writes at most 1,000 rows and trashes at most 1,000 a run, and checks your plan's row limit and every value before writing. If the step before it hands on nothing (no repeating payments found), it still runs when Replace rows from is set: it writes nothing and moves this step's rows from that day on to the trash, so a cancelled subscription's upcoming bills don't linger. Without Replace rows from, it changes nothing. A test run shows how many rows it would write, the first few and which rows it would replace, and writes nothing. It asks for tables:write.

A common pattern for upcoming bills: every Monday, Find rows in Transactions from the last six months, Find repeating payments by merchant, Repeat on dates from each one's next date every cycle until 13 weeks from today, Set fields to the bill's name, date, amount and key, then Write future rows replacing from today. Recurring detection works on your own transactions table, so the bill names are your merchants' names.

Feed steps#

• Run a feed starts a sync of a feed you pick, up to 100 a day, and by default waits for it to finish, so the next step has the run's counts (written, skipped, failed) and a failed sync fails the step.
• Read a feed and Read a sync run look up the feed or run a feed trigger names.
• List feeds and List a feed's sync runs go through all of them a page at a time (the newest 100 runs of a feed at most).
• Read a feed's destination names where the feed writes and whether its connection is still there.

The "Alert on reauth", "Send a digest after each run" and "Re-run a feed after reauth" templates use them. Running a feed asks for jobs:write.

Mailbox steps#

Where your workspace has mailboxes:

• Read a mailbox message reads the message behind When mail reaches a mailbox: its sender, subject and text, as the sender wrote them. Read a message's attachments lists its files by name, type and size.
• Release held mail lets a held message through to the mailbox's feeds; Mark a message notes in the mailbox's log what the automation made of it.
• Allow or block a sender adds an address or a domain to the allowed senders, or takes it off, and asks a member to approve it every time it runs. Give a mailbox another address mints a new address (up to 10 a mailbox).
• Send from a mailbox replies to or forwards a message the mailbox received, or writes to a workspace member or someone who confirmed by email, never anyone else, within the workspace's 30 an hour and 200 a day. Send a digest emails one list of what earlier steps found the same way.
• Wait for a reply pauses until the person a send went to writes back to that mailbox, or the hours you set run out.
• Attachments to table rows files each attachment of a message as a row of a table, the file in a files field.

These steps need the member who approves the automation to have edit access to the mailbox (and to the table), and full access to change who may send or to mint an address.

Telling people#

• Notify the workspace puts a notification in the tray of every member, or of its owners and admins, once per run even if the step retries. It asks for notifications:write, is capped per workspace and is never an email.
• Send an email emails people in this workspace at the address they sign in with: Only me (the member who approves the automation, the default), Owners and admins, or Owners, admins and editors. It never takes an address, so it can never email anyone outside the workspace, and someone who can no longer see the automation — or the bank or feed the email is about, which the money templates set for you — is left out when it sends. The subject is one line and the message plain text of up to 2,000 characters; each email comes from BankSync Automations, its subject starts with [Automation in your workspace's name], a web address in the message is shown as text rather than a link, and it links to the automation, where it is switched off. It asks for notifications:write, reaches at most 25 people, sends at most 50 emails a day for each automation and for the workspace, and sends once per run even if the step retries. A test shows what it would send and to whom, and sends nothing.
• Notify on channels tells people by email, Slack or text, using a converted feed's own channels (below). Anyone who can no longer see the workspace is not told.

A feed as an automation#

Feeds keep working as they are, and every new feed is a feed. To build on one, open a sync feed's page and choose Convert to an automation: the dialog shows the steps it becomes and every way it differs before anything is made. The automation does the feed's work in steps you can add to:

• Read bank changes reads what changed in the accounts you choose since the step last read them: new records, a pending transaction that posted, one the bank removed, a new balance or holding. Ids stay the same when a pending transaction posts or the bank changes its ids, so a later step can tell an update from something new. It asks the bank for fresh data at most as often as your plan syncs a feed, and only when the automation may write feeds; otherwise it reads what BankSync already has. A test run never asks the bank. A bank that needs signing in again is not read: the step says so and the automation reads on once you reconnect it. It remembers where it got to only when the whole run finishes, so a run that fails part-way reads the same records again next time.
• Apply enrichments runs your enrichments over those records — categories, rules, merchant clean-up, AI fill where your plan has it — exactly as a feed does. An enrichment it names that is no longer in the workspace stops the step and says which.
• Sync to destination writes them to Google Sheets, Excel, Notion, Airtable, a database, YNAB, a BankSync table, a webhook or an app, through the destination's own connection and with the field mapping you choose. Add new only adds each record once; Add and update, never delete also rewrites a changed record; Mirror also removes what the bank removed; Replace the window keeps a date range exactly in step. Sheets and Excel need the column that holds each record's id to update or remove rows; YNAB only adds; a database adds and updates. In mirror mode, rows to delete are held, not deleted: the step hands them on as held, and only a second Sync to destination behind an Approval step, with deletes set to approved, deletes them. Deleting more than 50 rows (or a tenth of what it wrote) at once waits for someone to approve it. It remembers what it wrote, so a retry, a re-read or a backfill never writes a row twice; if a write fails part-way, what was already written stays recorded and the next run sends only what is missing. A test run lists what it would add, change and delete and writes nothing.
• Notify on channels tells people by email, Slack or text the way the feed's notifications do, checking each person's access when it sends; a retry sends nothing twice, and the run records what was sent and what was skipped (a channel the feed never set up).
• Extract documents reads the receipts, invoices or documents attached to mail that reached a mailbox and hands on what they say, one row per document or line item, for Sync to destination to write. A message of another mailbox, or one whose files were erased, is not read.

Its first run starts where the feed got to, and it remembers what it wrote, so nothing is written twice — not on a retry, a re-read or a backfill. While it is on, the feed's own schedule stands aside and the feed's page says so and links to the automation; turn it off, or delete it, and the feed runs on its own schedule again from where it got to. A converted feed still counts as one feed of your plan; automations you build yourself never do. A feed that replaces rows in a spreadsheet, or reads documents by email or upload, stays a feed — for documents, start from the Receipts from a mailbox to a destination template instead.

These five steps run only inside an automation run, under the grant a member approved; nobody calls them directly, and an API key or an agent cannot. Each step's refusal names what to fix — the destination is not set up, the bank needs signing in again, the enrichment or message is not in this workspace — and the run's history keeps what every step was given and gave.

What is not here#

Only Read bank changes ever asks a bank for fresh data (as often as your plan syncs a feed); no other step starts a sync or hands out a link to sign in again: to run a feed use Run a feed, and to warn people when a bank needs signing in, use Alert on reauth. Feeds, dashboards, widgets, enrichments and banks are not created or changed by an automation. The support steps read a case; replying to support is a person's.