Mobile push notifications
The mobile app supports OS-level push notifications — new message, new task, urgent escalation — wired through the standard browser Push API.
Subscribing
The first time the operator opens the mobile app ships, the app prompts for notification permission. Grant → the subscription token is saved server-side against the operator's user row.
To re-prompt later: Settings → Notifications → Mobile push → tap Enable.
What fires a push
- New guest message on a thread you're routing to.
- Task assigned to you.
- Critical escalation (e.g. Send Check-in BLOCKED for a check-in today).
The set of triggers is configurable per-template in the Task Templates editor — same surface as in-app + WA notifications.
Deep-linking
Tapping a push notification opens the app to the right entity:
- New message → opens the thread.
- Task assigned → opens the task drawer.
- Critical escalation → opens the affected reservation.
Tapping a push opens the exact screen the notification is about — the service worker honours the payload's deep link.
Badge counts
The bottom tab bar carries badges:
- Inbox — count of unread / unanswered threads. Visible from any tab.
- Pulse — count of overdue auto-resolves blocked by failed conditions.
On iOS PWA install, the app-icon badge mirrors the Inbox count.
Resolving tasks on mobile
The mobile task list is fully actionable — tap a task to act inline. Full parity with desktop.
Reply with template on mobile
The mobile Inbox composer earlier only had AI Suggest + free composer; the reply-with-template dropdown from desktop was missing.
Calendar / occupancy view on mobile
The mobile Pulse tab earlier showed Auto-resolves + Unanswered + Per-property panel, but the calendar / occupancy view (data was fetched but not rendered). ## Phone-on-/v28 redirect to /m
When a phone-sized viewport loads a /v28/... route, the app redirects to the equivalent /m/... route instead of showing the desktop chrome cramped onto a phone.
PWA mount crash fix
The mobile PWA mount earlier crashed with a TypeError on /m/pulse (a threadsQ.data cast lie latent ).
Desktop (installed V28 PWA)
The installed desktop app (open /v28 and "install app" from the browser) shares the exact same push infrastructure as mobile — a subscription there is just another device. A banner strip prompts for permission the first time it's undecided; granting it subscribes the desktop app.
If the browser already reports notification permission as granted (e.g. a re-opened install) but no banner ever appeared for you, the app silently re-checks and subscribes this device in the background the next time you load /v28 — no action needed. If you still don't see a banner:
- Settings → Notifications now shows a "this device" status (subscribed / not subscribed) with an Enable on this device button — this works even when permission is already granted (the top banner only prompts once, on first decision).
- Use Send test notification in the same card to fire a one-off push to every device on your account and confirm one actually pops.
If notifications are blocked at the OS/browser level, the button will tell you — flip it back on in System Settings (macOS: Notifications → your browser / the installed app), then retry.