> ## Documentation Index > Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt > Use this file to discover all available pages before exploring further. # Notification Triggers & System Automations > Run automations when app notifications fire, use the notification context in your steps, and manage the built-in Emergency SMS and email alert automations. Notification Created triggers and the notification automations described on this page are available to **beta testers only**. If your team is interested in joining the beta program, reach out to the Voxworks team. ## What are notification automations? Voxworks publishes an account-wide feed of notifications — calls finishing, batches starting and completing, dispatch delays, billing alerts. They appear in the bell at the top of the app and in the **Activity** panel on your Dashboard. The **Notification Created** trigger connects this feed to your automations: whenever a notification fires, any enabled automation with a matching Notification Created trigger runs its pipeline. This is how Voxworks delivers every outbound alert — there is no separate notification-delivery system. Every account comes seeded with two system automations built on this trigger, **Emergency SMS alerts** and **Emergency email alerts**, which escalate critical notifications by text and email. You edit them like any other automation; you cannot delete them. This page covers the trigger and its filters, the `notification.*` context your steps can use, the catalogue of notification event types, the two system automations, and how event muting interacts with all of it. *** ## The Notification Created trigger Create one from the Automations page: click **New Automation**, then choose **Notification Created** — described in the create modal as "Runs when an app notification fires (filter by severity/event)" — and click **Create & Configure**. In the automations table the trigger column shows **Notification**. The trigger configuration has two optional filters. Leave both empty and the automation runs for every notification the account creates. | Setting | Description | Default | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | | **Severity Filter (optional)** | Checkboxes for `info`, `success`, `warning`, and `critical`. The automation only runs for notifications whose severity is ticked. "Leave empty to trigger for all severities." | Empty (all severities) | | **Event Type Filter (optional)** | Comma-separated event types, e.g. `call.emergency, batch.failed`. The automation only runs for notifications whose event type appears in the list. "Leave empty to trigger for all events." | Empty (all events) | Event-type matching is exact — enter the full `domain.event` string for each type you want. Wildcards such as `call.*` are not supported. **Firing behaviour:** * Each matching notification starts exactly one execution per automation — repeats are suppressed, so a retried delivery never double-fires your pipeline. * Notifications themselves are duplicate-suppressed at the source (for example, dispatch delays raise at most one notification per batch per hour), so noisy conditions do not flood your automations. * **Loop guard:** notifications generated as a side effect of an automation execution never trigger Notification Created automations, so pipelines cannot set off chain reactions. * Muted event types never fire the trigger at all — see [Event muting](#event-muting-and-notification-settings) below. * Only **Enabled** automations are matched when the notification is created, and the enabled state is checked again when the run executes — switching an automation to **Disabled** also stops any queued runs, which complete as skipped. Executions appear in the [Execution Log](/automations/execution-log) like any other automation run, with the notification as the trigger data. *** ## The notification context When a Notification Created automation runs, the notification record is loaded into the pipeline context under `notification.*`. Reference these fields in step templates (SMS bodies, email subjects and bodies, webhook payloads), field mappings, and Condition steps. | Field | Type | Example | Description | | -------------------------- | ------ | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | `notification.id` | number | `4182` | The notification's identifier. | | `notification.event_type` | string | `"batch.failed"` | Namespaced event type in `domain.event` form. | | `notification.severity` | string | `"critical"` | One of `info`, `success`, `warning`, `critical`. | | `notification.title` | string | `"Batch \"May renewals\" failed"` | Short headline shown in the bell and the Activity panel. | | `notification.body` | string | `"Batch failed: no calls could be dispatched."` | The full notification message. | | `notification.link` | string | `"/home/acme/batches"` | App-relative link to the page the notification is about (may be empty). | | `notification.entity_type` | string | `"batch"` | The kind of record the notification refers to, e.g. `call` or `batch` (may be empty). | | `notification.entity_id` | string | `"b7e2c9d4-..."` | Identifier of that record (may be empty). | | `notification.payload` | JSON | `{"batch_id": "b7e2c9d4-...", "error_message": "No calls could be dispatched."}` | Event-specific data fields — see the payload column in the catalogue below. | Dot into the payload for event-specific values — for example `{{notification.payload.delayed_count}}` (number, e.g. `12`) in a `dispatch.delayed` alert, or `{{notification.payload.remaining_minutes}}` (number, e.g. `14`) in a billing alert. A reference that does not resolve renders as an empty string in automation templates. A Condition step can branch on any of these fields — for example, field `notification.event_type` equals `batch.failed` to route batch failures to a different channel. See [Conditions](/automations/conditions). *** ## Event-type catalogue Every notification carries a severity and a namespaced event type. ### Severities | Severity | Meaning | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `info` | Routine processing update — listed quietly in the bell and the Activity panel. | | `success` | A positive completion, such as a finished batch. | | `warning` | Needs attention soon — a degraded state such as delayed dispatch or low credits. | | `critical` | Act now — highlighted in red, pinned until a team member acknowledges it, and escalated by the default emergency automations. Critical events can never be muted. | ### Event types These event types fire today: | Event type | Severity | When it fires | Noise control | Payload fields | | --------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------- | ------------------------------------ | | `call.completed` | info | A call that is not part of a batch reaches a final status other than failed. Batch calls roll up into the `batch.*` events instead. | Once per call | `call_id`, `status`, `duration` | | `call.failed` | warning | A non-batch call ends with the failed status. | Once per call | `call_id`, `end_reason` | | `batch.started` | info | A batch begins running. | Once per batch | `batch_id`, `total_calls` | | `batch.completed` | success | A batch finishes processing. | Once per batch | `batch_id`, `total_calls` | | `batch.failed` | critical | A batch fails. | Once per batch | `batch_id`, `error_message` | | `dispatch.delayed` | warning | Queued batch calls are waiting past their scheduled time, usually because the account is at its concurrency limit. | Once per batch per hour | `batch_id`, `delayed_count`, `cause` | | `billing.low_credits` | warning | On plans with a minute-credit allowance, remaining credits drop below 20%, and again below 5%. Visible only to members with billing permissions. | Once per threshold per billing period | `threshold_pct`, `remaining_minutes` | | `billing.credits_exhausted` | critical | The team has used all of its minute credits for the billing period. Visible only to members with billing permissions. | Once per billing period | `remaining_minutes` | The catalogue is extensible without app changes, so new event types appear over time. AI-detected call emergency and follow-up events (`call.emergency`, `call.followup_requested`) and automation failure alerts (`automation.dead_letter`) are coming soon. Notifications age out of the feed automatically: `info` and `success` notifications after 30 days, `warning` and `critical` after 90 days. Automations are unaffected — they run at the moment the notification is created. For the full set of call statuses that feed the `call.*` events, see [Call Statuses](/calls/statuses). *** ## The default emergency automations Every account — team and personal — is seeded with two system automations. They are created automatically when the account is created and restored automatically if they are ever missing. Both are **Enabled** by default, carry a **System** badge in the automations table, and offer no Delete action. ### Emergency SMS alerts * **Trigger:** Notification Created, Severity Filter set to `critical`. * **Pipeline:** a single Destination step that sends an SMS to **Team Members**. It is seeded with no specific members selected, which means the whole team: every member with a phone number on record receives the text (members without one are skipped). To narrow it down, open the step and tick individual members under "Select which team members should receive the SMS." The message is sent from your team's default phone number. * **Default message template:** ```text theme={null} [Voxworks URGENT] {{notification.title}} — {{notification.body}} {{notification.link}} ``` ### Emergency email alerts * **Trigger:** Notification Created, Severity Filter set to `critical`. * **Pipeline:** a single Destination step that emails the account owner's address (pre-filled when the automation is seeded). You can change it to any address, or list several separated by commas. * **Default subject:** `[URGENT] {{notification.title}}` * **Default body:** the notification title and body, followed by `Open Voxworks: {{notification.link}}`. ### What you can and cannot change | Editable | Locked | | ----------------------------------------- | ----------------------------------------------- | | Name and description | Deletion — system automations cannot be deleted | | Recipients (SMS members, email addresses) | Trigger type — always Notification Created | | Message and email templates | System identity — the badge stays | | Severity and event-type filters | | | Enabled/Disabled toggle | | If you do not want the default escalation, switch the automation to **Disabled** rather than looking for a delete option — as the settings page puts it, "they can be disabled but not deleted". You can also add further Notification Created automations of your own alongside them, for example a webhook post to your incident tool whenever `notification.severity` is `critical`. *** ## Event muting and notification settings The **Settings > Notifications** page controls the creation side of the feed and links to the delivery side: * **Emergency alerts** — explains that escalation runs through your automations and provides a **Manage escalation automations** button that takes you to the Automations page. * **Muted events** — checkboxes for the non-critical event types you can silence: **Call completed**, **Call failed**, **Batch started**, **Batch completed**, **Dispatch delays**, and **Automation failures**. Click **Save settings** to apply. Muting acts at the source: a muted event type is never created for the team, so it does not appear in the bell or the Activity panel **and it never fires Notification Created automations**. If an automation filters on an event type your team has muted, that automation will simply never run for it — unmute the event or filter on a different one. Critical alerts (emergencies, failed batches, exhausted credits) are never muted, so the default emergency automations always receive them. *** ## Next Steps * [Triggers](/automations/triggers) — all five automation trigger types and their configuration. * [Steps](/automations/steps) — the Destination, Transform, and Condition steps you can chain after the trigger. * [Execution Log](/automations/execution-log) — inspect each notification-triggered run step by step. * [Team Settings & Notifications](/team/settings) — the notification bell, Activity Monitor, and muting controls in detail.