Automations overview

Last updated Aug 2026

Automations

All plans

When something happens anywhere in your workspace — a contact’s engagement changes, a deal moves, a booking is confirmed, an order is paid — do something automatically. One engine reads from every service you use, so a rule can react to real business events instead of just email opens.

A rule, in plain language

WHEN an order is paid and its value is over $500

↓

THEN move the deal to Won, and notify me by email

Triggers — the "When"

Twelve sources, spanning every part of the workspace:

Group	Fires when…
Contacts	A contact's engagement reaches a stage, goes inactive, or N days pass since joining a list.
CRM	A deal moves to a specific stage, or is marked Won or Lost.
Booking	A booking is confirmed, cancelled, rescheduled, or marked a no-show.
Campaigns	A contact opens or clicks a campaign.
Paid Pages	A buyer is granted access, access is revoked, or a payment goes past due.
Orders	An order is paid, refunded, or a product runs out of stock.
Communities	A review or a comment is posted.
Inbox	An email is received (optionally filtered by address, sender, or subject).
Events	Someone RSVPs to an event, or cancels their RSVP.
Signups	Someone signs up through a Sign Up CTA block.
Forms	A Form block is submitted.
Content	A page is published — either to self-notify, or to send a real Campaign straight to a subscriber list.

✦

Booking, CRM, and Orders sources support value-based conditions — e.g. only fire when a deal is worth more than a threshold, not just "any deal was won."

Combining conditions

A single rule can react to more than one trigger, combined with Any (OR) or All (AND):


Any (OR)	Fires the instant ANY one of the listed conditions' own event happens — no extra check needed.
All (AND)	The event that just happened must be one of the listed conditions, AND every other listed condition must ALSO currently be true — checked live at the moment of firing, not assumed.

Actions — the "Then"

Send an email

A saved template, or write one inline right there in the rule — either way it can use variables like the contact's name.

Move (or create) a CRM deal

Moves the contact's existing deal in a pipeline, or creates one if they don't have one yet — value auto-fills from a real order when the deal is new (see the CRM docs).

Notify me

An in-app bell notification, or an email — to your own account, a specific team member, or a custom email address of your choice (e.g. a personal Gmail you actually check).

Request a review

Sends a link to a page's review section — the outbound counterpart to the "a review is posted" trigger.

Wait

Pauses the rule for a set amount of time before continuing, optionally restricted to business hours only.

Change engagement score

Increment, decrement, or set a contact's score directly — the same score other automations can read as a condition.

Enroll / remove from another automation

Chain automations together. A built-in depth limit stops an accidental A-enrolls-B-enrolls-A loop from running forever.

Multiple actions, and real branching

Chain several actions in one rule

Add as many actions as you need — every one of them runs when the rule fires, even if one of them fails partway through.

Or branch — if this, do X; else, do Y

Switch a rule into branching mode to route it down different paths based on a real condition, e.g. an order over $500 gets one treatment and everything else gets another — all in one rule instead of three separate ones. The first branch whose condition is true wins; an "Else" branch is the mandatory fallback.

A branching rule

if {OrderValue} > 500

→ Move deal to VIP · Notify me

else

→ Send "Thanks for your order" email

Variables

Branch conditions and action text can reference real data from whatever just fired — click a variable chip instead of typing the token by hand. What’s available depends on the trigger: a booking exposes {CalendarId}, an order exposes {OrderValue}, a deal exposes {DealValue}, an event exposes {EventTitle}, and every trigger exposes {ContactStage}, {ContactScore}, and {TriggerSource} (which of several OR’d conditions actually fired).

System automations — the built-in sends

Four transactional emails this app can send automatically — order confirmation, shipping notification, booking confirmation, and booking reminder — are themselves real rows on this page, not hardcoded and unturnable-off.


On by default	The first time each event type happens on your account, its row appears here automatically, already switched on.
Turn one off	Use the row's On/Off toggle. Deleting the row instead doesn't permanently disable the send — the next real event re-creates it, enabled again — so use the toggle, not delete, to actually turn one off.
Custom templates	Each of the four can optionally use a template you build yourself instead of the default design — set that from Settings → Email, not from this page.

Team permissions

On a reseller (White Label) account, Automations is its own separate team permission — off by default for every new team member, independent of every other feature toggle. See team members & client access.

Troubleshooting

Symptom	What it means
A rule doesn't seem to have fired	Check the row's Activity log first — it records every firing attempt, including failures with the real error, rather than failing silently.
A system automation (order confirmation etc.) isn't showing up in the list	Expected until the first real event of that type happens on your account — these rows are seeded on first use, not present from day one.
I deleted a system automation row but the email is still sending	Expected — delete re-seeds it enabled on the next event. Use the On/Off toggle to actually disable it.
An "All (AND)" rule isn't firing even though I think both conditions are true	The non-triggering condition is checked live at the moment of firing — if it was true earlier but has since changed, the rule correctly won't fire.

← PreviousCRM overview Next →Canvas view