This article provides a technical overview of the in-app notification system implemented across the Swif Webapp and Desktop Apps (Linux, macOS, Windows).

Overview

The notification system allows administrators to create, schedule, and broadcast messages to employees' desktop applications. It supports both event-based alerts and manual broadcast notifications, with deep-linking capabilities to specific application pages.

Admin Webapp Functionality

Administrators manage notifications through the Notifications section (formerly "Notification Rules") in the Swif Webapp.

Creating Broadcast Notifications

The creation flow consists of four primary steps:

Step 1: Compose Message: Define the notification title and body.
Step 2: Recipients: Select target devices or device groups.
Step 3: Delivery Schedule:
- Send Once: Specify a date, time, and timezone (defaults to organization timezone).
- Repeat: Options for Daily, Weekly (select days), or Monthly (select day of the month).
Step 4: Review: Finalize the notification. The CTA button dynamically updates to "Send Notification" or "Schedule Notification" based on the selected timing.

Deep Link Configuration

Administrators can configure a deep link to guide users to specific pages within the Desktop App:

Supported Pages: Overview, AppInstalled, and AppStore.
Label Logic:
- Custom Label: Displays the administrator's input.
- Default Label: If left blank, defaults to "Open [Page Name]" (e.g., "Open Overview").

Reporting and Metrics

The Webapp provides a reporting view to monitor active notifications:

Metrics: Sent, Read, and Failed counts per notification template.
Filters: Filter by time range, OS, team, and notification type.

Desktop App Implementation

The Swif Desktop App consumes notifications via a gRPC/WebSocket channel and provides a structured UI for user interaction.

Notification Management

Notifications are organized into three tabs to ensure clarity and priority:

All (Default): Displays all read and unread notifications, including system alerts.
Unread: Shows only unread notifications. An unread badge counter is visible on the sidebar menu and the tab itself.
Trash: Contains dismissed or deleted notifications.

System vs. Admin Notifications

Admin Notifications: User-generated messages created via the Webapp.
System Notifications: Automated alerts (e.g., FILEVAULT_KEY_REGENERATE). These are pinned to the top of the All tab and include a [SYSTEM] label. System notifications do not support "Mark as Read" or "Trash" actions.

Alert Logic and Fatigue Optimization

To prevent "notification fatigue," the Desktop App follows specific alert logic:

Trigger: The app pops up only for new notifications that have not been previously displayed.
Interval: The notification list is fetched every 5 minutes, but alerts only trigger for recent arrivals.
Reset: The alert logic resets if the user restarts the application.

Technical Specifications

Severity Levels

Notifications are categorized by urgency using the notificationSeverity field:

CRITICAL
WARNING
INFO

API Integration

The Desktop App communicates with the backend to sync notification states:

Update Notification Status:

PUT /api/v1/swifteam/app/notification/status Content-Type: application/json  {   "notificationId": "string",   "status": 1, // 1: Unread, 2: Read, 4: Trashed   "description": "string" }

Delete Notification:

DELETE /api/v1/swifteam/app/notification team-id: {teamId} Authorization: Bearer {token}  {     "id": "string" }

Scoping and Security

Identifiers: Scoping uses tenant, device, and employee identifiers.
Isolation: The system ensures no cross-tenant notification leakage.
Telemetry: Events such as shown, clicked, and dismissed are logged for reporting accuracy.

Swif In-App Notification System