--- title: "Understand notifications and order handoff" description: "Distinguish notification permission, device registration, delivery, in-app events, and order handoffs." canonical: https://docs.ordering.co/docs/products/business-app/app-behavior/notifications-order-handoff/ --- # 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 app can 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 confirmed. | | 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 app attempted an order handoff while signed in and loaded | This guide does not establish that the 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: 1. Permission is a device setting. Verify it in the operating system, not from notification delivery alone. 2. Device registration is an app/provider/service exchange. Business App does not display a registration receipt in this flow. 3. Delivery is an operating-system/provider outcome. Permission and registration do not guarantee it. 4. The in-app new-order modal is a realtime app event. It does not prove an operating-system push was delivered. 5. 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. - Installed-app behavior, service configuration, provider delivery, and the navigation result can vary and are not established by this guide. ## Related articles - [Understand new-order alerts](https://docs.ordering.co/docs/products/business-app/orders/new-order-alerts/) - [View an order](https://docs.ordering.co/docs/products/business-app/orders/view-order/) - [Recognize loading, connection, and error states](https://docs.ordering.co/docs/products/business-app/app-behavior/loading-connection-errors/)