Automations

An automation sends a message to a channel your team already uses when something happens on the platform. It is the answer to "a call finished, tell sales" without standing up a server to receive a webhook.

Automations run after the event, in the background. Nothing is added to the conversation itself, so a slow Slack cannot make a caller wait.

Connections

An automation sends to a connection: one configured destination, added under Settings - Integrations.

Add one connection per destination and name it after where it goes. A Slack incoming webhook URL is bound to a single channel, so "Sales" and "Support" are two connections, not one.

The generic Webhook connection is also how you reach anything else: point it at a Zapier, Make or n8n hook and the rest of that catalog is available without any further setup here.

Building a rule

A rule is three choices and a message.

1. When - any event from the webhook catalog. session.completed is the usual one; it carries the whole end-of-call report.
2. Send to - one of your connections.
3. The message - written with {{dotted.paths}} filled in from the event.

New call from {{variables.name}}
Outcome: {{analysis.summary}}
Cost: {{cost.total}}

Anything in the event payload can be referenced. For session.completed that includes session_uuid, workflow_uuid, status, transcript, variables, analysis, latency and cost. A path that does not exist renders as an empty string rather than failing, and each field is truncated so a long transcript cannot flood a channel.

Call recordings are deliberately not among them. An automation posts what it renders into a channel or a third-party endpoint, so a playable link would be a credential forwarded out of your workspace and kept in whatever received it. Send {{session_uuid}} instead and fetch the recording from the session with your API key.

Narrowing when it fires

Two optional conditions, both off by default:

• Only one agent - the rule ignores every other agent's calls.
• Only calls that met their goal (or only the ones that did not) - reads the success flag from post-call analysis, so it needs analysis enabled on the agent.

Testing and history

Send test renders your template against your newest finished call and really delivers it, so what you verify is the whole path rather than a preview. Conditions are not applied to a test.

Every firing is recorded with its outcome, duration and any error, so a rule that stopped working is visible without reproducing the call that triggered it.

Limits

• Up to 20 automations run per event.
• Each message field is truncated at 4,000 characters.
• The most recent 100 runs are kept per automation.