Automations in Mumble: The Rules Engine That Handles the Work for You

TL;DR

Automations are a rules engine that runs actions automatically when events occur in your account. Instead of having to remember to close a conversation after two hours, label a customer who completed a process, or notify an external system when a conversation closes, an automation does it in the background. The structure is simple: When (trigger) → If (conditions) → Then (actions). This article covers the available triggers, how to build a focused automation, and the difference between automations and the chatbot, Dolores AI, or drip campaigns. If you manage conversations at volume, this is the tool that gives you back hours every day.

How automations differ from other tools

Mumble has several features that do things automatically, and customers tend to confuse them. Here is a quick breakdown:

Two important things set automations apart from other features:

• They run in the background, invisible to the customer. Unlike the chatbot, which talks to the customer, an automation only performs actions. The customer sees only the result (for example, a message template that was sent).
• They fire once per event. Unlike a drip campaign, which runs a sequence over time, an automation performs a single action the moment the event occurs.

Where to set up automations

The main Mumble menu has a section called Automations. The page shows a list of every automation in the account, with these columns:

• Name. An internal name you give the automation.
• Active. A toggle to enable it or pause it temporarily without deleting.
• Max actions per day. A daily cap on runs — a safety mechanism against loops.
• Created on. When the automation was created.
• Actions. A delete icon.

Clicking an automation’s name opens the form with its current values, where you can edit and save. The purple + button in the corner opens a new creation form.

The three parts of an automation

Every automation is built from three parts, in this order:

1. When it happens (the trigger)

The trigger is the event that fires the automation. You can choose only one. The available triggers are:

• Conversation status changed. Any transition between statuses fires the trigger. You can filter in the conditions by the original status or the new status.
• Added to a list. A customer was attached to a particular list.
• Removed from a list. A customer was removed from a list.
• Self-assignment. An agent manually took a conversation.
• Agent / team. An event at the agent or team level (for example, assignment).
• Inactive conversation. A conversation has not received a message from the customer for a defined period. Especially useful for auto-closing abandoned conversations.

2. Only if the conditions are met (the conditions)

Conditions narrow the trigger. Without conditions, the automation runs on every event of that type in the account. With conditions, it runs only on events that pass the filter.

Each condition is built from three parts:

1. Where. The field you want to check. This depends on the trigger (for example, with the “Conversation status changed” trigger you can check the from-status or the to-status).
2. Equals. The comparison operator.
3. Value. The specific value to compare against.

Example: the “Conversation status changed” trigger plus the condition “Where: from-status, equals: New” makes the automation run only when a conversation in the “New” state moves to another state, not when other conversations change status.

You can add several conditions. They must all be met together (AND logic) for the automation to run.

3. Do these actions (the actions)

The actions are what happens when the trigger fires and the conditions are met. You can choose several actions to run together. The available actions are:

The Send a webhook action opens up deep integration possibilities. We recommend reading the dedicated section on it below.

Examples of automations that work

Example 1: Auto-closing abandoned conversations

• Trigger: Inactive conversation (90 minutes)
• Conditions: Status = In progress
• Actions: Send a message template (“Still need help?”) + change status to Closed
• Max per day: 500

The use case: preventing conversations from staying open forever. The customer gets a last chance to come back, and if they don’t, the conversation closes on its own.

Example 2: Auto-routing hot leads

• Trigger: Added to a list
• Conditions: List = “Hot lead”
• Actions: Assign to team = Sales team
• Max per day: 100

The use case: every customer marked as a hot lead (manually or via the chatbot) is automatically routed to the sales team. No need to remember to do it.

Example 3: Syncing conversation closure to an external system

• Trigger: Conversation status changed
• Conditions: To-status = Closed
• Actions: Send a webhook to https://yourcrm.com/conversation-closed with the conversation details

The use case: every time a conversation closes in Mumble, your external system (CRM, BI, customer management system) gets notified and can update its own record.

Example 4: Automatic onboarding on first handling

• Trigger: Conversation status changed
• Conditions: From-status = New, To-status = In progress
• Actions: Add to list = “Active customers” + assign to bot = Onboarding bot

The use case: the moment an agent takes a new conversation into handling for the first time, the customer is labeled as active and the onboarding bot starts running in the background.

The webhook action in depth

Automations are the primary way in Mumble to connect events to external systems. When you choose Send a webhook as an action, two fields open for editing.

The webhook URL

A single URL field. This is the endpoint Mumble will send the POST request to when the automation runs. The placeholder is https://example.com/webhook, and you fill in the address of the receiving system.

The webhook data (payload)

Very important: you define the payload structure yourself. Mumble does not impose a fixed JSON schema. You build the key/value pairs according to what the receiving system expects.

Each row includes:

• Key. The JSON key name, free text (for example phone, customer_email, conversation_status).
• Value. The value, which can be one of two things:
  • Free text. Sent as-is for every event.
  • A system variable. Selected from the variables menu (the three-bars icon). The variable is resolved at run time based on the actual customer (their name, number, conversation status).

This means that for each automation you build a payload tailored exactly to the receiving system’s requirements. If the system expects { "phone": "...", "event": "conversation_closed", "label": "..." }, you build exactly that. This flexibility is an advantage, but it also means each automation requires its own configuration.

If you need more complex connections (for example, two-way sync or advanced authentication), it’s worth also looking at Connecting Mumble to Make.

Max actions per day

This is an important field that customers tend to overlook. It sets how many times per day this automation is allowed to run. The value is 0–100 on standard accounts.

Why it exists: to prevent loops and bugs. If you build an automation that changes a status and that causes another automation to run, you can easily create a situation where every customer triggers dozens of runs. The daily cap protects against this.

How to choose a value:

• For an automation tied to a rare event (hot leads created at a rate of a few per day), a cap of 50–100 is safe.
• For an automation tied to a frequent event (every status change, every incoming message), consider a cap of 100 and check whether that’s enough.
• For an automation with a critical webhook that must not be missed, set a high cap (100) and watch that it isn’t filling up.

If the automation reaches its daily maximum, additional events are not processed. There is no error message — just inaction.

Plans and monthly limits

Overage: $0.0039 per additional run.

Important to understand: the numbers are runs, not the number of automations. One automation that runs 50 times a day = 1,500 runs per month. The Standard plan’s cap of 250 runs per month is enough for small businesses with simple processes, not for active accounts. The Pro plan suits most.

Best practices

• Give automations clear names. “Automation 1” will confuse you in two months. A name like “Auto-close after 90 minutes” says it all.
• Start with a low daily cap and raise it as needed. A new automation with a cap of 10 per day lets you see how it behaves before it handles the entire account.
• Don’t try to build everything in one automation. One automation per goal. When you have 5 actions across 3 conditions, it’s easy to make a logical mistake. Two simple automations are better than one complex one.
• Test the trigger before adding actions. Create an automation with just one action (for example, adding to a list), see whether it runs in the right situations, and only then add more actions.
• Use webhooks for syncing, not for essential actions. A webhook may fail if the receiving system is unavailable. If an action must happen (for example, charging a customer), don’t rely on the webhook alone. Combine it with a retry mechanism or periodic check.
• Remember that automations don’t work retroactively. An automation you create today runs only on new events, not on historical ones. See the next section.

Behaviors worth knowing

Automations don’t run on historical data

This is important. An automation runs only on events that occur after it was created. If you created an automation with the trigger “Added to list X,” it will not run on customers who were already in list X before the automation was created — only on new additions.

The workaround: if you want to run an action on existing customers, you can do it manually once, and then enable the automation going forward.

There is no run log

There is no log showing which automations ran, when, and on which customers. If you’re checking “did this automation run yesterday?”, you have to check the results (was the message sent? did the webhook reach your system?). This makes debugging harder.

Temporary pause without deleting

If you want to stop an automation temporarily (for example, during a campaign that conflicts with it), use the Active toggle instead of deleting. The toggle makes the automation inactive but keeps its settings. When you’re done, you re-enable it.

Common issues

I created an automation but it doesn’t run

Check in this order:

1. Is the Active toggle on?
2. Is the trigger actually occurring? For example, if the trigger is “Added to list X,” are customers actually being added to the list?
3. Are the conditions correct? Sometimes a condition looks right but is interpreted differently than you intended.
4. Have you hit the daily maximum?
5. Is the account within its monthly run quota?

If everything checks out, contact Mumble support with the automation’s name.

The automation ran but the action didn’t happen

For example: a message template was sent but didn’t arrive. The reasons:

• The 24-hour window is closed and the attempt was to send a free-form text message.
• The message template is Paused or Rejected by Meta.
• The customer is blacklisted (opt-in revoked).
• You’ve hit Meta’s daily limit (see Messaging limits in Meta’s tier system).

The webhook isn’t reaching my system

Check:

• Is the URL on https (not http) and valid?
• Does the receiving system actually expect a POST?
• Does the payload structure match what the system expects?
• Is there a firewall blocking Mumble’s IP address?

If everything checks out, ask your development team to print the incoming payload so you can see exactly what’s being sent.

The automation ran twice on the same conversation

It’s possible the trigger was actually fired twice. For example, if the status changed from X to Y and back to X and again to Y, the automation runs on each transition. Add more precise conditions (for example, only when the original status is New).

I hit the monthly maximum — what should I do?

• Upgrade to a higher plan (Pro = 25,000 runs).
• Pay the overage ($0.0039 per additional run).
• Reduce less essential automations until next month.

I want a delay between the trigger and the action

The “Inactive conversation” trigger is a built-in delay (a period of inactivity before the trigger fires). But there’s no general delay you can add to other triggers. If you need a sequence of “trigger → wait 24 hours → action,” you should use a drip campaign instead of an automation.

Related articles

• Building a chatbot in Mumble
• Chatbot triggers
• Dolores AI: the getting-started guide
• Working hours and out-of-office message
• Connecting Mumble to Make
• The Mumble API: the complete guide

Bottom line

Automations are a tool that gives time back to your team. An hour of building today saves hours of manual work in the months ahead. Success depends on three things: clear names, a sensible daily cap, and testing before a wide rollout. Start with one simple automation (auto-closing abandoned conversations is a great place to begin), confirm it works as expected, and then add more. After a few weeks you’ll find that a meaningful share of your team’s repetitive actions happen on their own.