---
sidebar_label: Sources and actions
doc_id: 7c4e1a3b-8d2f-4b91-a6e5-9f0c3d7e2a18
toc_max_heading_level: 3
description: >-
  Understand notification sources, their actions, and when to use each one
  to route the right platform events to the right channels.
keywords:
  - notification sources
  - notification actions
  - audit notifications
  - telemetry notifications
  - approval notifications
---

# Sources and actions

Every notification channel listens to one or more **sources**. A source is a category of platform event (approvals, audits, service provisioning, and so on). Each source produces **actions**: the specific operations that trigger a notification, such as `deployment:create` or `audit:log`.

When you [create a notification channel](/docs/notifications/channels), you choose which sources it listens to. You can then use [filters](/docs/notifications/filters) to narrow down to specific actions within those sources.

## What is a source?

A source groups related platform events under a single label. When you set `"source": ["audit"]` on a channel, that channel receives every audit event that matches its NRN and filters.

You can assign multiple sources to a single channel (for example, `"source": ["approval", "audit"]`) or create separate channels per source. Separate channels are easier to manage when each source needs different filters, destinations, or teams.

:::tip
Start with one source per channel. It's simpler to reason about what each channel does and easier to troubleshoot when notifications don't arrive as expected.
:::

## Source reference

| Source | What it tracks | Common actions | Typical channels |
|--------|---------------|----------------|-----------------|
| `approval` | Approval requests for deployments, scopes, and parameters | `deployment:create`, `scope:stop`, `scope:delete`, `parameter:read-secrets` | Slack, HTTP |
| `service` | Service provisioning actions triggered by scope or service specifications | `service:action:create` | Agent, GitHub, GitLab, Azure |
| `audit` | API activity log for every create, update, or delete on any platform entity | `audit:log` | HTTP |
| `alert` | Platform alerts and monitoring events | | Slack, HTTP |
| `entity` | Entity lifecycle hooks that run logic before or after entities are created, updated, or deleted | `application:create`, `scope:create`, `deployment:create` | HTTP, Agent |
| `telemetry` | Logs, metrics, and instance data from your applications | `log:read`, `metric:data`, `metric:list`, `instance:data` | Agent |
| `parameters` | Parameter lifecycle events: stores, deletes, reads, and change notifications | `parameter:store`, `parameter:delete`, `parameter:retrieve`, `parameter:notify`, `parameter:read-secrets` | Slack, HTTP |

## Action reference

Actions are the specific operations within a source that trigger notifications. Use them in [filters](/docs/notifications/filters) to narrow which events reach a channel.

### Deployment and scope actions

Track the full lifecycle of deployments and scopes — from creation and updates to stops, deletes, and recreations. Useful for triggering approval flows or alerting on destructive operations.

```bash
# Alert when a scope is stopped or deleted
"filters": {
  "action": { "$in": ["scope:stop", "scope:delete"] }
}
```

### Application and entity actions

Track organizational entities such as accounts, namespaces, applications, target groups, and permission grants. Useful for auditing onboarding flows or monitoring access changes across the platform.

```bash
# Notify when a new application is onboarded
"filters": {
  "action": "application:create"
}
```

### Service actions

Track service provisioning actions triggered by scope or service specifications — for example, when infrastructure is being created or updated via an external provider.

```bash
# Trigger a pipeline on every service provisioning action
"filters": {
  "action": "service:action:create"
}
```

### Parameter actions

Track the full parameter lifecycle: stores, deletes, retrievals, and secret reads. Useful for change management, compliance auditing, or alerting on sensitive secret access.

```bash
# Notify when a secret parameter is read
"filters": {
  "action": "parameter:read-secrets"
}
```

### Telemetry and monitoring actions

Track log reads, metric data, instance updates, and monitoring events from your running applications. Typically routed to an agent for custom processing.

```bash
# Capture metric and log events for custom processing
"filters": {
  "action": { "$in": ["metric:data", "log:read"] }
}
```

### Audit filterable fields

Audit events don't use a discrete action list. Instead, filter by any combination of these fields to track exactly what you need:

| Field | Type | Description |
|-------|------|-------------|
| `entity` | string | The type of entity affected (`application`, `scope`, `deployment`, …) |
| `method` | string | HTTP method of the operation: `GET`, `POST`, `PATCH`, `DELETE` |
| `status` | number | HTTP status code of the operation |
| `entity_context.<field>` | any | Any field within the entity context object, accessed via dot notation (e.g. `entity_context.account_id`) |
| `url` | string | The API path that was called |
| `user_type` | string | Who triggered the event: `user` or `service_account` |


## Choosing the right source

| You want to... | Use source | Example |
|----------------|-----------|---------|
| Track who changed what and when across the platform | `audit` | Route `audit:log` events to an HTTP webhook for your SIEM |
| Get approval requests in Slack | `approval` | Send `deployment:create` approvals to a Slack channel |
| Trigger infrastructure provisioning pipelines | `service` | Route `service:action:create` to a GitHub Actions workflow |
| Run custom logic before or after entity lifecycle events | `entity` | Send `scope:create` events to an HTTP endpoint for pre-validation. See [Entity hooks](/docs/entity-hooks/) |
| Stream logs and metrics to a custom provider | `telemetry` | Route `metric:data` and `log:read` to your agent. See [Telemetry](/docs/telemetry/overview) |
| Get notified when parameters change | `parameters` | Send `parameter:store` events to Slack so teams know when config changes |
| Forward platform alerts to your on-call tools | `alert` | Route alerts to a Slack channel or PagerDuty webhook |



## Next steps

- [Create a notification channel](/docs/notifications/channels)
- [Apply filters to route specific events](/docs/notifications/filters)
- [Manage existing channels](/docs/notifications/manage-channels)
- [Inspect event payloads](/docs/notifications/event-payloads)