Overview#
Every organisation on a shared Argus cluster has different rules for who hears about an incident escalate, a workforce approval waiting, a system alert, or a customer-facing utilities update. A single global channel list forces awkward workarounds: either every tenant inherits someone else's SMS gateway folklore, or application teams hard-code endpoints that drift the moment a number changes. Security reviewers also dislike notification configuration that can bleed across tenants.
Tenant Notification Channels store delivery endpoints and preferences inside the tenant boundary. Applications resolve channels at send time for operational notifications, so email, SMS, push, webhook, and related targets stay under local admin control. Channel definitions persist through the notification backend rather than living as one-off client lists. Admins manage only their organisation's endpoints; changes apply to subsequent sends without a platform redeploy.
For multi-agency programmes and managed-service operators, this is the difference between "notification is a platform feature" and "notification is a per-customer ticket forever".
Last Reviewed: 2026-09-15 Last Updated: 2026-09-15
Key Features#
-
Per-tenant configuration: Channel records belong to a single tenant. Cross-tenant visibility is excluded by design.
-
Backend persistence: Definitions persist through the notification backend so web and mobile clients share one source of truth.
-
Send-time resolution: Alerting, PSAP, workforce, and related flows resolve channels when they send, picking up admin changes without rebuilding clients.
-
Controlled failure: Missing or disabled channels fail in a way senders can surface, rather than pretending delivery succeeded.
-
Admin authorisation: Only tenant admins with the right grants can edit channels, enforced through auth_service-backed permissions.
-
Multi-path delivery: Supports the channel types the notification layer already operates (email, SMS, push, webhook patterns) under tenant configuration.
-
Operational breadth: The same registry can serve incident pages, approval notifications, and system alerts without a separate config island per app.
Use Cases#
-
Multi-agency deployments: Two agencies on one platform keep separate SMS and email channel sets for the same alert types.
-
Workforce approvals: Payroll or timesheet approvals notify the managers listed on the tenant's approval channels.
-
Quiet-hours and on-call changes: A tenant updates overnight channels during a roster change without affecting any other customer on the cluster.
-
Utilities customer communications: Impacted-customer outreach uses tenant-owned endpoints rather than a vendor-global sender identity when policy requires it.
-
Managed service operations: An MSP administers channels per customer tenant while keeping platform engineering out of day-to-day number changes.
Integration#
The notification backend stores and serves channel configuration and performs delivery. Consuming applications request channels by tenant and purpose. fe2 admin surfaces present maintenance UI where authorised. auth_service ensures only appropriate admins edit channels. PSAP, workforce, alerting, and utilities flows are expected consumers.
Open Standards#
- RFC 5424 (syslog): Where channels forward to SIEM collectors, payloads can follow syslog semantics already used in Argus monitoring modules.
- Web Push (RFC 8030): Browser and device push channels align with the Web Push protocol where enabled.
- SMTP: Email channels use the tenant's configured providers through the shared notification layer.
- OAuth 2.0: Admin and service callers authenticate through the platform auth stack.