Reject a delivery request

Rejecting a delivery request is an operational mutation. Driver App has different rejection paths for a plain order, a logistics assignment, and a group presentation. This procedure covers the visible plain-order detail flow and explains the boundaries of the other paths.

:::warning Reject can change assignment and order state immediately

The final Reject can update the order, remove or change Driver assignment, write history, and start notifications, sockets, jobs, and logistics work. Do not select it to test visibility, permissions, location, reasons, navigation, or documentation.

:::

Availability

On a plain order detail, the Reject action can be presented for selected order states when reject buttons are not hidden by configuration. The visible button is not authorization: selecting it also checks whether Driver rejection is explicitly allowed for the current project.

The action can remain unavailable or redirect when:

• the returned order state does not present Accept/Reject controls;
• reject controls are hidden by configuration;
• Driver rejection is not allowed by the separate local configuration gate;
• the App's local location-permission gate does not pass;
• order data or another action is loading; or
• connectivity is unavailable and offline status changes are disabled.

A local permission gate is not proof that every effective device permission is granted. Opening Reject Order also mounts a location hook and can request a GPS position before submission, even though the plain rejection request does not require or include that candidate location.

Before you start

• Confirm that the detail is the intended authorized plain order, not a logistics assignment or grouped presentation.
• Review the order and current assignment with the dispatcher when ownership is uncertain.
• Prepare a meaningful explanation. The UI requires a nonempty comment but does not reject whitespace-only text; do not rely on that weak validation.
• Do not enter or share coordinates. Location is not a rejection reason.
• If Upload status image appears, stop before opening the camera. Reject itself does not require a PIN, but project image configuration can still block the final button; this guide does not authorize capture or media upload.
• If another request is loading, do not begin a second rejection.

Complete the task

1. Open the intended plain order detail and select Reject once.
2. If Driver App says the Driver is not allowed to reject, close the alert and contact the dispatcher. Do not bypass it through another route.
3. If Request permissions opens, stop and review the permission state before returning. A returned order screen is not permission success.
4. In Reject Order, select a Reject reasons option when one accurately describes the situation. The dropdown reason is optional in the current App.
5. Enter a clear, meaningful comment in Please type your comments in here. The comment must be nonempty; loading or another configured requirement can also keep the final button disabled.
6. If Upload status image appears, stop and use the approved proof/media process or contact the operator. Do not reuse an unrelated image or infer capture/upload success. Reject itself has no PIN step.
7. Review the note that the customer may receive a notification. This is intent, not a delivery guarantee.
8. Select the final Reject once. Wait while the order is loading; do not repeat the action if the modal, order, or navigation result is unclear.

The inline plain-order modal suppresses the customer-phone action. Use the separate contact guide when communication is operationally required; do not use a dormant dedicated page as a substitute.

Verify the result

Observable result	Safe interpretation
Not-allowed alert	The local Driver-reject config gate blocked this route
Request-permissions screen	The local permission gate did not admit the modal
Reject modal	Local reason/comment UI is open; GPS work may already have started
Final Reject disabled	Comment is empty, another configured requirement is unresolved, or the order is loading
Upload status image visible	Project configuration added a media prerequisite; this guide does not authorize capture/upload
Order loading	A status update is unresolved
Error state	One request layer reported failure; concurrent/order/logistics effects still require reconciliation
Modal remains visible	The inline flow has no uniform successful-close receipt
Order/card disappears or changes status	Client navigation/state changed; final assignment, queue, notification, and follow-ons are not proved
Customer notification note/toast	UI intent/presentation only; push delivery is not proved

If the result is unclear, do not reject again. Ask the dispatcher to verify the current order, assignment request, and any grouped/logistics members.

States and variations

Plain order

The inline path submits a rejection update with the required comment and optional reject-reason value. The current service contract separately checks Driver ownership, allowed target status, order lock, and other order rules. The App's project rejection gate is local and does not replace service ownership.

Logistics assignment

A logistics detail uses an assignment-request decision rather than the plain rejection form. Selecting Reject can navigate back immediately before the assignment request settles. A toast or returned list is not rejection success. Review Logistics assignment requests for its distinct entry and lifecycle.

Grouped request

A grouped logistics decision can affect the assignment group and member orders through a different contract. It is not one atomic plain-order update. The separate grouped plain-order batch path is hidden in the current productive Driver flow and must not be used as a public rejection path.

Troubleshooting

Reject is visible but the not-allowed alert appears

Visibility and Driver-reject authorization are separate configuration gates. Close the alert and ask the operator to confirm policy. Do not try a notification, map, grouped, or logistics route to bypass it.

Reject Order opens slowly or location activates

The form mounts a location hook before the final action. Wait for the current screen; do not refresh GPS or open Settings as a rejection test. The plain rejection payload does not use that candidate location.

The reason list does not contain the situation

Choose Other when accurate and explain the situation in the required comment. Do not select a false reason merely to continue.

The modal remains after Reject

Do not press Reject again. The inline flow does not provide a uniform close receipt. Return only when safe and ask the dispatcher to reconcile the order and assignment state.

Upload status image appears

Stop before opening the camera or picker. Use the approved proof/media process or contact the operator. Do not infer that an image or PIN is a verified rejection result.

A logistics request returned to the list

Back navigation can occur before the assignment decision settles. Do not act on the same request again or assume every group member changed. Wait for a current read and escalate an uncertain or partial result.

Related guides: Accept a delivery request · Logistics assignment requests · Find delivery requests · Understand Driver permissions