Sending messages

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).

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). 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.

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.

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.

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.

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).

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). 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:

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). 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)). How fallback works as a channel feature is explained in SMS fallback.

Who receives it: the consent policy

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). 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; the same rules apply to campaigns and flows.

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), 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).

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). 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).

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):

• 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). 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).

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.

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.

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). 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).

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).

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. Messages are paid from your balance (see Balance).

Related