Skip to content

Notifications

Send Workbench delivers real-time notifications to users as risk events occur — for example when a risk action completes, a pipeline fails, or a task is assigned. Notifications appear in the Workbench UI via a persistent bell icon and can be extended to external channels such as Teams or Slack.

This page explains how the notification system works, what a configurator controls, and what requires DevOps involvement.

How notifications work

The notification system is built on three components:

  1. Notification Client — a shared library embedded in every Workbench service. Any service can publish a notification message.
  2. Apache Pulsar — the message broker that routes notifications between services.
  3. Notification Service — subscribes to Pulsar topics and delivers notifications to connected browsers via WebSocket.

When a pipeline step completes or a system event fires, the relevant service publishes a NotificationMessage to Pulsar. The Notification Service receives it and pushes it to the correct user's browser session in real time.

Service → NotificationClient → Apache Pulsar → Notification Service → WebSocket → Browser

Enabling notifications

Notifications require Pulsar to be running and the Notification Service to be deployed. The base repository's be_config.json does not contain a pulsarConfiguration block — Pulsar enablement is typically managed at the infrastructure / service-startup level by DevOps rather than via be_config.json. Confirm the exact enablement mechanism for your active core platform version with your delivery lead before assuming a config key name.

The base repository does include taskCreatedNotification and taskCompletedNotification switches under externalCallConfig in be_config.json, which control whether task lifecycle notifications fire to client-specific endpoints.

In local development, Pulsar runs as a Docker container. The standard docker-compose.yml includes:

pulsar:
  image: apachepulsar/pulsar:3.1.1
  ports:
    - "6650:6650"   # Pulsar broker
    - "8090:8090"   # Pulsar admin (port 8090 avoids clash with socket-io on 8080)

What triggers notifications

Notifications are fired by the platform automatically for the following events:

Event Description
Risk action completed When a pipeline finishes successfully for a risk action
Risk action failed When a pipeline encounters an error
Task assigned When a task is created and assigned to a user
Task status changed When a task moves to a new state
Smart Submission processed When an inbound email is triaged and a risk pre-populated
Sanctions check result When a sanctions screening result is returned

These are built into the platform and do not require configuration by an implementer.

Notification channels

The Notification Service currently supports:

Channel Status
In-browser (WebSocket) Live — available to all clients
Microsoft Teams Planned — not yet in production
Slack Planned — SDK included but not yet active

Future channel support will be configured via be_config.json once released.

Configuring notification recipients

The platform routes notifications to the user who owns the risk or task involved in the event. No explicit recipient configuration is required for standard workflow notifications.

For custom pipeline-triggered notifications, you can control recipients by configuring the pipeline component that calls the notification service. Recipient targeting follows these rules:

  • By user ID — route to a specific named user
  • By role — route to all users holding a given Workbench role (see User Roles & Permissions)
  • By risk owner — route to the current owner of the risk record

Local development

When running Workbench locally, ensure Pulsar starts before the Notification Service. The recommended startup order is:

  1. LocalStack (AWS SQS / Lambda)
  2. Riskwire Hub
  3. Pulsar
  4. Riskwire Underwriting
  5. Notification Service
  6. All other services

Warning

If Pulsar is not running when services start, notification publishing will silently fail. Risk actions will still complete but users will not receive real-time updates.

Troubleshooting

Users not receiving notifications

  • Confirm Pulsar is enabled for your environment (mechanism depends on your core platform version — confirm with DevOps or your delivery lead)
  • Confirm the Notification Service is running (port 4888 in local Docker)
  • Confirm Pulsar is healthy — visit http://localhost:8090/admin/v2/clusters to verify

Notifications delayed

  • Pulsar queues messages if the Notification Service is temporarily unavailable. Messages are delivered when the service reconnects.

No notifications in local development

  • Ensure you are using the full docker-compose.yml, not the minimal docker-compose-min.yml. Pulsar is excluded from the minimal stack.