A guard-management platform touches a lot of different events across a day โ a leave request gets approved, a referral reward is paid, an emergency alert fires, a kiosk tablet's battery runs low. Rather than each of those being its own separate, inconsistent alert mechanism, Raksha Kavach routes all of them through one shared notification system, so every user has a single place to see what needs their attention.
In-app first, push second
Every notification is always recorded in-app โ visible from the bell icon in the web portal or the notifications list in the mobile app โ regardless of whether push delivery is configured. Push notifications to a phone's lock screen are an addition on top of that, delivered via Firebase Cloud Messaging once an agency connects its own Firebase service account. In-app notifications work out of the box; push is an enhancement, not a dependency.
What actually triggers a notification
The list is broader than it might first seem, because the same pipeline is reused everywhere a "someone needs to know about this" moment happens in the product:
- A leave application being approved or rejected, sent to the guard who applied.
- A referral being rewarded, sent to whoever made the referral.
- An emergency SOS or HQ alarm, sent to the relevant admins, HR and site supervisors.
- Subscription and trial status changes, like an approaching trial expiry.
- A join request being submitted or approved, for both the applicant and the reviewing admin/HR.
- Kiosk device events โ an unrecognized face at a kiosk, a device going offline, low battery on a tablet, or a burst of repeated failed face matches.
Admin broadcasts use the same pipeline
Beyond automated triggers, Company Admins and HR can compose and send their own broadcast notification to some or all users in the company โ an announcement, a policy reminder, a heads-up about a site change โ from the Notifications page. It's delivered through the exact same in-app + push mechanism as every automated alert, so there's no separate "announcements" system to maintain or check.
Designed to fail gracefully
If push delivery isn't configured โ no Firebase service account connected yet โ nothing in the rest of the platform breaks. Notification-sending code is written to be best-effort: it tries push delivery, logs if it can't, and always still records the in-app notification regardless. An agency onboarding onto Raksha Kavach gets working in-app notifications from day one, with the option to switch on push delivery whenever they're ready.
Why this matters for a distributed guard workforce
Security agency staff are rarely all sitting at a desk โ guards are on site, supervisors are moving between locations, and HR is juggling multiple things at once. A system where important events (an emergency, a rejected leave request, a low-battery kiosk that needs attention) reliably surface somewhere the right person will actually see them is a meaningfully different experience from relying on someone remembering to check a shared spreadsheet or WhatsApp group.
Conclusion
Notifications aren't a bolt-on feature in Raksha Kavach โ they're the connective tissue between modules, making sure that when something happens that a specific person needs to know about, it reaches them consistently, whether that's an automated system event or a message an admin chose to send directly.