# Action Steps The building blocks of an automation: emails, waits, conditions and the actions that change a contact. Steps are the individual things an automation does. Once a trigger enrols a contact, they move from step to step at their own pace, following whichever path the flow sends them down. Each step is configured on its own. Changing a step's settings while the automation is active affects every contact who reaches it from then on. ## Available step types ### Send Email Sends an email when the contact reaches this step. Either pick a saved [template](https://sendbeam.io/docs/templates), or write the step's own subject, HTML body and optional plain-text fallback. Merge tags are filled in with the contact's data at the moment of sending. - Sent from the workspace's sender name and address (Settings → Email & Domains). - Open and click tracking, the unsubscribe link and the one-click unsubscribe header all work the same as for campaigns. - Each email counts towards the account's monthly allowance. If the allowance runs out the send fails, is logged, and the contact moves on. - Only subscribed contacts reach it: anyone who unsubscribed, bounced or complained since enrolment leaves before any step runs. > A template referenced by a step is live: edit the template and every email sent from that step afterwards changes with it. > Tick **Test a second subject line** to give the step a Subject B. Half of the contacts reaching the step get each subject (the same body either way), and the automation's page shows sent, opened and clicked per subject. See [Testing a sequence](#testing-a-sequence). ### Wait Holds the contact before the next step. Four ways to say when: - **Wait for a length of time** — minutes, hours or days, counted from when the contact reaches the step. - **Wait until a time of day** — the next time it is, say, 09:00. Tick *Send at the time each contact originally signed up* to use each contact's own signup hour instead. - **Wait until a day of the week** — pick one or more days, so a sequence only ever lands on weekdays. - **Wait until a day of the month** — the 1st, the 15th. A month too short for the day you chose uses its last day, so the 31st still fires in February. The last three take a timezone, so "09:00" means 09:00 where your audience is. Waits are honoured by a scheduler that runs about once a minute, so a wait may end up to a minute late — that is the one place an automation is not instant. ### Condition Splits the flow in two. Contacts who match go down the **Yes** path, contacts who do not go down the **No** path. Either path may be left empty, which simply ends the run for the contacts who take it. A condition holds a group of rules combined with **all**, **any** or **none**. Each rule tests either: - **A contact field** — status, first name, last name, email, source, or any custom field by name. - **Email activity** — whether the contact opened or clicked the email sent by an *earlier* step in this same automation. Only emails the contact has actually passed are offered. Field operators: equals, does not equal, contains, does not contain, starts with, ends with, is greater than, is less than, is empty, is not empty. Greater and less than compare numerically when both sides are numbers. ### Split Sends a share of the contacts reaching it down branch **A** and the rest down branch **B** — a 50/50 by default, or any whole-number split you set. Each contact is placed once, the moment they reach the step, and stays on that branch for the rest of their run; a contact who is enrolled again later is placed afresh. Either branch may be left empty, which ends the run for the contacts who take it. Set A to 100% to send everyone down the branch that did better. The numbers are on the automation's page. ### Add Tag / Remove Tag Applies or removes a tag. Useful for marking progress — tagging someone `onboarded` once they finish a sequence. - If the change would be a no-op — adding a tag they already have — the step completes silently. - Adding or removing a tag can start another automation using the matching tag trigger. ### Set Field Writes a value onto the contact. First name, last name, source and language write to the contact itself; any other name becomes a custom field you can merge into a later email or test in a condition. Language takes a code from the list (`fr`, `de`); a value that is not a language clears it rather than stopping the flow, so a form answer can set it safely. Choose **Increase by** instead of **Set** to add a number to the field's current value rather than replacing it — a running counter such as a visit count or a loyalty total. Increase by only works on a Number custom field (an undeclared key is created as a Number field the first time you use it this way, never as Text), and the amount may be negative to count down. This is what powers `lifetime_value` on [Order placed](https://sendbeam.io/docs/automations/triggers#available-trigger-types) — build your own counters with this step the same way. ### Unsubscribe Takes the contact off one list, or unsubscribes them entirely. Use it to close out a re-engagement sequence for people who never came back. > Unsubscribing from everything stops all future email to that contact and cannot be undone from inside the automation. Leaving a single list is the softer option. > ### Start Automation Hands the contact to another automation, which is how a long sequence is split into shorter ones. The automation being started must carry the **Started by another automation** trigger, and an automation cannot start itself. ### Call Webhook Tells your own systems that a contact has reached this point in the automation, so a CRM can be updated, a task raised, or an order checked without anybody watching the flow. The step carries no address of its own. It sends the `automation.step_reached` event, and the webhook endpoints you have already set up under **Settings → Webhooks** deliver it — signed, retried on failure, and scoped to particular automations if you want only some of them. That means one endpoint serves every automation you build, and a URL that changes is changed in one place. Give the step a **label** — `notify-crm`, say. It arrives as `step.label`, and it is what the receiving system should branch on: an automation's name changes when somebody renames it, and a step's id changes when the automation is rebuilt. > An endpoint has to subscribe to `automation.step_reached` before this step does anything. The step tells you whether one does, and links to the form with the event already chosen; activation warns you as well. > ## How a contact moves through A contact advances one step at a time along whichever path the flow gives them. Emails, tags, field writes and unsubscribes all complete within the same processing pass; a wait holds the contact until its time is up. Every contact's position is tracked independently and by *step*, not by position in a list — so editing an automation, reordering it or inserting a step never moves a contact who is already part-way through onto something they were not meant to receive. > You can see exactly where each contact is in the automation's **Enrolled Contacts** table — their status, the step they are on, and when their next action is due. > ## Branching with conditions Drop a **Condition** onto the canvas and it grows two connectors, one marked Yes and one marked No. Add steps to either. A branch left empty ends the run for the contacts who reach it — they finish the automation rather than being ejected from it. Because a condition can test email activity, the common shape is: send an email, wait a few days, then branch on whether they opened it — one path nudges, the other congratulates. ## Bringing branches back together Two branches can end at the same step. Point both at it and the flow draws them converging — everything after that point is shared, so a common ending does not have to be built twice. An automation can never loop back on itself. If an edit would send a contact round in a circle the automation refuses to save, because a loop in a sending engine means someone emailed forever. ## Testing a sequence There are two ways to test inside an automation. A **Split** step tests two different paths — a shorter sequence against a longer one, a discount against none. A **second subject line** on a Send Email step tests only the subject, with the same email behind both. The automation's page shows a table per test: for a split, how many contacts entered each branch and what the emails on that branch (and only that branch — steps after the two rejoin count for neither) sent, opened, clicked and, where a store is connected, earned; for a subject test, sent, opened and clicked per subject. The figures cover sends since the test was added, within the send history SendBeam keeps. Once both sides have enough sends, the one ahead on click rate (for a split) or open rate (for a subject) is marked **Ahead**. Nothing is promoted for you. A campaign test can pick a winner because the rest of the audience is waiting to be sent to; an automation has no such moment — contacts arrive one at a time, for as long as it runs. When you have seen enough, set the split to 100% for the better branch, or keep the better subject and untick the test. The report stays for the steps as they are now: if you delete or replace a branch's steps, their history goes with them. --- Source: https://sendbeam.io/docs/automations/steps