Operational summary
After sign-in, the app reads backend configuration to learn which modules are enabled for your deployment.
Sentinel is built so the same mobile app serves organizations with very different profiles: some need SOS but not geofences, others the other way, others neither in a first phase. To support that diversity without building separate versions, the app queries remote config exposed at /api/mobile/config every time the operator signs in. The response includes which modules are enabled for that organization.
Deep dive
The features.sos flag controls the emergency flow: when off, the SOS button and its flows are hidden or disabled per client version. This is useful in pilots that test monitoring first and add emergency response later, or in organizations that route emergencies via radio and use Sentinel only for visibility.
The features.geofences flag is analogous for zones: when off, the app does not apply geofence rules even if server-side zones exist. That architectural choice lets an admin globally disable geofences for an organization without deleting zones or changing app versions. Transition is transparent for the operator.
Operationally, remote config changes apply on the next session the operator opens. No app reinstall or device reboot needed. For controlled rollouts of new features, the usual practice is to enable first in a pilot organization, validate with their team, then extend to the rest. That cadence avoids surprises in critical operations.
Key takeaways
- SOS: when features.sos is off, the emergency flow is hidden or disabled per client version.
- Geofences: when features.geofences is on and location permission is granted, the app evaluates position against restricted zones and may notify on entry.
Open in product