Mobile and team access

Daily phone work starts with the correct company, the caller’s context, and a clear next action. The mobile experience and a server integration have different authentication and execution boundaries.

Preserve company context

A person can belong to several businesses. Display the active company beside calls, customer records, and meaningful actions. A deep link, notification, or cached screen must not silently apply another company’s calling settings.

Recheck current membership and permissions before showing private records or executing an action. An owner login does not grant a company machine key access to every business the owner belongs to.

Use human authentication on the device

Keep server integration keys off the device. Use the application’s supported account authentication and session flow. Handle signed-out, revoked-access, and company-switch states before showing customer data.

The bearer-key examples in the quickstart are intended for server-side integrations. They do not implement native signup or account recovery. Read authentication and scopes for that distinction.

Check calling readiness

A callback needs a current customer record, an eligible company caller ID, service readiness, and an authorized calling path. Answering and transfer behavior also depend on the supported client, device permissions, network, and server connection. Validate those on the actual device.

A deep link into a call record is not a promise that native answering or a carrier bridge is available. Inspect the relevant readiness before presenting an action as available; retain a useful saved-message path when it is not.

Make notifications actionable

• Deep-link to the correct authorized company and record.
• Re-fetch current state after opening; notification data may be stale.
• Keep sensitive customer details out of lock-screen previews.
• Show the saved request even if calling is temporarily unavailable.
• Distinguish a saved callback request from a completed outbound call.

Publication and status

The public mobile page describes current app availability. Native store publication, account access, and individual calling features are separate conditions; a feature should not be advertised as available solely because a store listing or a backend route exists.

Service status describes mobile backend and shared service readiness. It does not establish that every installed client, device permission, or carrier path is working.