Do not send order messages yet

:::warning Order-message sends are blocked Do not send text, images, signatures, or files from an order conversation using this guidance. Current evidence does not establish a safe authorization and result boundary for every send. :::

You may read a conversation that you opened from the intended Messages inbox, but a visible order, participant, composer, attachment control, or send button is not proof that a new message is authorized for that order.

Before you start

• Open the conversation from Messages and confirm the business and order number. Do not use an old link or a conversation left open for another order.
• Treat participant names, message text, phone numbers, email addresses, images, signatures, and files as private customer and operational data.
• Do not select an attachment merely to test the picker. A selected image is prepared in the app and can be uploaded if a send is attempted.
• Do not assume that a participant chip proves who will receive a message.

Record the conversation state safely

1. Keep the intended business and order visible. Do not enter private text in the composer and do not select the send control.
2. Note which participant indicators are active, but do not treat them as a delivery list or ownership proof.
3. If a previous attempt showed an error, refresh the conversation once before doing anything else.
4. Record only the minimum visible state required by the project administrator or approved support process. Do not copy unnecessary customer data.
5. Escalate the blocked or uncertain send without retrying it.

The source-intended send is a remote operation: text can be stored as an order message, and a selected image can be uploaded before the message is stored. After storage, the service can attempt realtime and notification effects for selected participants. An error, spinner ending, new local bubble, socket event, or notification is not enough to prove ownership, persistence, delivery, participant read state, or provider completion.

If a send was already attempted

What you observe	What it means	Safe next action
The new bubble appears	The app received or merged message-shaped data	Refresh once and compare the latest conversation before taking another action. Do not infer delivery or participant read state.
An error appears	The request reported or encountered a failure, but storage may have occurred before a later ownership or provider step failed	Do not retry. Refresh once, record the minimal visible result, and escalate the uncertain outcome.
The composer cleared but no bubble appears	The client can clear draft and attachment state immediately after starting the request	Do not retype or resend. Refresh once and escalate if the result remains unknown.
The same content appears twice	Separate attempts or later events may have produced duplicates	Do not delete or send a correction from this guidance. Record both entries and escalate.
Participant indicators or order details changed	The open conversation may be stale or belong to a changed order state	Return to Messages, reopen the verified order, and do not send.
An image was selected	Private image data was prepared for a possible upload	Remove it without sending. If a send was attempted, treat upload and persistence as unknown and escalate.

Attachments are not a safe workaround

• The visible image control can select a photo and prepare it for a remote message upload. Do not select or send private customer, payment, identity, health, or other sensitive material.
• The visible file picker can select a document, but the traced Business App flow does not establish a supported document send from that selection. Do not use it as an alternative to the blocked image or text path.
• A signature is handled as image data in the composer. It has the same privacy, upload, persistence, authorization, and delivery boundaries as another image.
• Picker cancellation, picker permission, upload success, storage cleanup, and recipient access were not verified on an installed build.

Contact actions in message text

Recognized content can hand work to the device or another provider:

• Pressing a web address can ask the operating system to open it.
• Pressing an email address can ask an installed mail app to start a draft.
• Pressing a phone number opens a confirmation sheet with Call and Text.
• Pressing and holding message text opens Copy Text, which places that text on the device clipboard.

Before choosing one of these actions, verify the displayed destination and consider whether the message contains private data. The handoff leaves Business App. Device support, permissions, installed apps, provider acceptance, call or SMS connection, email delivery, browser safety, and clipboard retention are not guaranteed. If the external app does not open, return to Business App and use the project's approved contact process; do not repeatedly activate the link.

Why sending remains blocked

• The available send path does not provide a safe ownership, upload, persistence, and returned-error boundary for every admitted account scope.
• The read-state endpoint separately lacks enough evidence to guarantee order ownership or participant read receipts. Opening or leaving the conversation must not be interpreted as delivery or read confirmation.
• Text and image are the only send forms established by the traced client. The visible document picker is not wired into the traced send body.
• Local clearing, local bubbles, realtime events, notifications, and returned errors do not provide an atomic result or a duplicate-safe retry contract.
• The relationship between the documented source and deployed app, API, socket, notification, device, and external providers is not attested.

When sending steps can return

Order-message steps can be restored only after all of these conditions are met:

1. A corrected, pinned API proves order ownership and participant visibility before any attachment upload or message persistence.
2. Positive and negative authorization tests cover administrators, business managers, customers, drivers, and driver managers without treating technical access levels as commercial roles.
3. Text, image, document-picker, error, duplicate, stale-order, read-state, socket, and notification behavior is retraced at the accepted versions.
4. An authorized synthetic W4 runtime receipt proves the allowed remote effects and cleanup, and an independent D3 review covers picker, clipboard, call, SMS, email, and web-provider handoffs.
5. Independent content and safety review accepts the revised procedure.

Availability and platform differences

• Sending controls depend on the order state, returned participant data, account scope, connectivity, and platform picker/provider availability.
• A finished order can disable the composer. This local state is not a server authorization guarantee.
• Quick-message choices depend on the signed-in technical account level and configured translations; they are draft aids, not delivery contracts.
• Phone, tablet, iOS, and Android behavior was not verified in an installed build. No provider completion or visual-parity claim is made.

Related articles

• Find an order conversation
• Understand technical access levels and business scope
• Recognize loading, connection, and error states

:::note Visual status Visual guidance is deferred. Reopen trigger: authorized synthetic capture program with accepted exact asset allowlist and independent visual QA. :::