Form actions
Form actions are automations
A form action is an automation that runs the moment a form is submitted. After the submission is validated and stored, BusinessDash can do something with it — subscribe the person, email them back, notify an external system, or remove them from a list. They're the configurable version of BusinessDash's built-in lead/inquiry mirrors: you pick the behavior, map it to your fields, and (optionally) gate it on a condition.
Automations run server-side, on every channel the form can be submitted through — your website, the API/SDK, the chatbot, and the careers/job-application flow — so they fire no matter where the submission came from, in addition to the built-in lead/inquiry mirrors.
The automations you can run
| Action | What it automates | Needs |
|---|---|---|
| Add to Followers | Subscribes the submitter to this org's followers list | An email field (optionally a name) |
| Unsubscribe | Removes the submitter from the followers list | An email field |
| Send Webhook | POSTs the submission to an external URL, HMAC-signed | A URL (https) + an optional signing secret |
| Autoresponder Email | Emails a confirmation back to the submitter | An email field; a subject + body |
| Create database records | Writes the submission into your custom database — one row, or several linked rows at once | A promoted custom collection |
Examples
A few automations teams set up:
- Newsletter sign-up → Add to Followers. An email-capture form subscribes everyone who submits.
- Contact form → Autoresponder Email. Send an instant "we got your message" so nobody wonders whether it went through.
- Lead form → Send Webhook. Forward every lead to Zapier / Make / your own CRM endpoint — signed, so the receiver can trust it came from you.
- "Unsubscribe me" form → Unsubscribe. A one-field email form that takes people off your followers list.
- "Add a technology" form → Create database records. One submission creates a Technology row, its Icon row, and its Logo row — already linked to each other — instead of someone hand-editing three tables.
- Conditional routing. Send Webhook only when "Budget" is greater than 10000 to ping your sales channel for big deals, or Autoresponder only when "How did you hear about us" equals "Referral" with a referral-specific reply.
Walk-through: a welcome autoresponder, A → Z
Let's automate a confirmation email on a contact form.
Open the form's actions
Open your form in the builder. On the right of the canvas is the Wiring panel — it holds Output Mapping, ⚡ Form Actions, and Staff. Expand it with the tab on its edge, then open the Form Actions section. (The Wiring panel is on both the form builder and the quiz builder.)
Add an action
Click + Add action. A new action card appears, defaulted to Add to Followers and toggled On.
Choose the automation
In the card's type dropdown, pick Autoresponder Email. The card updates to show what this automation needs, with a short hint describing it.
Map the inputs
Set the Email input to your form's email field — required inputs are marked with a red asterisk. Optionally map Name to a name field so you can greet people by name.
Write the email
Fill in the Email subject and the body. Personalize it with the tokens
{{name}}, {{email}}, and {{formName}}:
Subject: Thanks for reaching out!
Body: Hi {{name}}, we got your message and will reply shortly.
(Optional) Add a condition
Flip Only run on a condition if the automation should be selective, then pick a field, an operator, and a value — e.g. only email when a "Subscribe me to updates" checkbox is checked.
Confirm it's on and valid
Leave the On switch enabled. If anything's missing — an unmapped required input, a blank subject — an inline red warning appears and blocks saving until it's fixed. Otherwise your changes save automatically.
That's it: every contact-form submission now triggers the welcome email, automatically, across every channel the form is reachable from.
Create database records — one form, several linked rows
The Create database records action writes a submission into your custom database. The simple case is one row: map form fields to the collection's fields and every submission becomes a record.
The reason this action exists, though, is the compound case. Real entries rarely live in one table — adding a "technology" to a portfolio might mean a row in Technologies, a row in Icons, and a row in Logos, with the icon and logo pointing back at the technology. Without this action that's three manual inserts plus hand-wired links; with it, one form submission creates the whole cluster atomically — if any row fails, none are written, so you never get an icon pointing at a technology that doesn't exist.
In short: each entry is one row to create; you map its fields to form fields; and an entry with a relation field links it to another entry.
Build a two-table form, step by step
Say a "New technology" form should create a Technology row and a
Technology Logo row that points back at it (the logo's technology relation
field). Both are promoted custom collections.
Add the action
In the Form Actions section of the Wiring panel, click + Add action and set the type to Create database records.
Entry 1 — the parent (Table 1)
Click + Add entry and pick the Technologies collection. It's given a short
alias like technology. Map each collection field to the form field that fills
it — e.g. Company name → your Name field, Category → your Category dropdown.
Entry 2 — the child (Table 2)
Click + Add entry again and pick Technology Logos. Map its fields the same
way. Leave its relation field (technology) out of the field map — you don't
give it a value, you connect it in the next step.
Link the child to the parent
On the Technology Logos entry, check the link box technology → $technology.
That wires the logo's relation field to the Technology entry created in the same
submission. The $alias is a deferred reference — a stand-in for a row that has
no id until it's inserted.
Save
Done. On every submit, BusinessDash creates both rows and writes the link in one transaction — if either row fails, neither is written, so a logo never points at a technology that doesn't exist.
The link checkbox only appears when an entry has a relation field whose target is another entry's collection. So for the link above to show, Technology Logos must have a relation field pointing at Technologies. Define the relation on the collection first (see Data Relations).
Chaining across three or more tables
An entry can link to any other entry, so longer chains work exactly like the two-table case — just add more entries and more link checkboxes:
- Table 3 → Table 2 → Table 1. On Table 2's entry, check its relation link
→ $table1; on Table 3's entry, check its relation link→ $table2. There's no ordering to think about — every row is created first, then all the links are written, so a link never needs its target to exist yet. - Mutual links are fine too (Table 1 ↔ Table 2 each pointing at the other) — the same create-all-then-link-all pass handles cycles without complaint.
Each link is simply "this entry's relation field → that entry's $alias," so you
can wire whatever graph your collections describe in a single submission.
This is the same action the dashboard's Quick-Add widgets run: a widget is just a button that opens one of your forms, and the form's Create database records action does the writing. Build the form + action once and it works from your website, the API, and the dashboard widget alike.
Conditions
An automation with no condition always runs. Add one to make it selective — it checks a single field against an operator:
| Operator | Runs when the field… |
|---|---|
| equals / not equals | matches / doesn't match a value |
| contains | contains the text (case-insensitive) |
| greater than / less than | is greater / less than a number |
| is empty / is not empty | has no value / has a value |
(is empty and is not empty don't take a comparison value.)
What to expect — with vs. without
- Without any actions: a submission is validated and stored, and the built-in lead/inquiry mirrors run if you've enabled their toggles. Nothing else happens.
- With actions: after the submission is stored, each enabled action whose condition passes (or that has no condition) fires — so one submission can subscribe the person, email them, and notify an external system, automatically, on every channel.
Automations fire on every successful submission across every entry point. Use a condition when one should only run for some submissions, and double-check webhook URLs and autoresponder copy before publishing — they go out for real.