Send new database rows to Slack or Google Sheets

Most of these triggers check your database on a schedule and start one run for each new thing they find. Supabase also has an instant one:

• MySQL ◇ (paid plans) · New row — When a row is added to a table in your MySQL database. Choose the Table and an Increasing column — the id, or a created time — that only grows as rows are added. MariaDB works too. See Start a workflow when a row is added to a MySQL table.
• Supabase · New row — When a row is added to a table in your Supabase project. Choose the Table and an Increasing column — the id, or created_at. With the anon key, it sees only the rows your policies allow. Nothing to set up in Supabase. See Start a workflow when a row is added in Supabase.
• Supabase · Row added, changed or deleted — The moment a row changes, through a Supabase database webhook. Choose the Table (empty takes any table the webhook sends) and, under When a row is, Added, Changed, Deleted or Any. Bizomate shows the trigger's address and a secret; you create a database webhook in Supabase once, with that address as its URL and the secret in a header named X-Bizomate-Secret. Bizomate takes only deliveries that carry the secret. See Start a workflow the moment a row changes in Supabase.
• MongoDB · New document — When a document is added to a MongoDB collection. Choose the Database and the Collection; newest by _id, or by a date field of your own under Newest by. Atlas works too. See Start a workflow when a document is added to MongoDB.
• Amazon S3 ◇ (paid plans) · New object — When an object is added to a bucket. Choose the Bucket, and optionally Starting with to watch one folder, such as incoming/. S3-compatible stores use the same connection. See Start a workflow when an object is added to Amazon S3.

Each new row or document arrives in the run with its columns or fields by name — {{ trigger.customer_email }} — ready for the Sheets and Slack steps. With Row added, changed or deleted, the row's columns are under {{ trigger.row.customer_email }}, with {{ trigger.event }} saying insert, update or delete, and for a change or a deletion the row as it was under {{ trigger.oldRow }}.

Plans. Supabase and MongoDB are on every plan. MySQL and Amazon S3 are premium connections: on any plan, Free included, you can connect them, build the workflow and test it; publishing needs Starter, Pro or Enterprise. See Premium connections on the Free plan.

Try it on your own database. No card needed.

An object in S3 is a file in a bucket — an invoice PDF, a CSV export, a photo — not a row. So New object starts a run for each new file, and the run gets what describes it: the bucket, the key (its full path), the name, the size, the time it was last changed and its ETag. It does not bring the file's contents.

That is often all the team needs — "invoices/NW-20417.pdf arrived, 84 KB" in Slack, and a line in a sheet of files received. To work with the file itself, add Amazon S3 · Download a file with {{ trigger.key }}. To give people a link, Amazon S3 · Get a presigned URL makes one that stops working after a time you set.

One difference from rows: new means a newer modified time, so a file replaced at the same key counts as new again and starts another run. See Work with Amazon S3.

The triggers that check — MySQL · New row, Supabase · New row, MongoDB · New document and Amazon S3 · New object — are not instant.

• How often. You choose Every 5 minutes or Every 15 minutes. On the Free plan, MongoDB and Supabase's New row check every 15 minutes whatever is chosen. A row added at 10:01 reaches Slack at the next check.
• Only what is new. The first check after you publish only notes where the table stands. Rows, documents or files already there never start a run.
• Up to 100 per check. If more arrive between checks, the first 100 start runs, oldest first; the rest wait for the next check, in order.
• New, not changed. For the triggers that check, an updated row or document does not start a run.

For Supabase, if a check every few minutes is too slow, use Supabase · Row added, changed or deleted instead. Supabase sends each change to Bizomate through a database webhook — a webhook is the link that lets a service tell Bizomate something happened — and the run starts within seconds, with no check in between: each change starts one run. It can also start on a changed or deleted row, which New row never does. See Start a workflow the moment a row changes in Supabase.

Slack · Post a message — Posts to a channel in Slack. Choose the Channel and write the Message, with values from the row in {{ }}: New order {{ trigger.order_number }} from {{ trigger.customer_name }}. Slack's own formatting works — *bold*, _italic_. It posts as the Bizomate app, or as you with Post as me.

A private channel needs Bizomate in it first: type /invite @Bizomate in the channel. Optional Buttons add a link — to the order in your own system, say. Buttons open a link; they do not reply to the workflow. See Post a message to Slack and Connect Slack.

Google Sheets · Add a row — Adds a row to the end of a Google Sheet. Give the sheet headings in its first row — Order, Customer, Items, Received — pick the spreadsheet and the tab, and each heading appears with a box for its value from the trigger. A column left empty stays empty. Bizomate sees only the spreadsheets you pick. See Add a row to Google Sheets.

• A connection of its own. MySQL takes the server, database, user and password, encrypted with TLS; Supabase takes the project URL and an API key; MongoDB takes a mongodb:// or mongodb+srv:// connection string; Amazon S3 takes an access key, secret and region. Give each the least it needs to read what the trigger watches.
• On the public internet. Bizomate connects from its own servers and refuses private and loopback addresses, so a database on an office network, behind a VPN or on your own computer cannot be reached. If your database lets in only listed addresses, allow Bizomate's outgoing addresses — each connection's help article lists them.

See Connect a MySQL or MariaDB database, Connect Supabase, Connect MongoDB and Connect Amazon S3 or an S3-compatible store.

Bizomate counts runs, not steps. Each new row, document or file starts one run, and that run counts once however many steps it has — posting to Slack and adding to a sheet is still one run. A check that finds nothing starts no run and costs nothing, and test runs do not count. So the number to estimate is how many new rows arrive in a month. See What counts as a run.

Every run leaves a record: the row that started it, what was added to the sheet and what was posted, or which step failed and why. The run history is kept for 7 days on Free, 30 on Starter, 90 on Pro and without limit on Enterprise; each step's input and output is kept for 7 days on every plan.

To write into a database instead of reading from one, read How to save what your website sends into a database; for a summary once a week rather than a message per row, How to send a weekly report from your PostgreSQL database.