Skip to main content

Automations Overview

Automations run multi-step email journeys for you. Rather than sending one message to a whole list at one moment, you draw a workflow, a trigger followed by a sequence of actions, and each contact travels through it on their own.

A welcome series, a birthday greeting, a re-engagement email that only goes to the people who didn't open, a hand-off that copies engaged contacts onto a "warm leads" list: these are all automations.

Go to Actions → Automations to see and build them.

How it works​

Every automation has two kinds of building block.

One trigger. The event that enrols a contact in the workflow, such as a contact being added to a list, a contact opening an email or a date arriving. An automation has exactly one trigger, and it sits at the top of the canvas.

Any number of actions. What happens to a contact once enrolled: send them an email, wait three days, copy them to another list, notify your team, or evaluate a condition and take one of two paths.

You assemble these on a visual canvas by clicking the + below the last step and choosing the next one. The result is a tree that reads from top to bottom.

Trigger: Contact is added to a list
    │
    └── Send an email  ("Welcome")
            │
            └── Condition: opened the previous email?  (within 3 days)
                    ├── Yes → Send an email ("Here's what's next")
                    └── No  → Send an email ("Did you miss this?")

Each contact moves at their own pace​

This is the most important idea in automations, and it's what separates them from a broadcast.

A contact who enrols on Monday and a contact who enrols on Friday are each at their own position in the workflow. When a Wait step says three days, it means three days from when that contact reached the step, not three days from when you built the automation, and not a calendar date shared by everyone.

Contacts sitting in a Wait, or waiting for a condition to be decided, are held until their time is up. Mumara ONE checks for them at regular intervals, so a step runs within a few minutes of its due time.

A contact is only in an automation once at a time. If the trigger fires again for a contact who is still partway through, it's ignored. Once they've finished the journey, a new event can enrol them again.

How it compares to the rest of Mumara ONE​

FeatureWhat it doesReach for it when
BroadcastOne message, sent once to a list or segment.You have something to say now, to everyone.
Drip campaignA fixed sequence of emails on a fixed schedule.The sequence is the same for everyone and never branches.
Evergreen campaignA campaign that repeats on a schedule.You want the same send to go out again and again.
TriggerOne event, one action, straight away or after a delay.A single reaction is enough, such as starting a drip when someone joins a list.
AutomationA branching, multi-step journey driven by an event and by behaviour.The journey has more than one step, needs to wait, or needs to react to what the contact did.

The clearest sign that you want an automation is branching: if you ever want to say "send this only to the people who didn't open", you need a condition, and conditions live in automations.

Concepts and vocabulary​

TermMeaning
AutomationOne complete workflow: a trigger plus its actions. Listed under Actions → Automations.
Trigger / EventThe single entry point that enrols a contact. The builder calls it the Automation Event.
ActionA step performed on an enrolled contact.
Step or nodeAny single block on the canvas, trigger or action.
End of a branchThe last step on a path. New steps are added there.
Action LabelThe name you give an email step, shown on the canvas and in statistics.
Running / PausedAn automation's status, set with its Status switch. Only a running automation enrols and moves contacts.

What you need before you start​

  • At least one contact list. See Contact Lists.
  • A verified sending domain for the From address of your emails. See Sending Domains.
  • A pool to send through. In Mumara ONE, the "sending node" you pick in an email step is one of your pools. See Dedicated Pools.
  • The emails themselves. You can reuse a broadcast or design a new one from inside the automation.

Mumara ONE runs everything else for you, including processing waits and sending.

Plan limits​

Automations are part of your Mumara ONE plan, and your plan sets three limits:

  • Automations: how many automations you can have. Deleting one frees its place.
  • Actions per month: how many actions your automations can take each month. The allowance resets on your renewal date.
  • Steps per automation: how many steps a single automation can contain.

Each email sent, each admin notification and each copy or move operation counts as one action. Waits and conditions don't count.

You can see your usage in two places:

  • On the Automations page, the Automations Limit and Action Limit buttons next to Add New show what you've used against what your plan allows. The ∞ sign means unlimited.
  • On the Automations tab of Plan & Usage, Active automations and Actions this month show the same figures as meters. See Plan & Usage.

When you reach the monthly action limit, your automations stop taking actions until the allowance resets. See Automations stop part-way through the month. To compare plans, see Mumara ONE pricing.

Where to find it​

  • Actions → Automations lists your automations and is where you build them. See Building Automations.
  • Statistics → Automations Stats shows how each automation performs, step by step. See Automations Stats.

Next steps​

Last updated on