Understand notifications and order handoff
Business App notification behavior has separate stages. Device permission, notification registration, provider delivery, an in-app event, and opening an order are not the same result. Confirm each stage independently and use the Orders workspace as the reliable place to find an order.
Before you start
- Sign in to the intended project and keep the app connected.
- Confirm notification changes are allowed on this device before opening system settings.
- Do not use a real notification, token, account, or order as a test fixture.
- Do not reinstall the app, repeatedly change permission, or repeatedly open a notification to force a result.
Notification stages
| Stage or visible state | What it means | What it does not establish | Safe next action |
|---|---|---|---|
| Enable notifications appears over Orders | The operating system reported notification permission as blocked when the Orders workspace checked it | No provider registration, service registration, delivery, or order opening is confirmed | If authorized, select Enable notifications once to attempt to open the device's app settings. If Settings opens, make the intended choice there, then return to Business App. |
| No Enable notifications message appears | The check did not return the exact blocked state | Permission can still be limited, provider setup can still fail, and delivery is not confirmed | Check the current device setting through the approved device-management process if notifications are required. |
| Permission is allowed in device settings | The operating system can permit notifications for this app | The provider has issued a device identifier or the project service has accepted it | Return to Business App and continue normal work; do not toggle permission again as a test. |
| Business App is signed in with notification configuration | The source intends to initialize the notification provider and request a device registration | Registration success, provider reachability, and notification delivery are not visible or guaranteed | Treat this as configuration intent only. Escalate if delivery is required but cannot be verified through an approved synthetic test. |
| An operating-system notification is received | The device and provider delivered that notification to this installation | The order is current, accessible, or guaranteed to open | Open Business App and verify the order in Orders before acting. |
| New orders have been received! appears inside Business App | An in-app realtime event produced the Business App modal | It is not proof of operating-system notification permission, provider delivery, or token registration | Close the modal and locate the order in Orders. |
| Selecting an operating-system notification attempts to open an order | The notification supplied an order reference and the source attempted an order handoff while the app was signed in and loaded | The current source does not prove that the root-to-nested navigation succeeds | If Order Details does not appear, return to Orders and locate the order there. Do not select the notification repeatedly. |
Verify without conflating stages
Use only observable outcomes:
- Permission is a device setting. Verify it in the operating system, not from notification delivery alone.
- Device registration is an app/provider/service exchange. Business App does not display a registration receipt in this flow.
- Delivery is an operating-system/provider outcome. Permission and registration do not guarantee it.
- The in-app new-order modal is a realtime app event. It does not prove an operating-system push was delivered.
- Order opening is a navigation result. It is confirmed only when the intended Order Details view appears with the expected order context.
If any stage is missing, stop at that boundary. Do not infer that later stages succeeded.
Troubleshooting
| What you observe | Interpretation | Next action |
|---|---|---|
| Enable notifications returns from Settings | The app's permission check can still report blocked, or the app can be showing an earlier check result | Verify the device setting once through the approved process. Avoid repeated toggles; report the platform and visible state if it remains inconsistent. |
| Permission is allowed but no notification arrives | Provider initialization, device registration, service acceptance, provider delivery, or project configuration may be incomplete | Continue monitoring orders in Orders. Escalate with project, platform, approximate time, and permission state—never with a notification identifier or token. |
| The in-app new-order modal appears but no operating-system notification arrives | The realtime in-app event and operating-system push are separate paths | Use Orders for the current order state. Do not treat the modal as a push receipt. |
| A notification arrives but does not open Order Details | The root-to-nested order handoff was not confirmed | Return to Orders, search for the order using approved business context, and open it from the list. Do not tap the notification again. |
| A notification opens an unexpected or unavailable order | Delivery can be stale, the order can be outside the current state, or navigation/context can differ | Return to Orders and verify the current order before acting. Escalate if the mismatch remains. |
| Business App remains on startup loading during notification setup | Provider setup did not reach a source-confirmed settled state | Stop. Do not change permission or reinstall. Record the platform and visible loading state for support. |
Variations and limits
- Notification-provider initialization is conditional on the project's Business App notification configuration and an authenticated session.
- The app can associate provider state with account contact details and project/user context. Permission is not consent to every provider-side association, and this article does not claim or test those effects.
- The app requests service registration when local provider state changes, but the current client does not inspect the response. No registration receipt is shown.
- Operating-system prompts, settings screens, permission states, background handling, sound, badges, and delivery can differ between iOS and Android and by installed version.
- In-app events can use realtime connections, sound, or vibration independently of operating-system push permission.
- Source and API evidence describe intended behavior at the documented pins. They do not establish the installed build, deployed API, provider configuration, delivery, or root-to-nested navigation result.
Related articles
:::note Visual status authorized synthetic capture program with accepted exact asset allowlist and independent visual QA :::