Before you begin

The affected workspace, channel, and approximate time
One redacted example conversation or message identifier
Administrator access to channel settings or an administrator available to help

Preserve one example first

Record the workspace slug, channel/sender, direction, approximate timestamp and timezone, conversation/message ID, expected result, actual visible status, and exact error. Use one authorized example. Do not reconnect or resend until you know whether the first attempt may still complete.

Narrow the failure before escalating

01
ScopeConfirm scope
Identify the workspace, record, channel, time, and affected users.
02
ObserveCheck visible state
Read the current status instead of repeating the action.
03
TraceReview history
Use delivery events, audit history, or run logs to find the last good step.
04
RecoverTry safe recovery
Retry only when duplication and customer impact are understood.
05
EscalateEscalate with redacted evidence
Share expected versus actual results without secrets or excess customer data.

Start with one record, test each boundary in order, apply one safe recovery, and preserve sanitized evidence.

Locate the failed boundary

What works	What fails	Likely boundary to inspect first
Settings show Connected	No inbound conversation	Provider subscription/sync, exact sender, or receiving path
Inbound appears in All Work	Wrong team inbox	Team-inbox route/default route
Inbound works	Outbound fails immediately	Default sender, direct sending, authorization, message/template, or recipient rule
Outbound shows Sent	Customer reports no receipt	Provider/recipient delivery after acceptance
One recipient fails	Other recipients succeed	Address/number, consent/suppression, or recipient-specific provider response
Every send fails	Inbound still works	Outbound authorization or send readiness
Private Mail sync fails	Work email still works	Personal-mail provider scope/token, not shared-email transport

Check the current connection

Open Settings → WhatsApp. Verify the exact sender, Connected/Disconnected state, connection mode, default sender, and any sync warning. A historical sync warning does not necessarily stop new messages, so test transport separately.

Shared email

Open Settings → Email. Verify the shared address, receiving state, and direct Microsoft 365, Google Workspace, or SMTP sending. A fallback sender does not prove the shared identity is ready.

Private Mail

In Inbox → Private Mail, review the selected account's sync status and provider connection. Confirm whether the issue affects one mailbox, one folder/policy, or every personal account.

Check inbound receipt

Send a unique harmless test from an approved external account.
Search All Work with broad filters and All channels.
For email, inspect Other or Quarantine if the message did not enter the primary view.
Verify the exact destination number/address and timestamp.
If nothing arrives, review provider/connection evidence; do not alter routing yet because routing cannot move a message WRKZY never received.

Check team routing

If the conversation exists but reaches the wrong queue:

Open Settings → Messaging → Team inboxes.
Confirm the channel is attached to the intended inbox.
Review explicit routes and default routing.
Check whether the inbox is Active and its members are correct.
Retest with a new unique inbound message.

Connection before routing

01
SourceConnected channel
WhatsApp, shared email, or another supported source receives the message.
02
RouteTeam inbox
Channel rules place the conversation with the responsible team.
03
TriageQueue and priority
State, SLA, and filters determine when it needs attention.
04
OwnAccountable owner
One teammate becomes responsible for the outcome.
05
ActReply, resolve, or follow up
The conversation ends with a visible result or next action.

First prove WRKZY received the message, then prove the channel route selected the intended team inbox and owner.

Check outbound submission

Open the exact failed message.
Read Sending, Sent, Delivered, Read, or Failed.
For email, inspect Delayed, Bounced, Complaint, or Failed provider events.
Verify the connected/default sender and recipient.
For WhatsApp, verify the allowed template/message path and any recipient restriction.
For email, verify direct-send readiness and send-as permission.
Correct one known cause and retry once only when the original attempt is terminal and non-delivered.

Submission is not recipient delivery

01
LocalPrepared
Content and recipient are ready but nothing has left WRKZY.
02
PendingSubmitted
WRKZY handed the request to the connected provider.
03
AcceptedProvider accepted
The provider accepted processing, not necessarily delivery.
04
ResultDelivered or failed
A terminal provider event confirms delivery or an exception.
05
RecoverException reviewed
An owner diagnoses, recovers safely, or escalates with evidence.

A successful composer action can still be awaiting provider acceptance or recipient evidence; use the exact state to choose recovery.

Symptoms and safe recovery

States and meaning
State	Meaning
Disconnected	Reauthorize through the intended provider after confirming company ownership; avoid deleting the connection first
Sending	Wait, refresh, and inspect delivery health before retrying
Failed	Read the error, correct sender/recipient/authorization/content cause, then perform one controlled retry
Sent without Delivered	Provider accepted the attempt; wait for supported receipt evidence or inspect provider delivery
Delayed	Monitor for a later Delivered or terminal email event; do not duplicate
Bounced	Correct the address/reason and review suppression before another send
Complaint	Stop further inappropriate contact and escalate consent/suppression review
Wrong queue	Fix team-inbox routing and retest with a new inbound message

Avoid destructive troubleshooting

Do not remove a sender to refresh the screen.
Do not overwrite working OAuth/SMTP settings without recording the current configuration owner.
Do not send repeated templates or emails to a real customer.
Do not change several routing rules at once.
Do not import historical email until live receive/send behavior is stable.
Do not share passwords, app passwords, OAuth codes, Meta tokens, webhook secrets, or customer message exports.

Escalate with useful evidence

Provide impact, workspace slug, channel/sender label, direction, timestamp/timezone, safe record/message ID, exact state/error, which boundaries passed, and one redacted crop. State whether a retry could duplicate delivery. Provider identifiers shown specifically for support may be included only when needed and should never include secrets.

Verify recovery

Repeat the smallest test that previously failed. Confirm connection health, inbound queue, assignment, outbound state, and external receipt as applicable. Then monitor the next few real cases and document the cause so the team does not repeat the unsafe workaround.

Channel recovery check

One example preserved
Failure boundary identified
Connection checked before route
Route checked before assignment
Exact message/provider state read
One cause changed at a time
Ambiguous send not repeated
Recovery retested end to end
Evidence contains no secrets