Browser and PWA notifications on Vareons for Egypt stores: order alerts and the daily digest
Browser notifications on Vareons deliver OS-level alerts through VAPID-based Web Push to each device you pair from the dashboard: new orders, contact messages, and new leads, plus an opt-in daily digest sent once for the closed day. Every device holds its own subscription and its alert types can be tuned independently.
Last verified: 2026-09-19
Browser notifications on Vareons are managed from the "browser notifications" tab inside /dashboard/settings. They are built on the W3C Web Push standard (called System C internally) and are separate from the FCM pushes of the mobile app: browser subscriptions live in the WebPushSubscription collection while mobile tokens live in DeviceToken, each with its own sending service.
Pairing is per device: pressing the enable button registers the dashboard service worker (dashboard-sw.js), asks the OS for notification permission, then posts the subscription fingerprint (endpoint plus p256dh and auth keys) to POST /api/dashboard/web-push/subscribe, which saves or refreshes it scoped to your tenant id and user id. Endpoints are globally unique: if one is registered to another user or tenant the server answers 409, and each user is capped at five subscriptions. The audience flag is retagged automatically to platform_admin when the account is a live platform admin, otherwise merchant, and demoted accounts lose the admin tag.
After pairing, four toggles appear for this device only: orders, contact messages, and leads (on by default) plus the daily summary (off by default, opt-in). Changes go through PATCH /api/dashboard/web-push/preferences against that same endpoint only, so editing your laptop never affects your phone. A new-order alert deep-links to the order page at /dashboard/orders/{orderId}, while the daily digest links to /dashboard/daily-summary.
Delivery is guarded by a five-second timeout per subscription: when a subscription expires (410 or 404 from the push provider) the server deletes it automatically and stamps lastSuccessAt on success, and every test send returns sent, failed, and removed counts. The "test" button in the same tab posts to POST /api/dashboard/web-push/test and reaches only your devices without creating an order, while the test button on /admin/notifications posts to POST /api/admin/web-push/test and reaches every device of the platform admin after a live admin check, automatically disabling rows of demoted accounts.
The daily summary is a dedicated standalone service: the merchant opts in per device, then a 00:05 Africa/Cairo schedule runs /api/cron/daily-summary-digest guarded by CRON_SECRET, computing the previous closed day (views, orders, leads, contact messages) and pushing a digest payload tagged daily-summary-{date} to opted-in subscriptions only, with low concurrency (2) and an 86400-second TTL, while DailySummaryPushLog blocks duplicate sends for the same tenant and date. Platform-wide merchant broadcasts instead go through /api/admin/tenant-broadcast on an async BullMQ queue over both FCM and web-push.
The one thing that does not exist yet is installing the storefront itself as a PWA on customer devices: a footer install control is planned but still at the planning stage and unbuilt, so do not confuse it with the working dashboard browser notifications.
Setup steps in Vareons
Open the browser-notifications tab
In the dashboard open /dashboard/settings, then the browser-notifications tab (BrowserOrderAlertsSettings). It shows support status, the active device count, and this device's type toggles.
Pair this device
Press the enable button and accept the notification permission in the browser and the OS. The browser registers the service worker and posts the subscription to POST /api/dashboard/web-push/subscribe. Repeat on each device (desktop and phone) because a subscription belongs to one browser.
Choose alert types for this device
Enable or disable orders, contact messages, and leads per device via PATCH /api/dashboard/web-push/preferences. The three default to on, and changing one device never touches the others.
Opt into the daily summary if you want it
The daily-summary toggle defaults to off: enable it on each device that should receive the digest. It is sent once at 00:05 Cairo time for the previous closed day with a /dashboard/daily-summary link, never duplicated for the same date.
Verify delivery with the test button
Press Test in the same tab: POST /api/dashboard/web-push/test pushes to your devices and reports sent, failed, and removed counts. A sent: 0 means this user has no enabled subscription yet. Platform admins find a matching test button on /admin/notifications.
Manage the five devices and expired subscriptions
Each user is capped at five subscriptions: remove an old device via POST /api/dashboard/web-push/unsubscribe before adding a new one. Expired subscriptions (410/404) are deleted automatically on send, and reopening the dashboard silently refreshes the subscription without spamming the activity log.
Monitor from the activity log
Every subscribe, unsubscribe, preference change, and test is recorded in /dashboard/activity as a pwa event with no keys or endpoints, and the dialog links straight back to the browser-notifications tab. Check the log when a device seems silent.
Frequently asked questions
Do I need a mobile app to receive order alerts?
No. Browser notifications work over Web Push in the browser itself after pairing the device from /dashboard/settings, a channel independent of the mobile app's FCM tokens.
Are notification settings shared across my devices?
No. Each device has its own subscription and toggles, and editing alert types affects only the current endpoint, so orders can stay on for the phone and off for the office desktop.
When does the daily summary arrive and what is inside?
It is sent once at 00:05 Cairo time for the previous closed day: views, orders, leads, and contact messages, deep-linking /dashboard/daily-summary, and it is never repeated for the same tenant and date thanks to the DailySummaryPushLog record.
How do I test notifications without a fake order?
Press the test button in the browser-notifications tab: POST /api/dashboard/web-push/test sends a trial payload to your devices and reports sent, failed, and removed counts without creating any notification document.
I enabled notifications but nothing arrives, why?
Common causes: notification permission denied in the browser or OS, an expired subscription (auto-deleted on the first 410/404), the five-device cap, or an endpoint registered to another user (409). Check the test button and the pwa activity log, then re-pair.
What happens to a staff member's pushes after demotion?
On every subscribe and test send the server re-checks the live user role: anyone stripped of the platform-admin role gets their platform_admin rows disabled and retagged to merchant automatically, so admin alerts stop reaching them.
Can my store customers install the storefront as an app?
Not yet. The storefront PWA install control is still at the planning stage and unbuilt, and it is entirely separate from the working dashboard browser notifications for the merchant and team.
Are push keys or browsing data stored?
The p256dh and auth keys are stored in WebPushSubscription because sending requires them, but the pwa activity log never keeps full endpoints, keys, or raw user agents — only the browser family and provider class.
Troubleshooting
1) Nothing arrives: confirm notification permission is granted in the browser and the OS (Windows focus-assist hides the banner), then press Test and read the counts. 2) sent: 0 after testing: this user has no enabled subscription — re-pair the device from the browser-notifications tab. 3) 409 while pairing: the endpoint is registered to another user or tenant — delete it from the original device first. 4) Five-device cap reached: remove an old device via POST /api/dashboard/web-push/unsubscribe, then add the new one. 5) Daily digest missing: confirm the dailySummary toggle is on for this exact device (not another one), and that VAPID keys are configured on the server, otherwise it answers VAPID_NOT_CONFIGURED. 6) Admin alerts stopped: the account is no longer a live platform admin — platform_admin rows are disabled automatically on the live check.
Important limitations
• Browser pushes serve the merchant and team only, not a marketing channel to store customers. • Each user is capped at five browser subscriptions. • Sends carry a five-second timeout per subscription, and expired subscriptions are deleted rather than repaired. • The daily digest is opt-in (off by default) and sent at most once per day. • Storefront PWA install for customers is not built yet (planning stage). • Platform-admin merchant broadcasts run on an async queue and may lag behind instant sends.