Setup & Initial Configuration
Automations depends on more of the application than most addons — it needs a real queue and a running scheduler. Work through this page in order and it will run correctly the first time.
1. Install and activate the addon
Go to Setup → Add-ons, find Automations, and install or activate it. Once active, an Automations entry appears in the main menu.
2. Set the queue driver to Database
This step is not optional, and it is the single most common reason a new installation misbehaves.
Under Application Settings, set the Queue driver to Database, then make sure a queue worker is actually running on the server.
On the Sync driver the application has nowhere to park background work, so
contacts never advance through a workflow. Mumara blocks the configuration
outright — if you try to enable Automation Status while the queue driver is
still Sync, you'll see:
First, you need to set the queue driver from "Sync" to "Database" in the application settings.
Before 3.1, turning Automation Status on and saving silently discarded every
setting in that block on any installation whose queue driver was not database.
If you have hit that, update the addon — see the changelog.
3. Turn Automations on
Go to Application Settings → Triggers. The Automations settings live in their own block there.
| Setting | What it controls |
|---|---|
| Automation Status | The master switch. Off means no automation enrols or advances a contact. |
| Automatically resume system-paused Automations | When on, an automation that the system paused because its sending node failed is resumed automatically once that node is active again. |
| Automation waiting pool driver | How contacts waiting inside a Wait or Condition step are stored — Database or Write-File. |
| List selection type when creating an Automation | Whether an automation may target Single List or Multiple List. |
| Reset Automation Limit | What happens to automations paused by a limit when the monthly counter resets — Skip or Resume. |
Automatically resume system-paused Automations
Mumara pauses an automation by itself if the sending node it depends on stops working. That protects you from an automation quietly failing every send. With this setting on, the automation restarts as soon as the node is healthy again; with it off, someone has to resume it by hand.
Automation waiting pool driver
Database is the default and the right answer for almost every installation. Write-File stores the pool on disk instead, for specialised setups. If you have no specific reason to change this, leave it on Database.
List selection type
Single List restricts an automation to one contact list. Multiple List allows several. This is a global policy, so choose it before your users start building — an automation already built against several lists is affected if you later restrict the setting.
Reset Automation Limit
When a user hits their monthly actions limit, their automations stop. When the monthly counter resets, this decides what happens next:
- Skip — the automation stays paused and someone has to resume it.
- Resume — the automation restarts automatically.
The same setting exists per user, on the user's profile under the Automation tab, and the per-user value governs that user.
4. Make sure the scheduler is running
Automations ships three scheduled jobs, registered automatically by the addon. They only run if your Mumara cron entry is installed and firing.
| Job | Schedule | What it does |
|---|---|---|
automation:waiting_pool | Every n minutes (configurable) | Releases contacts whose Wait or Condition has elapsed. The heart of the addon. |
automation:resume_triggers | Daily at 00:05 | Resumes triggers left pending. |
automation:check_specific_time_email | Daily at 00:07 | Handles emails set to send at a specific time of day. |
If the waiting pool job isn't running, contacts enrol and then sit there forever. Any automation containing a Wait or a Condition will appear frozen. This is the second most common cause of "my automation isn't working".
Changing how often the pool runs
The waiting pool interval is set under Cron Settings as
automation_waitingpool, in minutes. It defaults to 1 minute, which suits
most installs.
- A value of 60 or less runs every n minutes.
- A value above 60 is converted to whole hours.
- A value of zero or a non-numeric value disables the job entirely.
You can also trigger the job from the Cron Settings screen with Run Now, or Force Run to run it even if a previous run is still flagged as active — useful when a stuck run is blocking the queue.
5. Set limits (multi-user installations)
If you resell Mumara, three limits are configurable per package.
| Limit | Meaning |
|---|---|
| Automation Limit | How many automations a user may create in total. |
| Monthly Actions Limit | How many automation actions the user may consume per month. |
| Maximum Actions in a single Automation | How many nodes one automation may contain. Defaults to 30. |
Enter -1 for unlimited on the first two.
Users who hit a limit see a warning on the Automations page — "You have already used N actions this month" — and further actions are refused with "You've reached the maximum number of actions allowed in this automation."
The monthly counter is per user and resets on its own cycle; what happens to paused automations at that moment is governed by Reset Automation Limit above.
6. Prepare a sending node
Any automation that sends email needs an active sending node, configured under Sending → Nodes. Set this up before building, because the Send an Email action asks you to pick one.
If the node later fails, Mumara pauses the automation and records the reason on the Issues page — the automation list will show "Your SMTP failed. For more details visit the Issues page."
Verifying your setup
Before building anything real, confirm all four:
- Setup → Add-ons shows Automations as active.
- Application Settings shows the queue driver as Database, with a worker running.
- Application Settings → Triggers shows Automation Status on, and the block still shows your values after a save and a page reload.
- Cron Settings shows
automation_waitingpoolwith a sensible interval and a recent run time.
A quick end-to-end test: build a two-step automation (send an email, wait one minute, send another), enrol a test contact, and confirm the second email arrives about a minute later. If the first arrives and the second never does, your scheduler is the problem.
Next steps
- Triggers — choose the event that starts your automation.
- Building Automations — the canvas and its rules.
- Troubleshooting — when something isn't firing.