Campaign Send

Bulk Send in the last lesson took a list and a body and mailed it. That is enough for a digest and not enough for marketing, because marketing has obligations. Someone unsubscribed last month. Someone's address bounced twice. Someone is in two of the four segments you picked and should not get it twice.

Campaigns in Expedify are three nodes rather than one, and the split is exactly those obligations. One builds the audience and applies the rules. One picks the message. One sends and records what happened. Chain them and the compliance is structural rather than something you remembered.

The exclusions default to on, and that is the point of the node. Unsubscribed and bounced contacts are removed before anything downstream sees them, so no part of your workflow has to know about consent. It also deduplicates across the segments you named — a contact in three of them is one recipient.

Sampling is for testing, and it is the one setting to touch carefully. max_audience_size caps the list and sampling_method decides which ones survive the cap. Set the cap to 50 while you are building and your campaign goes to fifty people instead of five thousand — which is how you want to discover a broken merge field. Just remember to raise it.

Two _source fields decide where the node looks. template_source is manual when you picked a template in the panel and input when an upstream node chose it. contact_source is input when the audience node built the list — which is the normal shape and the default.

Personalisation is not a node. There is no Campaign Personalization step, and people look for one because the video for the old version implied it. The merge fields live in the template and are mapped in this node. If a name is not appearing, the mapping is here.

A re-engagement campaign, monthly. The segment is named once, the compliance filtering is the audience node's default behaviour, and the template is chosen by a node rather than pasted into the send.

Read the two variables and the chain explains itself. {{audiencesegmentation_1.contacts}} is the filtered list — not the segment, the survivors of it. {{templateselection_1.template.id}} is the chosen template. Neither node knows anything about the other; the send is what joins them.

Putting the template behind its own node looks like ceremony for one field, and it is — until the choice becomes conditional. A Condition ahead of two Template Selections, both feeding one send, gives you a campaign that says different things to different halves of the audience with no duplicated send configuration.

The question that settles it: if this message goes to someone who unsubscribed, is that a problem? If yes, you want the campaign nodes, and you want them even for a small list.

A campaign that sends nothing used to report success. When no template resolved, each recipient was skipped in a way that recorded nothing at all — and the summary computed failures as “results minus successes”, which on an empty list is zero. So the run was green, the node was green, and not one message existed. This is fixed: a send that reaches nobody now fails and leaves down the error path. Zero recipients is still a success, because there was nothing to do.

A contact id is not a contact. Pointing contact_input_variable at something like {{trigger_1.new_data.id}} is the natural way to mail whoever fired a trigger, and it used to file the raw UUID as the email address — which the provider then refused. It is now recognised and resolved. Prefer handing this field the audience node's contacts array anyway; it is the shape everything downstream expects.

WhatsApp campaigns need four ids, not one. The warning above is the node's own. It is not a bug — a WhatsApp template send has to be attributed to a campaign and a segment on the provider's side as well as yours — but it does mean a WhatsApp campaign cannot be assembled the same way an email one can. Build the email path first.