Automation rules
Trigger something when something happens. "When a deal moves to Won, email the customer this template and send a Slack ping to my team."
Anatomy of a rule
Every rule has three parts:
- Trigger — the event ("Deal won," "Form submitted," "Booking created," "24h before booking").
- Filter (optional) — only run when the data matches ("only deals over $1,000," "only bookings of type 'install'").
- Actions — one or more things to do (send email, create task, hit a webhook, run an agent, send SMS).
Building one
Automations → "New rule." The builder is visual: pick a trigger, optionally add a filter, drag actions into the sequence. Save → it's live.
Through Claude Code
"When a deal moves to 'Job done,' wait 3 days, then send the review-request email template. Skip if the deal value is under $200."
Common triggers
- Contact created / updated / tag added
- Deal stage changed / value updated / won / lost
- Booking created / rescheduled / cancelled / completed
- Form submitted
- Time-based (every Monday 8am, 30 days after deal won)
- Custom webhook (a third-party system POSTs to a SeldonFrame webhook URL)
Common actions
- Send email (template or one-off)
- Send SMS (via Twilio)
- Create / update / move a deal
- Add a tag / change a stage
- Create a task for a teammate
- POST to a webhook (Slack, Zapier, your own backend)
- Run an agent step (e.g. ask the AI agent to draft a follow-up email)
Durable workflows under the hood
Long-running rules (anything with a wait step longer than a few seconds) run on Vercel Workflows — they survive deploys, retries on failure, and are observable in your dashboard. The 24h post-booking reminder is the canonical example; see Post-booking reminders.