Use Automations for work that should happen after a business event or on a recurring schedule: notifying a team when a record changes, forwarding an event to another system, or sending a regular report.
The page separates three questions: When this happens defines event subscriptions, On a rhythm defines schedules, and What fired shows recorded business events. Viewing this area and managing its rules require the relevant account access.
Choose an event that is available
Open Automations and select When this happens → New subscription.
- Choose the event under When. Record changes and approval events currently publish; options marked not published yet will not trigger simply because you select them.
- Choose the action: a message flow, notification, webhook, or agent task.
- Enter its required target, such as a flow identifier, notification audience, or HTTPS webhook URL.
- Give the subscription a recognizable name under Called.
- Add an optional condition, save, and test one controlled event before relying on it.
For a record workflow, create a test row, inspect its event in What fired, and use the actual payload fields in your condition. For example, narrow a status-change event to a particular table:
{"all":[{"column":"table.slug","op":"equals","value":"service-requests"}]}
Replace the example slug with your own. Conditions are JSON, so field names and punctuation matter. An event being recorded does not prove an external receiver finished processing it; verify the target outcome too.
A flow subscription also needs an existing conversation ID in the event. If your record stores that ID in conversation_id, set Extras to {"conversation_path":"record.conversation_id"}. A flow target alone cannot start a conversation; an event without the required ID is skipped. Use a notification or webhook for your first record-event test if you do not have a conversation to resume.
Schedule recurring work
Under On a rhythm, choose New schedule. Select the action under Does, then configure Every, the time or weekdays, the target under To, and the action's Details.
Actions include sending a report, writing a record, starting a flow, sending an SMS or WhatsApp message, and calling a contact group. Each needs the relevant configured channel, published flow, table, or calling setup.
For a controlled SMS test, choose Send a message, use your own authorized test number as To, and provide:
{"channel":"sms","body":"Test reminder for {{slot_date}} at {{slot_time}}."}
The placeholders use the scheduled run's date and time. New schedules use the account timezone, falling back to Africa/Dar_es_Salaam when none is set. Check the displayed rhythm and next run before enabling it. Monthly schedules use days 1–28.
Choose how missed runs should behave: run once late, skip missed work, or catch up on missed occurrences. Catch-up can produce several actions, so consider whether that fits customer messages.
Test and monitor
Run now performs the schedule's real action. Use a test recipient or record and review the result before applying it to customers. A run can successfully start a message or call that later fails delivery; inspect the resulting message, call, or flow for its final outcome.
For subscriptions, review firing times, counters, and errors. Repeated failures can switch a subscription off. Use Switch off while correcting a target or condition, then re-enable it after testing.
For webhooks, use Signing secret to configure verification at your receiver, keep the secret private, and follow the automation webhook contract. Its signature differs from communication webhooks.
If nothing runs, check whether the event publishes, the rule is on, the condition matches, and the target exists. If timing is wrong, check the rhythm, timezone, and missed-run policy before creating a duplicate schedule.
Separate reply automation from recurring business work
Use Accounts → Automations to choose the normal AI agent or message flow for a connected account. Use Inbox to make an exception for one chat. Event subscriptions and schedules serve a different purpose: they start work because a business event occurred or a time arrived.
For example, an account's flow can collect a service request, while a record-change subscription notifies a supervisor when that request reaches a review stage. Configure and test each part independently so a missing notification is not mistaken for a broken conversation flow.
Plan for retries and duplicate events
Use the event or record reference when checking whether an action already happened. A webhook receiver should remember processed event identifiers where supplied and handle repeat deliveries safely. For a customer message, inspect the existing outcome before triggering the same work manually.
Keep an initial schedule pointed at a test target through at least one scheduled occurrence. A successful Run now check proves the action can run; it does not confirm your chosen timezone and missed-run behavior produce the intended timing.