Reject a pending order safely
Reject an order only when it is still Pending and cannot be fulfilled. A successful rejection records your written reason, moves the order toward Rejected by business, and can trigger customer-facing updates. Confirm the result for every affected order; a closed screen or notification does not prove that the rejection or every follow-up completed.
Before you start
- Sign in to the intended project and business scope, then open Orders.
- Refresh the queue and match the order number, business, customer, items, and current Pending status to the decision you intend to make.
- If you are rejecting a grouped set, refresh and review every displayed order. Confirm that each member is intended and still Pending. The app checks the first order before showing Reject all, but submits the same reason for every displayed group member without filtering their individual statuses.
- Prepare a clear, customer-safe reason. Business App requires a written comment; it does not use the preset reason picker shown in some other apps.
- Treat rejection as a remote order change. Do not repeat it while the result is unknown.
Reject the order
- From a pending order, select Reject. For a displayed group, select Reject all only after confirming that every member is intended and still Pending; the visible group action is gated by its first order only.
- Review the Reject Order screen. If a customer phone button appears, use it only when your operating procedure requires contact. Selecting it hands the number to the device phone app; it does not confirm that a call started or connected.
- Enter the rejection reason in Please type your comments in here. The Reject button remains unavailable while the comment is empty. If the app reports a length validation error, shorten the reason to 255 characters or fewer.
- Before selecting Reject, preview the effect: a single order or every displayed group member is submitted with the same reason. Each accepted order can leave Pending and trigger configured notifications, email, realtime updates, webhooks, or logistics follow-up. A mixed or stale group can produce different results for its members.
- Select Reject once. Wait for the current update to finish before navigating away or trying again.
Verify the result
Return to Orders, refresh, and verify each affected order separately.
- A verified rejection shows the intended order as Rejected by business in the Cancelled group or in its refreshed order details.
- If a grouped set was submitted, confirm every displayed order number and current status. The rejection screen can close after receiving one result slot per order even when a non-pending member was submitted or one or more individual updates failed.
- A customer notification, email, realtime event, or phone-app screen is not proof of the saved order status. Those follow-up channels can finish, fail, or arrive separately.
- If the app was offline or reconnecting, a local change can be stale or unsynchronized. Reconnect and refresh before treating the order as rejected.
Recover safely
| What you observe | What it means | Safe next action |
|---|---|---|
| Reject is unavailable | The comment is empty, or the order update is already loading. | Enter a clear reason or wait for the current attempt. Do not tap repeatedly. |
| Reject or Reject all is missing | The order is not currently pending, the view is stale, or offline actions are unavailable. | Refresh and verify the exact status, scope, and connection. Do not force a different status. |
| A validation, permission, locked-order, status-change, or network error appears | The service did not accept the current request as submitted. | Keep the visible message, refresh the order, correct only the stated problem, and retry once if the status is still Pending. |
| The rejection screen closes but an order remains Pending | A grouped request may have failed partially, or the list may be stale. | Refresh every submitted order. Retry only the intended still-pending order once; escalate persistent mismatches to the project administrator or Ordering support. |
| A submitted group member shows a different non-pending status | Reject all submitted the displayed group IDs without rechecking each status, or another actor changed the order first. | Stop. Reopen that order and follow its current workflow instead of repeating rejection. Verify the other group members separately. |
| The device phone app does not open, or no call result is visible | The optional device handoff was unavailable or its result is outside Business App. | Contact the customer through an approved alternative if required. Do not treat the order as rejected until its status is verified separately. |
| A notification or realtime update is missing | A follow-up channel can fail or lag after the order update. | Verify the saved order status by refreshing. Escalate the missing channel separately; do not repeat the rejection solely to resend it. |
Availability and platform differences
- Reject is available for a pending order in order details. A displayed group's Reject all visibility checks only its first order for Pending, then submits every displayed group member without filtering each status. Refresh and verify every member before submission and again afterward.
- The Business App flow uses a free-text comment as the rejection reason. It does not expose the preset rejection-reason list used by the driver flow.
- When the app cannot perform or retain offline actions, status controls are unavailable. When it retains an offline change, there is no supported pending-action indicator that proves later synchronization.
- The customer phone button appears only when the loaded order includes a customer mobile number. It opens the platform phone handler and is separate from the remote rejection.
- Visible behavior describes the current documented source contract. Deployed app, API, phone provider, notification, email, webhook, and realtime parity are not established by this article.
Related articles
- Review an order before taking action
- Understand order queues and statuses
- Loading, connection, empty, and error states
:::note Visual status Visual guidance is deferred pending an authorized synthetic capture program and independent visual QA. :::