Your app already writes its orders, sign-ups and events to MongoDB. Bizomate reads and writes your collections from any workflow — filters, updates and aggregation pipelines in JSON, with values from earlier steps put in as values — and starts a workflow when a new document appears. Every run leaves a record of what it ran and what came back.
| Label | Value |
|---|---|
| Plans | Every plan |
| Connect | A connection string — mongodb://, or mongodb+srv:// for Atlas |
| Starts runs | Every 5 minutes (15 on Free) |
| Kind | Connected app · Database |
Choose the database and the collection; newest by _id, or by a date field you name under Newest by. Documents already there never start a run, and neither does a changed one; up to 100 new documents start runs in one check, oldest first.
The filter, the fields to return and the sort in JSON. 1,000 documents by default, up to 10,000.
Fields to set, or the update in JSON with operators only, so a document is never replaced whole. The first match or every match, and Add one when none matches if you want it.
Always needs a filter. Deleted documents cannot be brought back.
Yes. In Atlas, open your cluster's Connect › Drivers, copy the mongodb+srv:// string, put the user's password in it, and paste it into Bizomate. Then add Bizomate's addresses, listed in the connect article, under Network Access.
Only what the workflows need: read on a database to find and count documents, readWrite to insert, update and delete them. Give it a role only on the databases your workflows use.
Write the filter as JSON and put a value from an earlier step in quotes. Bizomate puts it in as a value, keeping its type, and stops the step if the value holds a MongoDB operator — so data from a form or an email cannot change what the filter means.
A database user with a password — SCRAM, MongoDB's usual sign-in. Sign-in by certificate, cloud identity or Kerberos is not used.
Each new row, posted to Slack and added to a sheet.
