# Sending messages

How the Send message step works: channel, sender, the consent policy each message requires and what happens when a message can't be sent.

**Language:** en
**Audience:** platform
**TLDR:** The Send message step sends one SMS, or an RCS with SMS fallback, and the flow moves on at once. Each message has its own consent policy: by default Basic (or your project's default for the channel), which reaches every subscribed contact even if they declined marketing; select No opt-out or Opt-in, or add a Check consent step, to respect that choice. If a message can't be sent, the run stops there unless you turn that option off.
**Translation key:** platform.automations.flows.sending-messages
**Search keywords:** send SMS, send RCS, SMS fallback, sender, Basic, No opt-out, Opt-in, marketing consent, received although opted out, got the message after saying no, stop the run, message not sent, variables, event variables, personalization, quiet hours, replied STOP during the flow
**Related pages:** /platform/es/automations/flows/sending-messages, /platform/en/automations/flows, /platform/en/automations/flows/waits, /platform/en/automations/flows/branches, /platform/en/campaigns/compliance-policies, /platform/en/channels/rcs/sms-fallback, /platform/en/consent
**Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt
**This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/llms.txt
**This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/sending-messages/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/sending-messages.md (Markdown)
**Other language (es):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/sending-messages.md

The **Send message** step is where a flow actually talks to the contact: when a
contact reaches it, the step sends them one message — an SMS, or an RCS message with
an SMS fallback — and the contact moves straight on to the next step. The step doesn't
wait to find out whether the message was delivered, read or clicked, and it has no
"success" or "failure" exits. When you want the flow to react to what happened, you
add a wait after it: a **Wait for delivery** splits on whether the message arrived, and
a **Wait for activity** waits for a click, a tap or a reply (see [Waits](/platform/en/automations/flows/waits)).

Each Send message step carries everything about its message: the channel, the sender,
the text in every language, and two settings that decide **who actually receives it**
and **what happens to the contact when it can't be sent**. Those two settings are the
part of a flow that most often surprises people, so they get their own sections below.

## Add a message

Messages are added from the step palette, which opens from any **+** on the canvas
(see [Building a flow](/platform/en/automations/flows/building-a-flow)). The **Send**
group offers two entries:

- **Send SMS** — a text message. Every phone can receive one.
- **Send RCS** — a branded message, with an SMS fallback if it can't be delivered. It
  only appears when RCS is available in your project; see
  [What is RCS](/platform/en/channels/rcs/what-is-rcs).

On the canvas both become a **Send message** step, showing its channel and the start of
the text. The channel is fixed when you add the step: to turn an SMS into an RCS
message, or the other way round, delete the step and add the other one in its place.

Clicking the step opens its message in **Edit message**; the arrow next to that title
returns you to the flow builder. Faded labels above and below the message name the steps
around it, and **End of the branch** marks where its branch ends. The centre holds the message — one card per channel, so an RCS
step shows its RCS card and, below it, the SMS fallback card. On the right, a preview
tab per channel shows the message on a phone, and the **Advanced** tab holds the step's
settings.

![The message editor of a Send message step with sender, text and phone preview](/platform/en/automations/flows/images/sending-messages--1-message-editor.png)
*The step's message opens in its own editor.*

### Sender

Each channel card starts with its own **sender** picker. In a flow the sender belongs
to the step — and to each channel of the step — rather than to the whole flow, so two
messages of the same flow can be sent from different senders.

The first time you open a step, the sender is already filled in: with the one the
flow's other messages on that channel already use, or, if there are none, with your
project's default sender for the channel. Check it before you publish. If the project
has no sender for that channel yet, the picker stays empty and lets you create one.

### Text, languages and variables

The message is written in the message composer: the text, attributes such as the first
name, links, the unsubscribe link, emoji, AI writing tools and, for RCS, quick actions.
You can add a version of the text per **language**: each contact receives the one for
their language, and anyone else receives the default text. The composer's tools are
described in more detail in
[Creating a campaign › Message](/platform/en/campaigns/creating-a-campaign#2-message).

One thing is specific to flows: **event variables**. Because a contact enters a flow
when an event happens, the message can quote that event's data. The composer toolbar
shows a button named after the trigger event (for example **Order created**) that
inserts its parameters, such as `{{_event.order-id}}` for the order number. Each
contact's message is filled with the data of the event that started *their* run, so two
contacts who entered with different orders get their own order number.

> **Warning**: If the trigger event arrives without a parameter that a variable uses, the variable
> comes out empty and the message is still sent, with a gap where the data should be. To
> avoid it, give the variable a **Default value** in its options: it's used whenever the
> event parameter is empty.

### Preview and test

Each channel's preview tab shows the message on an Android or iOS phone, for the
country you select, with the estimated cost of one message. From there you can send
a test to yourself to check the text, the personalization and the links on a real
device. To try the whole flow with one contact — waits, branches and all — use a test
run instead (see [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing#test-with-one-contact)).

### When the step needs attention

A message needs a **sender and a text** on every channel it uses. While one is
missing, the card says **This message needs a sender and a text**, and saving from the
editor keeps your work but reminds you: **Saved. This message is still incomplete: it
needs a sender and a text.** The step is then marked **Needs attention** on the canvas
and listed under **Fix your flow to publish it**, with one line per incomplete
channel — an RCS step with an empty RCS card and an empty SMS fallback gets two. You
can save a draft like this, but you can't publish it until it's complete (see
[Building a flow](/platform/en/automations/flows/building-a-flow#fix-what-blocks-publishing)). An SMS fallback that
you've switched off doesn't need a text.

Inside **Edit message** there is **Save changes** but no discard button: to undo your
edits, go back to the flow builder and use **Discard** there.

## RCS with SMS fallback

An RCS message reaches the contact with your brand, but not every phone can receive RCS.
That's why a **Send RCS** step is created with an **SMS fallback** already switched on:
the automatic plan B, so the contacts RCS can't reach still get the message as an SMS.

In the editor, the RCS card and the SMS card are joined by the **If RCS is
undeliverable** connector, which has a switch. Leave it on to keep the fallback, or turn
it off if this message should only ever go out as RCS. The SMS card is labelled
**fallback** and has its own sender and text. Its text starts as a copy of the RCS text
and keeps following it until you edit it; from then on it's yours and later changes to
the RCS text don't overwrite it.

The fallback can come into play at two moments:

```mermaid
flowchart TD
    A["Contact reaches a Send RCS step"] --> Q1{"Can RCS be sent to this contact?"}
    Q1 -->|No| S1["The SMS fallback is sent instead"]
    Q1 -->|Yes| R["RCS is sent"]
    R --> Q2{"Is the RCS delivered?"}
    Q2 -->|Yes| OK["Delivered over RCS"]
    Q2 -->|No| S2["The SMS fallback is sent"]
    class OK success
```

- **At send time.** If RCS can't go out to this contact — their phone is known not to
  support RCS, or your RCS sender isn't available in their country — the SMS is sent
  in its place. Contacts whose phone hasn't yet shown whether it supports RCS are sent
  RCS first.
- **After sending.** If the RCS message is sent but isn't delivered, the SMS fallback
  is sent, the same way it works in campaigns.

The flow doesn't wait for either moment: the contact has already moved on to the next
step. If you need to know which channel the message finally used, a **Wait for
delivery** placed after the step decides on the message that actually went out and can
split by delivery channel (see [Waits](/platform/en/automations/flows/waits#wait-for-delivery)). On the
contact's journey, a message that fell back says it was sent on SMS because the
channels before it couldn't deliver.

The consent policy described below applies to the whole message: the RCS and its SMS
fallback follow the same policy, and RCS uses the contact's SMS consent (see
[Shared consent (RCS & SMS)](/platform/en/consent/rcs-sms-shared-consent)).
How fallback works as a channel feature is explained in
[SMS fallback](/platform/en/channels/rcs/sms-fallback).

## Who receives it: the consent policy

> **Warning**: By default, a flow message uses the **Basic** policy: it reaches every subscribed
> contact and ignores the marketing preference. A contact who said no to marketing but
> isn't suppressed on the channel **receives it**. If the message is marketing, change the
> policy or add a **Check consent** step before it, as explained below.

Every Send message step has its own **Consent policy**: the consent this message
requires. When a contact reaches the step, Instasent checks them against that policy at
that very moment; a contact who doesn't meet it isn't sent the message, and the flow
reacts as set in the step's other setting (see
[When a message can't be sent](#when-a-message-cant-be-sent)). The policy is in the
**Advanced** tab of **Edit message**, and offers three options, described in the panel
like this:

| Policy         | What the panel says                                             |
| -------------- | --------------------------------------------------------------- |
| **Basic**      | Sends to all subscribed contacts, ignores marketing preferences |
| **No opt-out** | Excludes contacts who explicitly declined marketing             |
| **Opt-in**     | Only contacts who explicitly accepted marketing                 |

Contacts **suppressed** on the channel — blocked from every send on it — aren't sent the
message under any of the three. A contact who declined marketing but isn't suppressed
still counts as subscribed, so a Basic message reaches them. Exactly which contacts
each policy reaches — including those with no marketing preference recorded — is
explained in
[Compliance policies](/platform/en/campaigns/compliance-policies); the same rules apply
to campaigns and flows.

![The Advanced tab of a message with the consent policy options](/platform/en/automations/flows/images/sending-messages--2-advanced-tab.png)
*Basic is selected unless your project sets another default.*

**Which policy a new message starts with.** A new step starts with your project's default
policy for that channel, if one is configured (see
[Compliance](/platform/en/channels/compliance-defaults)), and otherwise with
**Basic**. Out of the box no channel has a default set, so in most projects every new
message starts on Basic. Flow templates set the policy of each message they create,
so check it there too (see [Flow templates](/platform/en/automations/flows/templates)).

**Two ways to respect a contact's "no" to marketing:**

- **Change the policy of the message** to **No opt-out** or **Opt-in**. Contacts who
  don't meet it aren't sent this message.
- **Route them first with a Check consent step.** It splits contacts into **Has
  consent** and **No consent** using the same rules, so those who don't qualify can
  take a different path — a tag, a different message, or the end of the flow (see
  [Branches › By consent](/platform/en/automations/flows/branches#by-consent)). Check consent starts on
  **Opt-in**, while a message starts on Basic: the two settings are independent, and
  the message still applies its own policy.

Consent is always checked when the message is sent, whether or not there's a Check
consent step before it — but it's checked against **the message's** policy. A flow with
no Check consent step and messages left on Basic sends to contacts who declined
marketing.

Once a message has been sent, its policy is shown in the message's details: on the
contact's journey, **View message** opens them (see
[Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow#the-contact-journey)).

### If the contact opts out during the flow

Consent is checked again at every Send message step, so a contact who replies **STOP**
or uses an unsubscribe link while inside the flow is held to it for the messages that
come next. What the opt-out blocks depends on the policy of the message they opted out
from, under the same rules as campaigns (see
[Compliance policies › What happens when someone opts out](/platform/en/campaigns/compliance-policies#what-happens-when-someone-opts-out)):

- **From a Basic message**, the contact is suppressed on the channel: no later message
  of the flow is sent to them, whatever its policy.
- **From a No opt-out or Opt-in message**, the contact is recorded as declining
  marketing: later No opt-out and Opt-in messages aren't sent, but a later **Basic**
  message still reaches them.

A message that isn't sent for this reason follows the step's **Stop the run if the
message can't be sent** switch: on, the run ends there as **Stopped**; off, the contact
carries on without it (see [When a message can't be sent](#when-a-message-cant-be-sent)).
To end the run as soon as someone opts out, add **Customer unsubscribed** as an exit
event, without marking it as the goal (see
[Goals and exits › Exit events](/platform/en/automations/flows/goals-and-exits#exit-events)).

### Worked example: a spring offer

A store creates a flow called *Spring offer*: when a contact views a product (**Product
viewed**), it sends an SMS with a discount. Laura declined marketing SMS in her account
preferences, but never unsubscribed.

- **The SMS is left as it was created, on Basic.** Laura views a product and **receives
  the offer**. Nothing went wrong: Basic ignores the marketing preference.
- **The SMS is set to Opt-in.** Laura isn't sent the offer. With the default
  **Stop the run if the message can't be sent**, her run ends at that step with the
  status **Stopped**, and her journey shows that the message wasn't sent because she
  doesn't meet the channel's consent policy.
- **A Check consent step (Opt-in) goes before the SMS.** Laura goes down **No consent**,
  where an **Update tags** step adds the tag `no-marketing-consent`. She receives
  nothing, her run finishes normally, and contacts who accepted marketing go down
  **Has consent** to the offer.

#### Why did a contact who refused marketing get the message?

Because the message used the **Basic** policy, which is the default: it reaches every
subscribed contact and ignores the marketing preference. Open the contact's journey,
then **View message** to see the policy the message used. To stop it happening, set
the message to **No opt-out** or **Opt-in** in **Advanced**, or add a **Check
consent** step before it. Contacts already inside the flow keep the version they
entered with; the change applies once you publish it.

## When a message can't be sent

Sometimes a message can't go out to a contact in any way: they don't meet the consent
policy, no channel can reach them (for example, they have no mobile number), the
sender isn't available for their country, or the message isn't fully set up. What
happens next depends on the switch **Stop the run if the message can't be sent**, in
the **Advanced** tab:

- **On (the default).** The contact's run stops at this step, with the status
  **Stopped**. They receive nothing else from this run of the flow.
- **Off.** The contact carries on to the next step without the message, and the step
  records why it wasn't sent.

Either way, the contact's journey shows the reason the message wasn't sent; the full
list of reasons is in [Monitoring a flow › Why a message wasn't sent](/platform/en/automations/flows/monitoring-a-flow#why-a-message-wasnt-sent).

Turn the switch off when the rest of the flow still makes sense without the message —
for example, a final **Update tags** step that should run for everyone. With it off, a
**Wait for delivery** placed after the message can also send contacts who couldn't be
sent the message down their own path, through its optional **Unable to send** output
(see [Waits › Wait for delivery](/platform/en/automations/flows/waits#wait-for-delivery)). If what you want is to separate
contacts a channel can't reach *before* trying, a **Check reachability** step routes
them by whether SMS or RCS can reach them (see
[Branches › By channel reachability](/platform/en/automations/flows/branches#by-channel-reachability)).

## Sending time

A Send message step has no sending window or quiet hours of its own and sends as soon as
the contact reaches it, at any hour; to send only at suitable times, put a **Timezone
delay** or a **Smart delay** right before it (see
[Waits › There are no quiet hours on messages](/platform/en/automations/flows/waits#there-are-no-quiet-hours-on-messages)).

## What gets billed

Each message a flow sends is charged like any other SMS or RCS message, at your account's
price for that channel and destination; the preview shows the estimated cost per
message. The flow itself, its waits, branches, contact updates and goals add no charge.
When an RCS message falls back to SMS, the RCS attempt is not charged and the SMS is
billed under SMS conditions; see [SMS fallback › What gets billed](/platform/en/channels/rcs/sms-fallback#what-gets-billed).
Messages are paid from your balance (see [Balance](/platform/en/billing/wallet-balance)).

## Related

- [Waits](/platform/en/automations/flows/waits) - React to delivery, clicks and replies, and send at the right time.
- [Branches](/platform/en/automations/flows/branches) - Check consent and reachability before sending.
- [Compliance policies](/platform/en/campaigns/compliance-policies) - Who each consent policy reaches.
- [Consent & subscriptions](/platform/en/consent) - Marketing preference, opt-outs and suppression.

---

This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.