Enders are automation rules that perform actions on conversations when specific events occur. Each Ender follows a simple "if this, then that" pattern: you define a trigger (the event that starts the automation), optional conditions (filters that narrow which conversations qualify), and one or more actions (what the Ender does when triggered).

Use Enders to automate repetitive tasks such as sending notifications when new conversations arrive, running automated quality assessments, categorizing conversations by topic, or adding conversations to a reviewer's to-do list.

Enders require the Enders / Automation Management permission. Users without this permission cannot view, create, or manage Enders.

The Run Historical action and the webhook Preview / Send Test actions additionally require the Conversations View permission.

The Enders list shows all your automation rules with their name, creator, last edit date, active status, team, and labels.

Filter selections are remembered between visits.

In the if section, select a trigger from the Trigger when dropdown:

The selected trigger determines which condition filters are available. Some filters are only available with specific triggers:

Each of the CSAT and Intensity filters only matches when the triggering summary is of the same type — an Intensity-filtered Ender will not fire when a CSAT summary arrives, and vice versa. Pick the filter that matches the summary you want to react to.

Use Search by itself to match the whole conversation, including its transcript, comments, and summaries. On New summary added, Search alone is evaluated again for every new summary and may repeat actions while the conversation still matches. Add Summary prompt to check only the newly added summary.

Use the Summary prompt filter to make the Ender act only when the triggering summary was generated by one of the summarisation prompts you select. This is useful when you maintain several summarisation prompts and want different actions (for example, sending a webhook or running categorisation) to run only for specific summaries.

For a paired Ender, independently matching summaries can each add a comment. While a notification is pending, the same conversation and prompt do not queue another notification for the same Ender action and recipient. Overlapping groups include only pairs that are not already pending; after delivery, that pair can notify again.

After selecting a trigger, click condition to add filters that narrow which conversations the Ender acts on. Available filters include agent, tags, topics, direction, duration, language, and many others. Some filters are trigger-specific — see the trigger-specific filters table above for details.

You can add multiple conditions. Only conversations matching all conditions will trigger the Ender's actions.

Use the Open Conversations button to preview which conversations currently match your conditions in the Conversations view.

Certain trigger and filter combinations can cause an Ender to never fire. The system displays warnings in the edit view and a warning icon in the list view when it detects these situations:

When trigger or filter compatibility issues are detected, a warning icon appears next to the Ender's name in the list view with the tooltip: "This Ender may require reconfiguration. Open it to see details." This reconfiguration icon only appears for active, non-archived Enders — deactivated or archived Enders do not show it. The unsupported-filters warning icon appears regardless of the Ender's active or archived status.

In the then section, choose one or more actions for the Ender to perform. Click the + button below the action list to add more actions. Each action runs in sequence. To remove an action, click the X button next to it.

Sends an email notification to specified recipients. Select internal users or type external email addresses directly. Choose a delivery frequency: immediately, or grouped at 1-hour, 8-hour, or 24-hour intervals.

Expand the Advanced — include in email panel to control which sections appear in the email body. Each section has its own checkbox:

A chip next to the panel title shows how many sections are currently selected out of the total. By default, Topics, Summary, and QA scores are included, and CSI is not. The CSI section is rendered only when the conversation actually has a CSI value — if the conversation has no CSI, or your organization does not use CSI at all, the email omits the CSI line even when the checkbox is on. Other sections behave the same way: a section is included in the email only when there is data to show.

Runs rule-based automated quality assessment using a selected scorecard. After choosing a scorecard, you can open the default scores dialog to pre-set specific scores and optional comments for individual scoring points. Enable Post Score to publish the result automatically.

Runs generative AI-powered quality assessment. Requires a Gen AI provider API key in your organization's settings. Select a scorecard and a Gen AI prompt. You can configure which scoring points to evaluate: Full Mode evaluates all points, while Partial Mode lets you choose specific points. Set a default score (N/A, Max, or Min) for points that are not evaluated.

Generates an AI-powered conversation summary using a selected Gen AI prompt. Requires a Gen AI provider API key in your organization's settings. If the selected prompt has been archived, the action cannot run until a valid prompt is chosen.

Runs topic categorisation on the conversation. Select which categories to apply — you can choose individual categories, or use the quick-select options: All Categories, All Categories (Rules), or All Categories (LLM). Use the label filter to narrow the list by category labels. If any LLM-based categories are selected, you must also choose a Gen AI prompt.

Automatically adds a text comment to the conversation. Enter the comment text in the provided field.

Adds the conversation to a reviewer's to-do list. Configure:

Sends conversation data to an external URL over HTTP. The webhook editor is split into three tabs: Destination, Request Body, and Preview.

The host name is checked again each time a request is sent, including test sends and retries. Every address the host name resolves to must be public; if any of them is private or internal, or the name cannot be resolved, the request is not sent. Each request then goes only to one of those checked addresses.

You can also use conversation-specific placeholders in the path or query string, for example https://example.com/tickets/{{additional_info.ticket_system_id}}. Placeholders use JSONata expressions evaluated against the standard webhook payload, so both {{additional_info.ticket_system_id}} and {{$.additional_info.ticket_system_id}} work. Placeholder values are percent-encoded before substitution, and placeholders are not allowed in the scheme, host, credentials, port, or fragment.

Before upgrading an existing installation, review saved webhook URLs containing literal {{ or }}. A balanced {{...}} sequence is interpreted as a placeholder after this feature is enabled; percent-encode literal braces as %7B and %7D when placeholder evaluation is not intended.

Keep these delivery rules in mind:

Switch between Standard Payload and Custom Mapping:

Click Validate to check the expression. Validation parses the expression and evaluates it against an empty payload — it fails if the expression is invalid, errors at runtime, or returns anything other than a JSON object (for example, a scalar or array). Custom mapping has runtime limits: $eval() and user-defined function declarations are disabled, but $parseJson() is available for parsing JSON strings.

If you switch back to Standard Payload but the custom mapping is still set to a non-default expression, saving the Ender prompts for confirmation before the custom mapping is discarded.

Use the Preview tab to verify how a real conversation will look when sent to your endpoint:

When the Ender pairs Search with Summary prompt, the conversation list is not available because the pair matches only newly added summaries. Type a conversation ID to preview the payload instead.

If a placeholder points to a missing or empty value, the preview and delivery fail before anything is sent so you can fix the configuration instead of sending a malformed URL.

When editing an existing Ender, the right panel shows the History of saved versions. Click any version to view its configuration. The editor becomes read-only when viewing a past version. Select the Current version to return to the latest saved state and resume editing.

You can retroactively apply an Ender to conversations that already exist:

The maximum number of sessions per historical run is 20,000. If more sessions match, narrow the date range or add more filters.

Run Historical requires that the Ender is saved (no unsaved changes) and that you have the Conversations View permission. It is unavailable for Enders that pair Search with Summary prompt, because that pair checks summaries only as they are added.

Enders are automatically labeled based on their action types: Notification, Scoring, AutoQA, Summary, Categorisation, Comment, TODO, and Webhook. You can also add custom labels from the list view to organize Enders by purpose or project.

Some conversations arrive with no transcript content — for example, uploaded calls that were too short or too small to be transcribed. These still carry metadata (agent, direction, duration, caller information, and so on) and can still trigger Enders, but individual actions that need transcript text will not run on them.

When an Ender fires on a conversation with no transcript text:

Skipped actions produce no session activity entry and no scorecard, summary, or topic result for that conversation. Actions earlier or later in the same Ender continue to run — the skip only affects the transcript-dependent action itself.

Some actions produce new events on the conversation they act on — for example, Add Comment creates a comment event, Set Topics and Summary update the conversation, and Auto QA actions add scores. Without protection, an Ender whose trigger matches its own output could re-fire on the event it just produced, creating a loop.

To prevent this, an Ender is skipped when it would fire on an event caused by its own earlier action on that conversation, either directly or through other Enders. Concretely:

This protection is automatic and applies to all triggers and actions — there is no setting to configure. Chains between Enders remain supported; an Ender cannot trigger itself again through its own chain of changes.