Most of what an [automation rule](automation-rules) does is for your team: a label, an assignment, a private note.
**Send WhatsApp template** is the one action that writes to the customer, and it exists for one reason — an
approved template is the only thing WhatsApp allows once the 24-hour window has closed. See
[the WhatsApp 24-hour window](the-whatsapp-24-hour-window).

## What it is not

- **It is not a free-form message.** There is no fallback to typed text. If the template cannot be sent, nothing is
  sent — which is the point, because a plain message outside the window is exactly what WhatsApp forbids.
- **It is not a campaign.** It sends one template into one conversation each time the rule fires. For a list of
  people, use [WhatsApp campaigns](whatsapp-campaigns).
- **It is not a way around consent.** Someone who replied **STOP** is still not messaged. See
  [messaging consent](messaging-consent).

## What you need first

- An **administrator** account, because rules are administrator-only.
- **At least one WhatsApp channel on the account.** With none, the action is not offered in the rule editor at
  all — the inbox list would be empty, and a rule that cannot be configured is a rule that silently does nothing.
  See [connect a WhatsApp number](connect-whatsapp) and
  [plans, limits and what they stop](plans-limits-and-what-they-stop).
- **At least one approved template synced on that channel.** See [WhatsApp templates](whatsapp-templates).

## Configuring the action

**Settings → Automation**, open or create the rule, and add **Send WhatsApp template** under Actions.

1. **Inbox.** Only this account's WhatsApp channels are listed. Pick the number the message will come from.
2. **Template.** Only templates synced on *that* channel are offered, and only the ones that can actually be sent:
   approved, not an authentication template, not a satisfaction-survey template, and without a list, product,
   catalogue or call-permission component or a location header. **The language is part of the template**, not a
   separate field — the same name in two languages is two entries in the list, because the send is matched on name
   and language together.
3. **Values.** One field appears for each slot the template declares: its body variables, a text header's
   variables, a media header's file URL (and a file name for a document), and the parameter for each URL or
   copy-code button. Every one of them must have a value.

A value can be literal text, or it can carry a token that is filled in when the rule fires:

| Token | What it becomes |
|---|---|
| `{{contact.name}}` | the contact's name on the conversation |
| `{{cart.total}}` | the abandoned cart's total |
| `{{cart.currency}}` | the abandoned cart's currency |
| `{{cart.item_count}}` | how many items the abandoned cart holds |
| `{{cart.recovery_url}}` | a checkout link for that cart, read from the store at send time |

**The four `cart` tokens only have a value on the Cart abandoned trigger, and that trigger cannot fire in this
build.** In practice `{{contact.name}}` is the token to use. [Recovering an abandoned cart](abandoned-cart-recovery)
explains why the cart trigger is offered but never runs.

Any other token, and any token that comes back empty at send time, **refuses the whole send** rather than
delivering a half-filled template.

## Which rules can use it

Every trigger offers it — conversation events, message created, and the Commerce order triggers. On a
**Commerce trigger it is the only customer-facing action there is**: send a message and send an attachment are
deliberately withheld there, because a store event is not a customer message and the conversation is very likely
outside the window.

**An active rule cannot be saved with the action half-filled.** The channel, the template name and the language are
all required while the rule is switched on. A switched-off rule saves without them, which is how a recipe can hand
you a rule with the action already in place and leave the choice of template to you — and why such a rule cannot be
switched on until you have made it.

## Every reason it refuses

The checks run in this order, and the first one that fails stops the send. Nothing further is tried.

| Reason | What happened | What to change |
|---|---|---|
| `inbox_not_in_account` | the channel the action names is not in this account any more — deleted, or the rule was copied from elsewhere | open the action and pick the channel again |
| `channel_not_whatsapp` | the channel named is not a WhatsApp channel. The editor cannot produce this; a rule written through the API can | pick a WhatsApp channel |
| `conversation_inbox_mismatch` | the conversation the rule fired on belongs to a **different channel** from the one the action names | add an **inbox** condition to the rule so it only fires on that channel, or add one action per channel |
| `contact_unavailable` | there is no contact, the contact is **blocked** in Lynomia Chat, or this conversation holds no WhatsApp address for them | unblock the contact, or accept that this conversation cannot be answered on WhatsApp |
| `template_not_found` | no template of that name is synced on that channel | re-sync the channel's templates, or pick one that is there |
| `template_language_unavailable` | the name exists on the channel, but not in the language the action asks for | pick the language that is actually approved |
| `template_not_approved` | the template is there but its status is not approved — in review, rejected, paused or disabled | see [the template lifecycle](whatsapp-template-lifecycle) |
| `template_not_allowed` | approved, but of a kind that cannot be sent this way: an authentication template, a satisfaction-survey template, or one carrying a list, product, catalogue or call-permission component or a location header | use a different template |
| `consent_withdrawn` | the person asked not to be messaged — usually by replying **STOP** | only they can undo it, by replying **START** |
| `messaging_suppressed` | the provider reports that the number cannot receive | fix the cause, then clear the suppression |
| `promotional_consent_missing` | this send counts as promotional and no grant exists for that person | see the table below |
| `template_param_missing` | a value was left empty, a token could not be resolved, or a copy-code value is longer than 15 characters | fill the value, or use a template with fewer slots |

## When a send counts as promotional

Two things decide it, and **both have a veto**: what Meta classified the template as, and what the trigger is
about. Only Meta's **UTILITY** category can be transactional.

| | A **UTILITY** template | Any other template |
|---|---|---|
| **An order trigger** | transactional — sends unless the person withdrew or is suppressed | **promotional — needs a grant** |
| **Any other trigger** | only a withdrawal or a suppression stops it | **promotional — needs a grant** |
| **The cart trigger** | **promotional — needs a grant** | **promotional — needs a grant** |

**Recording a promotional grant needs Commerce on your plan.** Without it there is nowhere to record one, so a
MARKETING template fired from a rule will be refused every time, for everybody. If your plan has no Commerce,
treat this action as UTILITY-templates-only. [Messaging consent](messaging-consent) is the full picture, and
[plans, limits and what they stop](plans-limits-and-what-they-stop) covers what your plan includes.

## How you tell whether it sent

**When it sends**, an outgoing message appears in the conversation carrying the template's body text, attributed to
the rule rather than to a person. That message is your receipt.

**When it refuses, there is nothing to see.** No message, no failed message, no private note, and no entry in
[automation and flow analytics](automation-and-flow-analytics) — a refused template is not a "skipped" rule; as far
as the rule is concerned it ran. The reason is written to the server log only, as
`[AUTOMATION TEMPLATE] event=refused` with the rule, the conversation and one of the codes above. If you cannot
work out which refusal you are hitting, [raise a ticket](contact-lynomia-support) naming the rule and a
conversation where you expected a message.

A template that *was* accepted can still fail at WhatsApp afterwards — that one **does** show in the conversation,
marked as failed with Meta's own reason. See
[finding the conversations where a message failed](whatsapp-find-a-failed-message).

## A worked example

An order is marked shipped, and you want the customer told even though they last wrote to you three days ago.

1. **Settings → Automation → Create automation.** Name it *Shipped notice*.
2. Event: **order shipped**.
3. Condition: *store — is — your store*.
4. Action: **Send WhatsApp template**. Inbox: your WhatsApp number. Template: your approved
   `order_shipped` template, in the customer's language. Value for the body variable: `{{contact.name}}`.
5. Save and switch the rule on.

If the customer's most recent conversation is on the website widget rather than on WhatsApp, this rule will refuse
with `conversation_inbox_mismatch` — a Commerce rule acts on the contact's most recent conversation, whichever
channel that is on.

## Who can do this

**Administrators.** Automation is not one of the permissions a custom role can hold, so a custom role cannot reach
this action at all. See [roles and permissions](roles-and-permissions).

## Limits

- **One template per action.** Two templates means adding the action twice.
- **The language is fixed in the action.** Nothing chooses a template language per contact; a second language
  means a second rule with a condition on the contact's language.
- **A Commerce rule never waits.** You cannot delay this action behind an order trigger.
- **The message this action sends does not trigger other rules**, so it cannot start a loop and cannot be chained.
- **A media header's URL is used as you give it.** Lynomia Chat does not host the file for you.
- **It does not open the 24-hour window.** A template is what you may send when the window is shut; only the
  customer's own reply opens it again.

## Related

- [Automation rules](automation-rules)
- [WhatsApp templates](whatsapp-templates)
- [The WhatsApp 24-hour window](the-whatsapp-24-hour-window)
- [Messaging consent](messaging-consent)
- [The template lifecycle](whatsapp-template-lifecycle)
- [Plans, limits and what they stop](plans-limits-and-what-they-stop)

## If it does not work

**The action is not in the list of actions.** This account has no WhatsApp channel. Connect one, and it appears.

**The template dropdown is empty after I pick an inbox.** That channel has no template that can be sent this way —
none approved yet, or only authentication and survey templates. See [WhatsApp templates](whatsapp-templates).

**The rule will not switch on.** The action is incomplete: the channel, the template or the language is missing.
The form says which.

**It works for some customers and not others.** Almost always `conversation_inbox_mismatch` — those customers'
most recent conversation is on another channel. Add an inbox condition and watch what the rule stops matching.

**It worked when I tested it on my own number and not for real customers.** Consent. Your own number has no
withdrawal recorded against it; a customer who replied STOP, or who never granted promotional messaging for a
MARKETING template, is refused.

**Nothing is in the conversation at all.** Then it was refused rather than failed — a failed send leaves a message
behind, a refusal leaves nothing. Work down the refusal table above.