Sending SMS: what is available today
Connect does not send SMS on the live carrier, because that carrier carries no SMS traffic. Outbound text depends entirely on the configured provider, and in India additionally on DLT registration. Rather than presenting a thread you could type into and a message that would never leave, the Phone screen reports the channel's readiness and says which condition is unmet.
The two conditions, and why both are unmet#
| Condition | Who satisfies it | State on the live account |
|---|---|---|
| A provider that carries SMS | The workspace, by configuring one | The carrier in use carries none |
| Credentials for that provider | The workspace | Nothing to configure while the first condition is unmet |
| DLT registration, in India | The business, with the telecom operators | A separate process; see DLT registration in India |
| An autonomy rule permitting the send | The workspace, in What Connect May Do | Configurable now, but has nothing to govern yet |
| No suppression on the recipient | Enforced at the send boundary | Already enforced, already recorded |
The order is the diagnostic. There is no point examining an autonomy rule or a suppression entry while the first row is unsatisfied, because nothing reaches those checks. That is also the order SMS will not send works through.
Why the screen refuses rather than pretends#
The alternative design is common and worse: show a compose box, accept the text, queue it, and let it fail somewhere a person will not look. That produces a business that believes it answered a customer. The readiness reported on the Phone screen exists so the failure is visible at the point of decision instead of hours later in a log.
The same instinct runs through how a send is recorded everywhere in Connect: a message counts as sent when a provider acknowledges it, never when it was handed over hopefully. A channel with no provider that can carry it has nothing to acknowledge, so it does not get a compose box. Why 'sent' must require provider evidence is the longer argument.
What changes when a provider that carries SMS is configured#
- The send runs through the same boundary as an email send, under the same autonomy modes:
off,draft_only,ask_before_send,autonomous. - Suppression,
block:smsdirectives and do-not-contact entries already recorded start refusing sends immediately — nothing needs to be migrated or re-entered. - On a customer plan, each send is metered against the workspace's allowance in the same ledger every other channel uses.
- Follow-ups already scheduled on the
smschannel become drainable instead of stalling, and the ones that were rescheduled onto other channels stay where they were put. - In India, none of that is sufficient on its own: an unregistered header or a message that drifts from its registered template is rejected by the operator regardless of what Connect does.
What does not change is the shape of the record. Inbound SMS already becomes a canonical message on a conversation attached to a person; an outbound one would join the same conversation. There is no second data model waiting to be switched on.
What to do meanwhile#
Keep receiving. Inbound handling, deduplication, attachment and opt-out are all working.
Result Text arriving at the business is filed, understood and actionable even though it cannot be answered in kind.
Book the reply as a follow-up on a channel that works — email, WhatsApp or phone — with the inbound text as its reason.
Result The customer gets an answer, and the reason it went out on a different channel is on the record.
If SMS is genuinely required, start the provider question and, in India, the DLT process in parallel.
Result The two conditions are independent and both take outside time; running them one after the other doubles the wait for nothing.
Questions#
Is this a bug I should report?
No. It is a stated limit of the channel rather than a fault: the carrier on the live account carries no SMS. A page that told you otherwise would be the defect. What is worth reporting is a screen that implies a text was sent.
Can I send one manually from my own phone and have it recorded?
Nothing stops you texting a customer yourself, but Connect will not know about it — the record here is built from what providers report. If the exchange matters to the relationship, note it against the contact so the history is not missing a piece nobody can see.
Do follow-ups scheduled on SMS disappear?
No. They stay on the follow-ups screen with the channel they were booked on. A follow-up that cannot be drained sits there visibly rather than being silently cancelled, which is the behaviour you want when the reason is external and may change.