Connect by JBRH Open Connect

SMS will not send

On the live carrier this is expected rather than broken: that carrier carries no SMS, so no text can leave. Check in one order — a provider that carries SMS, then DLT registration if you are sending in India, then suppression on the recipient, then the autonomy rule. The first unmet condition is the answer, and the ones below it were never reached.

Status
Foundation In development What this means
Audience
both
Channels
sms
In the app
#/calls, #/dlt, #/follow-ups
Last verified
Product version
6.3.2

What the symptom looks like#

There is no compose box on a conversation that arrived by text, or a follow-up booked on the sms channel sits on the follow-ups screen past its date without draining, or a request to the Assistant to text somebody comes back as a refusal with a reason rather than as a sent message.

What you will not see is a message that claims to have been sent. A send is recorded as sent only against a provider's acknowledgement, so an unsendable message shows as unsent rather than as delivered-and-missing. If you ever see the opposite, that is a defect worth reporting; this page is about the ordinary case.

What it means#

SMS is a foundation channel here. The model, the service and the tests exist and the inbound half runs in production; outbound depends entirely on the configured provider. On the live account that provider carries no SMS traffic at all, which makes an unsent text the correct outcome rather than a fault to chase.

Causes, in order of likelihood#

  1. No provider that carries SMS. The overwhelmingly common cause, and the one that applies to every workspace on the live carrier. Nothing below this matters until it is resolved.
  2. DLT registration missing or mismatched, in India. With a provider in place, an unregistered header or a message that drifts from its registered template is rejected by the operator before delivery.
  3. The recipient is suppressed. An opt-out word in an earlier message, a block:sms directive, or a do-not-contact entry against the contact. The refusal is recorded with its reason.
  4. The autonomy rule for sms is off or draft_only. The first disables the channel; the second prepares and stops on purpose without even asking.
  5. The daily allowance is spent, on a customer workspace. The work is not lost; it waits, and the refusal is recorded rather than silent.

What Connect completed#

  • Received, verified and stored the inbound message that prompted the reply, if there was one.
  • Attached it to the right Person, so the relationship and the timeline are correct and complete.
  • Evaluated the send against suppression, autonomy and allowance, and recorded the outcome as a decision with a reason.
  • Kept any follow-up booked on the sms channel visible on the follow-ups screen rather than cancelling it.
  • Left the conversation open and answerable on a channel that does work.

What Connect did NOT complete#

  • It did not hand a message to a provider, because there is no provider carrying SMS to hand it to.
  • It did not obtain, check or stand in for a DLT registration — those are grants from the telecom operators, and Connect stores them rather than granting them.
  • It did not queue the text for later delivery in a hidden retry loop. Nothing is waiting to surprise a recipient when a provider is eventually configured.
  • It did not notify the customer that their message could not be answered by text. If that matters, a person or a follow-up on another channel has to do it.

What you can do, and what an administrator can do#

  1. Answer on a channel that works — email, WhatsApp or phone — and book it as a follow-up with the inbound text as the reason.

    Result The customer is answered and the record shows why the reply travelled a different way.

  2. If a follow-up is stuck on sms, move it to a channel that can carry it rather than leaving it to age.

    Result It drains normally, and nobody has to remember it by hand.

  3. An administrator confirms whether the workspace has a provider that carries SMS at all before investigating anything else.

    Result On the live carrier the answer is no, and the investigation is over in one step.

  4. In India, an administrator checks the entity, header and template grants recorded at #/dlt against what the operator actually issued.

    Result A recorded value that was never granted is the second most common cause of an unsent message once a provider exists.

Questions#

Will my message send later on its own?

No. There is no hidden queue holding unsendable text, which is deliberate: a message delivered weeks after it was written is often worse than one never sent. Re-send deliberately on a channel that works instead.

Does this affect WhatsApp?

No. WhatsApp is a separate channel with its own provider and its own credentials, and it sends. If WhatsApp is also failing, the cause is that channel's own, not this one.

How do I know which of the five causes applies to me?

Work down the list in order and stop at the first unmet condition — the ones below it were never evaluated. The Decision Log names the reason for a refusal that did reach the send boundary, which distinguishes a suppression or an allowance from a missing provider.