Lone Worker FAQ
Answers to common setup and operating questions about Lone Worker.
For what the app is and how to set it up from scratch, see the
Lone Worker Overview.
Setup
What do I need to configure before check-ins start?
Two things: a responder roster and, optionally, a check-in schedule. A shift is “covered” — meaning timed check-ins arm automatically when a worker clocks in — only when a responder roster resolves for that shift’s site or team. Without a roster, check-ins will not arm, and a worker’s SOS will route to the break-glass safety-admin broadcast instead of a named responder ladder. You can also create a check-in schedule for a site or team to override the tenant default cadence. If you skip the schedule, check-ins use your tenant’s default interval and grace window (set in Settings).
Who can manage rosters, schedules, and settings?
Settings are restricted to business admins and Lone Worker app administrators. Rosters and check-in schedules follow the Who can manage responder rosters & check-in schedules? setting, and Analytics follows Who can view safety analytics?. Both default to admins and app administrators only; each can be widened to every manager, or to groups you choose. Anyone allowed to manage rosters can add themselves as a responder, so widen that one with care.
Permissions and access
Why can’t some employees see the Lone Worker app?
The app must be both enabled and licensed for your business, and accessible to the employee. If you use Access Management to restrict the app to specific groups, employees outside those groups are blocked on both the web and the API. Check the app’s access settings in Admin → Apps → All Apps.
Who can see which alerts on the dashboard?
Admins and Lone Worker app admins see every alert across the business. Everyone else sees only their own alerts plus alerts on rosters they belong to as a responder. This scope also applies to the Alerts list and the CSV export. The dashboard’s Open alerts table shows who has a live SOS or overdue check-in, so it is never served business-wide to a regular member. A worker who is on no responder roster and is not covered by either permission setting has no dashboard at all: opening Lone Worker takes them to My Safety, and their sidebar shows My Safety and Alerts.
Day-to-day
Which roster applies when a worker triggers an SOS or misses a check-in?
The most specific active roster wins: a roster scoped to the worker’s team is checked first, then one scoped to their site. If nothing resolves, the alert routes to a break-glass broadcast — your safety admins are notified over push, SMS, and voice. Safety admins are every business admin unless you pick a group under Settings → Escalation → Safety admins; only group members who are business admins or Lone Worker app admins are paged, since only they can open the alert and respond to it, and a group with nobody like that in it falls back to every business admin. That fallback is always on; a missing roster never swallows an alert.
What happens when a worker misses a check-in?
If a worker does not tap “I’m safe” before the due time plus the grace window elapses, the check-in is marked missed and an alert is raised automatically. That alert climbs the responder ladder exactly like an SOS. No one has to monitor a board — the system detects misses every minute.
Can a worker cancel their own SOS?
Yes, as a false alarm. A worker can close their own alert with the False alarm outcome. They cannot acknowledge it — acknowledgement must come from someone else, because acknowledging your own alert would stop the escalation ladder with nobody coming. Responders and admins can resolve an alert with any outcome: Safe, False alarm, or Incident. That includes their own alert: a worker who is also a responder on the alert’s roster, a business admin, or a Lone Worker app admin can record any outcome on it.
I acknowledged an alert but can’t attend — can I hand it back?
Yes. On the alert page, Hand it back — I can’t take this puts the alert back on its responder ladder at the same tier: everyone else on that tier is alerted again (not you), or, when nobody else is on it, it climbs to the next tier at once. On the last tier that sends it to your safety admins through the dead-man’s switch. The worker is told, and the alert’s history records who handed it back. Only the responder who acknowledged it, or a safety admin (whose button reads **Release 's acknowledgement**, and the acknowledger is told), can do this; Ask AI can do it for you after you confirm. An acknowledgement held by someone taken off the roster, or who leaves the organization, goes back the same way on its own.
What happens when I resolve an alert as “Incident”?
A note is required. If the Open a Safety Hub Incident setting is on (on by default), resolving as “Incident” automatically creates a Safety Hub incident record. Floor-issue alerts produce an equipment-failure incident; all other trigger types produce a security incident. The Safety Hub handoff is best-effort — if it fails, the alert still resolves and the failure is logged.
How do wearable and IoT device alerts work?
Devices (RFID badge presses, push-to-talk panic buttons, line sensors) POST events to a signed webhook endpoint. Each event must be signed with the integration’s HMAC-SHA256 secret. To protect deliveries from being replayed, the device platform can send an X-Signature-Timestamp header (Unix seconds) and sign <timestamp>.<body> instead of the body alone: a delivery more than five minutes old is then refused, and once an integration has sent a timestamp, every later delivery must carry one (changing the integration’s signing secret resets that). The device event is attributed to a worker by badge ID; if no badge matches, it falls back to the integration’s fallback user. If that person has left, the event is still raised under their name — it pages your safety admins — and the integration’s page says to pick a current person. An admin connects a device platform under Admin → Integrations → Wearables & IoT: enter a webhook signing secret (the same value goes on the device platform), optionally pick a fallback worker, save, and give the device platform the webhook URL the integration then shows. The integration’s page also says how the last device delivery went — accepted, or refused and why. Device alerts also stay off until an admin turns on Let wearable & IoT devices raise alerts in Lone Worker → Settings. Events with neither a matching badge nor a fallback user are rejected. Accepted events raise an alert on the same responder ladder, acknowledgement flow, and audit trail as a phone-raised SOS or floor issue. A fall or man-down the device detects on its own raises an SOS that the worker sees as Fall detected or Man-down detected, not as an SOS they pressed; when the device sends no message with it, responders see the same words as the alert’s note.
When something looks wrong
I tapped SOS and nothing happened — what’s going on?
If you already have an active SOS, a second tap is blocked to prevent restarting the escalation ladder from tier 1. You should see a message confirming your SOS is already active. If you see an error instead, the alert could not be saved — call your local emergency number if it is an emergency. Location capture is best-effort: a missing or denied location permission does not block the SOS.
My check-in keeps saying “Are you safe?” even after I answered
The “I’m safe” button is always visible while you have an armed check-in, even when it is not yet due. The prompt text (“Are you safe? Due by…”) clears the moment your answer is recorded, but the button stays so you can confirm safety any time. If the prompt text reappears quickly, your site or team may have a short check-in interval — ask your admin to check the schedule.
Check-ins are not arming for workers who are on shift
Four things must all be true for a check-in to arm: the Lone Worker app is enabled for your business, the worker has clocked in (an active attendance record exists), the shift has not reached its scheduled end, and a responder roster resolves for the shift’s site or team. If any is missing, no check-in is armed. Check-ins stop at the shift’s scheduled end even when the worker is still clocked in, and the worker is sent a notice when they do — extend the shift to start them again. The most common cause is a missing roster — create one scoped to the site or team and check-ins will start arming on the next clock-in.
The dead-man’s switch fired — what does that mean?
It means an alert ran out of responder tiers with no outcome recorded — nobody acknowledged it in time, an acknowledgement lapsed and nobody took it again, or the responder who acknowledged it handed it back (or left the roster) with nobody on that tier or above left to alert. The dead-man’s switch broadcasts to your safety admins (every business admin, unless you picked a Safety admins group in Settings) in the app and over push, email, SMS, and voice. No Lone Worker setting turns it off. Its in-app, push and email notices follow each admin’s own notification settings for Safety Hub & Lone Worker; the text message (to a verified mobile number) and the phone call go out whatever those settings say, as long as texts and calls are on for your organization. Intervene immediately: open the alert in Lone Worker and record what happened to close it — an exhausted alert can no longer be acknowledged, only resolved. If no roster was configured, the break-glass reached your admins directly.
Licensing and limits
Does Lone Worker require a licence?
Yes. An admin enables and licenses the app from Admin → Apps → All Apps. Enabling the app does not start check-ins on its own — a responder roster must also be configured before any shift is covered.
What are the configurable ranges and limits?
| Setting | Default | Allowed range |
|---|---|---|
| Check-in interval | 60 minutes | 5–480 minutes |
| Check-in grace window | 10 minutes | 1–120 minutes |
| Acknowledgement timeout per tier | 120 seconds | 30–1,800 seconds |
| Notification channels per tier | Push, SMS | Push, SMS, Voice (any combination) |
| Floor-issue / SOS note | — | Up to 280 characters |
| Alert audit-trail CSV export | — | Up to 10,000 rows per export |
| Stale armed check-in cutoff | 24 hours | Fixed (armed check-ins more than 24 hours past due are cancelled without raising an alert) |
| Escalation driver cadence | Every minute | Fixed |
| Missed-check-in detector cadence | Every minute | Fixed |
| Check-in scheduler cadence | Every 5 minutes | Fixed |
More help
- Lone Worker Overview
- Ask AI — the assistant answers Lone Worker questions from these articles.