Mumara Campaigns 7.0.3
Release Date: May 2026 Type: Patch Release Previous Version: 7.0.2
Version 7.0.3 is a focused patch release on top of 7.0.2. It dramatically speeds up campaign preparation for large multi-list sends, fixes a segment broadcast bug that was silently dropping a portion of intended recipients, repairs a long-standing issue with triggers that update custom fields, makes the "has been sent" status on contacts accurately reflect actual deliveries, replaces the browser's generic error screen with a clear in-app message when a recipient clicks a broken link, and adds helpful diagnostics when the database backup tool can't find its dependencies.
If you're already on 7.0.2, this update is straightforward — a short background migration runs automatically to install the new deduplication system, but there are no manual steps required.
Highlights
| Area | Summary |
|---|---|
| Campaign Preparation | Large multi-list sends prepare dramatically faster — a real-customer campaign that took ~12 hours now finishes in a fraction of the time |
| Segment Broadcasts | Fixed a bug that was silently dropping 25–50% of intended recipients from segment-based broadcasts |
| "Has Been Sent" Status | The contact-level flag now reflects actual deliveries instead of being flipped on for everyone the moment a campaign starts preparing |
| Triggers | Custom-field updates that previously did nothing on first-time matches now save reliably |
| Click Tracker | Recipients clicking a broken link now see a clear in-app message instead of the browser's generic error page |
| Database Backup | New diagnostic panel explains exactly why a backup can't start, and the backup engine recognizes MariaDB's export tool as an alternative |
| Schedule Page | "Skip duplicates" toggle renamed to "Double-check duplicates" and off by default — duplicates are now removed automatically |
Before You Update
7.0.3 is a patch release with no breaking changes, no API contract changes, and no manual steps. A short database migration runs automatically in the background as part of the update to install a new deduplication system for the schedule log.
How to Update
Navigate to Tools → Update in the admin panel, pick your update channel (Stable is recommended for production), and click Begin Update.
The update queues a one-time cleanup of any historical duplicate entries in the schedule log, then installs a new deduplication index, then drops the old non-unique index. The whole sequence runs in the background and is invisible to you — no downtime, no manual steps. Campaign preparation falls back to the previous behaviour automatically while the migration is still in flight, and switches over to the faster path as soon as it completes.
Take a quick database and files backup before updating. It costs nothing and gives you a clean rollback path if anything unexpected happens in your environment.
Server requirements are unchanged from 7.0.2 — PHP 8.4 (with 8.3 and 8.5 also supported).
Campaign Preparation — Dramatically Faster for Large Multi-List Sends
The biggest performance win in 7.0.3 is the campaign preparation pipeline — the step that runs after you click Schedule and before the first email actually leaves the server. On large multi-list campaigns this step was the slowest part of the entire sending flow.
The problem
When a campaign targeted multiple overlapping lists, the preparation step had to deduplicate recipients twice: once at the source by grouping contacts by email address, and again by cross-checking every candidate against every other list. On a real-customer campaign of 1.7 million recipients across multiple lists, preparation was taking around 12 hours before a single email could be sent.
The fix
7.0.3 replaces the old "scan then insert" deduplication approach with a much faster automatic dedup at the moment of writing. The schedule log now has a built-in mechanism that silently rejects duplicates as they're inserted, so the slow scan-and-compare logic is no longer needed.
What you'll notice:
- Multi-list campaigns prepare in a fraction of the time they did in 7.0.2 — the 12-hour real-customer case mentioned above now completes far faster
- Campaigns that target a single list also prepare faster, since the source query no longer does a per-email grouping pass
- The end result is identical — every unique email address still appears in the schedule exactly once, regardless of how many lists they sit in
This change is automatic. No configuration, no migration steps for you — the speedup applies as soon as the background migration finishes.
"Skip Duplicates" Renamed to "Double-Check Duplicates"
Because deduplication now happens automatically, the schedule-page toggle that previously read "Skip duplicates" has been renamed and rethought:
| Before (7.0.2) | After (7.0.3) |
|---|---|
| Skip duplicates — default ON | Double-check duplicates — default OFF |
| Did the deduplication work | Adds an extra safety scan on top of the automatic dedup |
| Always on, always slow | Only enable if you want belt-and-suspenders verification |
The new help text on the schedule page explains the trade-off. For everyday use, leave it off — the automatic system handles duplicates correctly and far more efficiently. If you have a specific reason to want a second-pass scan (for example, you're auditing a one-off import), turn it on; preparation will take longer but the result is identical.
Segment Broadcasts — Full Recipient Lists Restored
A bug in segment-based broadcast preparation was causing silent recipient loss — typically 25% to 50% of the segment's intended audience wasn't being scheduled at all. On a real customer's send, a segment that should have prepared 12,000 contacts only prepared about 6,670.
There was no warning, no error, no entry in the log — the segment counts on the dashboard simply came out lower than expected, and the missing contacts received nothing.
What was happening
The preparation step was iterating through the segment in batches while writing each batch to the schedule. Because each write was changing the answer to the same question being asked for the next batch, the iterator was skipping over rows that had shifted position underneath it.
What's fixed
7.0.3 changes the order of operations so the full list of matching contacts is captured up front, then batched into the schedule. The result is that every contact matched by the segment is now correctly scheduled — no silent losses, no batch-size sensitivity, and cross-segment deduplication still works correctly when you target multiple segments in the same campaign.
What you'll notice:
- Segment counts shown on the schedule confirmation match the counts that actually get prepared
- Triggers and automations that schedule against the same segment now reach every matching contact
- A brief log line is written per segment with the matched count, so you can verify on your end as well
If you've had segment broadcasts running in production and suspected the numbers were "off," this update resolves it.
"Has Been Sent" Status — Now Accurate Per Recipient
Mumara stores a "has been sent" flag on each contact that you can target in segments — for example, "send only to contacts I've never emailed" or "send to contacts I've already emailed at least once". In 7.0.2 and earlier, this flag wasn't behaving correctly.
What was wrong
The moment a campaign started preparing, this flag was flipped on for every contact in every target list — including:
- Hard-bounced contacts who would be excluded from the send
- Unsubscribed contacts who would never receive the email
- Suppressed contacts who were on the global suppression list
- Contacts who would later fail to send because of an SMTP error or rate limit
In other words, contacts were being marked "sent" who had never actually received a single email. That made segments built on this flag essentially useless.
What's fixed
7.0.3 flips the flag at the moment of successful delivery — once an email actually leaves Mumara through your SMTP, that specific contact's flag is updated. Contacts that bounce, are skipped, are suppressed, or hit a delivery error keep their previous flag value, because no email reached them.
Where this kicks in:
- Broadcasts — the main send loop flips the flag per successful delivery
- Triggers and drip groups — the same per-recipient flip applies
- MTA errors, rate-limit failures, suppression skips — the flag is not touched, because no email was sent
What you'll notice:
- Segments using "has been sent" or "never sent to" return accurate results from now on
- Existing contact records keep their stored value until the next send attempt, so segments built today will refine themselves naturally as new campaigns go out
- No bulk update runs at preparation time, which contributes to the broader preparation speedup mentioned above
Triggers — Custom Field Updates Always Save
A long-standing issue with triggers that update a custom field on a contact has been fixed.
What was wrong
If a trigger action was set to update a custom field — for example, "set engaged = clicked when subscriber clicks any link" — and the contact didn't already have a value stored for that custom field, the update did nothing. There was no error, no log entry, and the trigger's run history showed it as having executed successfully. But the value was never actually saved.
This caused subtle problems for anyone using triggers to populate custom fields:
- Engagement scoring triggers reported running daily but had no effect on the underlying field
- Triggers used to populate workflow status fields silently failed for first-time matches
- Segments built on those fields stayed empty, even though the source trigger appeared healthy
What's fixed
7.0.3 changes the underlying logic so the field value is written regardless of whether a previous value existed. The first time a trigger updates a custom field on a contact, the value is created; subsequent updates overwrite it. Triggers that have been silently failing for months will start working immediately after the update — no need to rebuild or re-save them.
Broken Links — A Friendly Message Instead of a Browser Error
When a recipient clicks a link in an email, the click first lands on Mumara's click tracker (so the click can be logged), and then redirects to the actual destination URL. If the destination URL is broken — for example, when a merge tag inside a link resolves to empty because the recipient's data was missing — the tracker would 302-redirect to an incomplete URL like https:// with no domain.
The result was the browser's generic error page ("This page isn't working — server sent an invalid response"), which gave the recipient zero context about what went wrong and gave you no easy way to diagnose it.
What's fixed
The click tracker now validates the destination URL before redirecting. If the destination is missing, incomplete, or otherwise unusable:
- The recipient sees a clear in-app message: "This link is no longer valid"
- The click is logged with full context — campaign, schedule, contact, broadcast — so you can identify exactly which recipient's data is responsible and follow up
- Other links in the same email continue to work normally
What you'll notice:
- Recipients of campaigns that use merge tags inside link hrefs no longer see the browser's confusing native error page
- A warning entry appears in your Mumara log file (search for
invalid destination url) every time a broken link is clicked, including all the IDs you need to track it back to the contact and merge tag in question
If you start seeing these log entries after the update, the most common cause is a merge tag in a link href (for example, <a href="https://%%meeting_url%%">) where the contact doesn't have a value stored for meeting_url. Check the relevant custom field on the affected contacts, or move the URL scheme into the merge tag itself ({{$meeting_url}} containing https://...) so empty values produce a visibly empty link rather than a half-formed one.
Database Backup — Clearer Diagnostics
The Database Backup screen has been improved to surface useful information when a backup can't start.
The problem
When the server didn't have the database export tool installed in its standard location — or PHP didn't have permission to invoke it — the backup screen would simply fail with a generic error message. Operators had no way to tell why it had failed without server-level debugging.
What's new
7.0.3 adds a diagnostic panel that appears on the Database Backup screen whenever the export tool can't be found. The panel lists:
- The operating system Mumara is running on
- The user account PHP is running as
- Whether system command execution is permitted in your PHP environment
- The install paths that were checked
- A short, actionable hint for resolving the issue
In addition, the backup engine now recognizes MariaDB's export tool as an alternative to the standard MySQL one. Installations that ship MariaDB no longer need any extra setup — Mumara finds and uses whichever tool is available.
Breaking Changes
None. 7.0.3 is fully backward-compatible with 7.0.2 — no configuration changes, no breaking schema changes (the new dedup index is additive), and no API contract changes.
Migration Notes
The only schema change in 7.0.3 is the new deduplication mechanism on the schedule log, which is installed as part of the update via a background migration. Specifically, the update:
- Cleans up any historical duplicate entries in the schedule log (one-time)
- Installs the new deduplication system
- Removes the older, slower deduplication system
All three steps run in the background after the update finishes. You don't need to do anything — campaign preparation continues to work throughout, falling back to the previous logic until the migration completes, then switching automatically to the faster path.
Getting Help
If anything looks off after the update, please contact your Mumara team member with:
- The exact error message (or a screenshot)
- Which updater channel you used (Stable, Beta, or Specific Version)
- Your previous Mumara version and current PHP version
You can also visit our Support Portal or review the Troubleshooting guide.
Last updated on May 15, 2026