--- title: "Recognize a new order and open it safely" description: "Distinguish in-app, device, and operating-system alerts, then verify the order from a current queue." canonical: https://docs.ordering.co/docs/products/business-app/orders/new-order-alerts/ --- # Recognize a new order and open it safely The Business App can surface incoming order activity in several ways. An in-app notice, vibration, operating-system notification, and a new card in the **Orders** queue are related signals, but they do not share the same delivery path or prove that the order view is current. ## Before you start - Sign in to the intended project and business scope, then open **Orders**. - Keep a network connection when you rely on incoming activity. - Allow operating-system notifications if you want device notifications. This permission is separate from the in-app realtime connection. - Keep the app audio at an appropriate level for the workplace. Sound and vibration depend on device settings, platform behavior, and provider state. ## How alerts reach the workspace | Signal | What it means | Availability or gate | What to do next | | ---------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | **New orders have been received!** | The open app received an eligible incoming-order event and displayed its order number | The realtime connection, account scope, configured notification statuses, and event data must all qualify | Close the notice, find the order in the appropriate queue, and open it. | | Repeating alert sound | The in-app notice is still open | Audio playback, network access to the sound, and device volume must be available | Close the notice after noting the order number. Do not use sound as proof that the order loaded. | | Vibration | The signed-in app received the incoming-order socket event | Device and platform vibration behavior must be available | Check the queue; vibration does not identify the order by itself. | | New or updated card | The order list applied an incoming event to its local groups | The event must match the visible business and status scope | Match the order number and status, then open the card. | | Operating-system notification | The push provider attempted a device notification | Project configuration, permission, token registration, provider delivery, and device state all apply | Open the app and verify the order from **Orders**. | The in-app notice has a close control; it does not open the order detail by itself. On a phone or narrow layout, select the matching card to open the order view. On a wide tablet, select the matching card and review the detail shown on the right. ## Verify the order 1. Note the order number shown by the notice or device notification. 2. Close the in-app notice if it is covering the workspace. 3. In **Orders**, check the relevant queue and clear filters if the order is not visible. 4. Confirm that **Status** shows **Ok**. If it shows **Connecting** or **Disconnected**, reconnect and refresh. 5. Open the matching order and verify its order number, business, current status, fulfillment type, items, and totals before using an action. ## Limits and variations - The project can configure which order statuses produce the in-app notice. That setting does not guarantee that every incoming event produces sound, vibration, or a device notification. - An event can add a card to a local queue while another filter, business scope, or page keeps it outside the current view. - Operating-system notification permission does not repair a disconnected realtime session, and a realtime event does not prove push delivery. - Opening an order from an operating-system notification is source-intended, but is not established as a reliable path for the current release. Open **Orders** and select the matching card when the notification does not reach the order view. - Provider delivery, alert timing, audio repetition, vibration, and deployed build behavior can vary. This article does not guarantee any of them. ## Troubleshooting | What you observe | Likely boundary | Safe next action | | ----------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | No in-app notice appears | The connection, event, account scope, or configured status may not qualify | Check **Status**, refresh the queue, and verify filters and business scope. | | The notice appears but there is no sound or vibration | Device volume, vibration, platform, or audio delivery may be unavailable | Use the order number in the notice and verify the queue; check device settings only if alerts are expected. | | **Enable notifications** appears | Operating-system notifications are blocked | Open device settings from the prompt if authorized, then return to **Orders**. | | A device notification opens the app but not the order | The notification-to-detail handoff did not complete | Open **Orders**, refresh, and select the matching card. | | The alerted order is missing | The queue can be stale, filtered, paginated, or outside the signed-in business scope | Reconnect, clear filters, check the relevant queue, load more results, and ask the project administrator to verify scope if it remains missing. | ## Related articles - [Review an order](https://docs.ordering.co/docs/products/business-app/orders/view-order/) - [Monitor current orders on a phone](https://docs.ordering.co/docs/products/business-app/orders/phone-queue/) - [Use the tablet order workspace](https://docs.ordering.co/docs/products/business-app/orders/tablet-workspace/)