Sending Messages
Once an account is configured, sending happens from several places and all of them land in the same log.
Where to find it
Architect Panel → Communication:
- Message Log — every message, its state and its cost
Where to find it
Architect Panel → Activity:
- SMS Log — the sending record from the platform side
Where sends come from
- Workflows — a send action at a stage, which is how most operational messaging works: an appointment reminder, a status change, a code.
- Campaigns — a bulk send to a selected audience.
- Platform paths — two-factor codes and password resets, which use the same accounts.
Delivery is not immediate
A message is queued, dispatched and then reported on by the provider. The states matter: accepted by the provider is not delivered to the handset, and delivered is not read. Build any process that depends on a message on the state you actually have.
The drain task
Outbound dispatch and inbound processing are driven by the Inbound Message Drain task, which ships disabled and should run every minute. Messaging that appears to do nothing at all is almost always this task not being enabled.
Message content
Keep it short and identify yourself. A message that does not say who it is from reads as spam, and recipients report it. Include a way to stop — both because people expect it and because it keeps your sending reputation intact.
Timing
Do not send outside reasonable hours. A two-factor code at 3am is fine because the user asked for it; a marketing message is not, and a reminder is arguable. Where the send is scheduled rather than triggered, constrain the window.