Send a WhatsApp template from a rule

Most of what an automation rule 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.

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.
It is not a way around consent. Someone who replied STOP is still not messaged. See 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 and plans, limits and what they stop.
At least one approved template synced on that channel. See WhatsApp templates.

Configuring the action

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

Inbox. Only this account's WhatsApp channels are listed. Pick the number the message will come from.
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.
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 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
`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 is the full picture, and 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 — 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 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.

A worked example

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

Settings → Automation → Create automation. Name it Shipped notice.
Event: order shipped.
Condition: store — is — your store.
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}}.
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.

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.

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.

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.