[Developers]

Notification System

An intelligence officer who has just been assigned a time-sensitive case needs to know the moment that assignment happens, not when they next open their browser. A field investigator waiting for a forensic analysis resul

Category: CollaborationLast Updated: Feb 5, 2026
collaborationreal-timecomplianceblockchain

Overview#

An intelligence officer who has just been assigned a time-sensitive case needs to know the moment that assignment happens, not when they next open their browser. A field investigator waiting for a forensic analysis result cannot afford to miss the completion notification because their phone was on silent during quiet hours. The platform's Notification System handles these realities through intelligent routing: critical alerts bypass quiet hours, urgent items retry through fallback channels, and each user decides how they receive different message types. The goal is that the right person always knows what they need to know, when they need to know it.

The system supports email, SMS, push notifications, in-app messages, and webhook integrations across a multi-tenant environment with full organisation-level isolation and 40+ language support for notification content.

Key Features#

Multi-Channel Notification Delivery#

  • Email notifications for detailed content and formal communications
  • SMS messaging for urgent, time-sensitive alerts
  • Push notifications for real-time mobile alerts
  • In-app messages for users actively working in the platform
  • Webhook delivery for notifying external systems and triggering automation

Intelligent Routing and Preferences#

  • User-configurable channel preferences determine how each person receives notifications
  • Channel optimisation selects the most effective delivery method based on message type and urgency
  • Fallback chains automatically try alternative channels when the primary channel fails
  • Quiet hours settings suppress non-critical notifications during off hours
  • Priority-based routing ensures critical alerts bypass preference restrictions and reach recipients immediately

Notification Priority Levels#

  • Critical: Delivered across all channels, bypassing quiet hours and preference restrictions.
  • High: Delivered through preferred channels, bypassing quiet hours.
  • Normal: Delivered according to user preferences and quiet hours settings.
  • Low: Delivered through a single channel, respecting all quiet hours and preferences.

Template and Personalisation System#

  • Reusable notification templates with dynamic variable substitution
  • Channel-specific formatting ensures messages display correctly on each delivery platform
  • Localisation support delivers notifications in the recipient's preferred language across 40+ supported languages
  • Personalised content adapts messaging based on recipient context and role
  • A/B testing capabilities optimise notification content for engagement

Bulk and Scheduled Notifications#

  • Bulk notification delivery reaches multiple recipients simultaneously for organisational announcements
  • Scheduled notifications enable planned communications at optimal times
  • Recipient group targeting delivers messages to specific teams, roles, or organisational units
  • Delivery throttling prevents notification fatigue during high-volume events

Delivery Tracking and Analytics#

  • Real-time delivery status tracking across all channels
  • Delivery confirmation verifies messages reached their intended recipients
  • Open and click tracking measures notification engagement
  • Failure analysis identifies delivery issues and triggers retry attempts
  • Channel performance analytics reveal which delivery methods are most effective

Use Cases#

Critical Alert Notifications#

Security alerts, system warnings, SLA violations, and escalation notices are delivered immediately through all available channels, ensuring responsible personnel are aware and can respond without delay.

Operational Updates and Activity Notifications#

Users stay informed about assignment updates, report completions, status changes, collaboration messages, and task reminders through their preferred channels without being overwhelmed.

External System Integration#

Webhook-based notifications trigger workflows in external systems, enabling automated responses to platform events such as alert creation, case status changes, and compliance deadline approaches.

Organisational Communications#

System maintenance notices, policy updates, and organisational announcements reach all affected users through bulk notification delivery with appropriate channel selection and scheduling.

Integration#

  • Alert Management: Alerts automatically trigger notifications based on severity and recipient assignment rules.
  • User Preferences: Individual notification settings are managed through the user profile and respected across all notification types.
  • Webhook Integrations: External systems receive event-driven notifications for automation and workflow triggers.
  • Collaboration Platform: Team messaging and collaboration events generate targeted notifications to relevant participants.

Open Standards#

  • OASIS Common Alerting Protocol (CAP) 1.2: Alert messages submitted to FEMA IPAWS are serialised as CAP 1.2 XML documents, with urgency, severity, certainty, event codes, and area elements conforming exactly to the urn:oasis:names:tc:emergency:cap:1.2 namespace specification.
  • W3C XML Signature Syntax and Processing (XML-DSig): CAP alert documents are signed using an enveloped XML-DSig signature with RSA-SHA256 before submission to the IPAWS gateway, meeting FEMA's mandatory cryptographic-integrity requirement.
  • OAuth 2.0 / JWT Bearer Token Profile (RFC 6749 / RFC 7519): Push notification delivery to Android devices via the FCM HTTP v1 API is authenticated by exchanging a service-account-signed JWT (RS256) at Google's OAuth 2.0 token endpoint, following the JWT Bearer grant type.
  • SMTP / MIME (RFC 5321 / RFC 2045): Email notifications are composed as MIME multipart messages (plain-text and HTML parts) and delivered over SMTP, with optional STARTTLS for transport security.
  • HMAC-SHA256 Webhook Signing: Outbound webhook payloads are signed with HMAC-SHA256 and the digest is attached in the X-Argus-Signature request header, following the convention widely adopted in webhook security (analogous to GitHub, Stripe, and similar implementations).
  • GeoJSON (RFC 7946): Polygon boundaries for geofenced alert targeting and the geographic area element of CAP alert messages are represented and stored as GeoJSON geometry objects.
  • GraphQL: All notification management operations, including preference configuration, template management, bulk dispatch, IPAWS alert lifecycle, and push-notification management, are exposed through a typed GraphQL API.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14

Ready to Build?

Get started with our APIs or contact our integration team for support.