FAQs

Navigator Mobile is for field users who pair devices, monitor readings, and participate in emergency workflows on phone. Navigator Console is the web experience for dispatch and admin visibility, triage, coordination, and reporting. Most organizations use both surfaces together.

Use your organization-approved app source (managed store or MDM catalog) whenever possible. This ensures users receive the correct build, permissions profile, and update policy.

Confirm users are on the correct tenant URL first, then verify account status and role assignment. If SSO is used, check identity provider assignment and session policies before resetting credentials.

Mobile Users primarily use Navigator Mobile for pairing, monitoring, tools, and mobile emergency participation when enabled. Dispatch users use Navigator Console for operational visibility and emergency coordination as entitled. Admins configure users, groups, organization settings, and Compass Pro configurations when applicable. Exact menus still depend on subscription and tenant configuration.

Confirm Bluetooth permissions, that the device is in pairing mode (restart if the window timed out), that no other phone is already connected if your model restricts one active session, and that MDM policies are not blocking Bluetooth or background behavior. See Device Won’t Pair with Navigator Mobile for a full checklist.

Schedule updates in controlled windows with supervisors available, ensure devices have sufficient battery, and avoid pushing major updates before critical shifts. Validate a pilot group before broad rollout.

Keep the device powered, avoid repeated forced retries, and follow the documented recovery workflow in Navigator Mobile. Escalate with device ID and hardware version if multiple devices fail in the same group.

They generally indicate a device health or fault state that needs inspection before continued use. Run self-test checks and compare behavior against the fault troubleshooting guide instead of assuming a temporary connection glitch.

Connection Lost usually signals an interrupted communication path while the user or device may still be active. Device Offline typically means the device is not currently reporting. The response process may differ, so dispatch teams should follow the dedicated guidance for each state.

Emergency modules are often gated by subscription, seat assignment, role, unfinished admin configuration (teams/service settings), app version, or device model support. Start with Why Am I Not Seeing Emergency Features? rather than assuming hardware failure.

Events can start from supported device/app workflows and include countdown or confirmation logic depending on configuration. Teams should train users on countdown behavior so accidental triggers can be safely canceled while real incidents are still escalated immediately.

Field users typically acknowledge and share immediate context in Mobile, while dispatch and supervisors coordinate broader response in Console. Defining this split ahead of time helps avoid duplicate or delayed actions.

Yes. Emergency history and report workflows support after-action review and audit needs. Keep role permissions aligned so only authorized users can access sensitive event details.

Align seats to operational roles first, then validate that users can see expected menus after assignment. Most access issues come from role-seat mismatch rather than app defects.

Location sharing settings control who can view location context for response and monitoring. Apply least-privilege defaults and document exceptions for teams that need broader visibility.

Use the Supported Devices, Browsers, and Languages reference as the source of truth before rollout. Standardizing on supported environments reduces sign-in, rendering, and performance issues.

Customer-facing documentation uses Navigator Console. Some legacy bookmarks or training PDFs may still say WebApp - update links and bookmarks to Navigator Console.