Skip to main content
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. 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 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 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. 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.

Event-type catalogue

Every notification carries a severity and a namespaced event type.

Severities

Event types

These event types fire today: 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.

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:

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

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 — all five automation trigger types and their configuration.
  • Steps — the Destination, Transform, and Condition steps you can chain after the trigger.
  • Execution Log — inspect each notification-triggered run step by step.
  • Team Settings & Notifications — the notification bell, Activity Monitor, and muting controls in detail.