Mumara Campaigns 7.0.4
Release Date: May 2026 Type: Patch Release Previous Version: 7.0.3
Version 7.0.4 is a small patch release on top of 7.0.3. It restores Dynamic Content tag creation on Linux installations, fixes Trigger-tab settings sometimes not taking effect after clicking Save, and resolves three related issues that were preventing the "When a contact opens an email" and "When a contact clicks a link" automation triggers from firing reliably — especially on setups that use a masked tracking domain.
If you're already on 7.0.3, this update is straightforward — no schema changes, no manual steps, just install through the Update Wizard.
Highlights
| Area | Summary |
|---|---|
| Dynamic Content | Creating or saving a Dynamic Content tag no longer fails with a server error on Linux installations |
| Triggers — Tab Settings | Timeline and Automation settings on the Triggers tab now persist immediately when you click Save, regardless of how background work is configured |
| Automations — Open Trigger | "When a contact opens an email" reliably fires for every open, including the very first one after a send |
| Automations — Click Trigger | "When a contact clicks a link" reliably fires, including for installations that route tracking through a masked CNAME domain |
| Automation Coverage | Opens and clicks generated by triggers, drip groups, admin notifications, and Send Email actions now feed the Automations engine the same way broadcasts already do |
Before You Update
7.0.4 is a patch release with no breaking changes, no schema changes, and no manual steps. The update simply replaces the changed application files in place.
How to Update
Navigate to Tools → Update in the admin panel, pick your update channel (Stable is recommended for production), and click Begin Update.
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.3 — PHP 8.4 (with 8.3 and 8.5 also supported).
Dynamic Content — Tag Creation Restored on Linux
Customers reported that opening Dynamic Content and clicking Save on a new or edited tag returned a server error and the tag was never created.
What was wrong
A small internal reference in the Dynamic Content save flow worked correctly on Windows and macOS test environments but failed on Linux production hosts because Linux is stricter about how files are looked up. The result was a server error every time you tried to create or update a Dynamic Content tag.
What's fixed
The reference now resolves correctly on every supported operating system. Dynamic Content tag creation, editing, and the associated activity-log entry all behave the same as they did before the regression appeared.
What you'll notice:
- Creating a new Dynamic Content tag completes successfully without errors
- Editing an existing tag and clicking Save now updates and returns to the listing as expected
- The corresponding entry shows up in the activity log
Triggers — Tab Settings Always Save
The settings on the Triggers tab (Timeline Settings and Automation Settings) could appear to save successfully but not actually take effect — on some installations, a refresh of the page would show the old values back. The behavior depended on how Mumara's background work was configured on your server.
What was wrong
These two screens were routing their save through Mumara's background job system, which on certain queue configurations meant the new values would only land after a worker picked the job up — anywhere from a few seconds to a minute later, or in some configurations not at all. The AJAX request returned success immediately because the job had been queued, but the values weren't in the database yet, so a quick refresh showed the previous state.
What's fixed
Both screens now write their settings synchronously as part of the Save click. By the time you see the success response, the values are already persisted, and refreshing the page shows the new state every time.
What you'll notice:
- Saving Timeline Settings or Automation Settings reflects the new values immediately on refresh
- Behavior is now identical regardless of which queue driver is configured on your installation
- Other parts of the trigger flow that legitimately belong in the background (such as fan-out work) are unaffected — only the settings persistence itself was moved to run inline
Automations — Open & Click Triggers Now Fire Reliably
Three independent issues were combining to make the "When a contact opens an email" and "When a contact clicks a link" automation triggers unreliable. Depending on your setup, automations connected to these triggers could fail on every event, only fail for masked tracking domains, or fail only for the very first open after a send while later opens worked.
This release resolves all three.
Tracking-variable loss on masked (CNAME) tracking domains
Installations that use a masked tracking domain (a CNAME pointing at your Mumara instance, so click and open URLs appear to come from your own brand) were dropping the tracking metadata that the Automations engine needs to match a click back to the workflow that scheduled it. Click-triggered automations on masked-domain setups effectively never fired.
The tracking handler now reads the metadata correctly from the masked-domain request shape, matching how open tracking already worked. Click-triggered automations on CNAME-masked installations now fire on every match.
Full coverage for triggers, drips, admin notifications, and Send Email actions
When an email was sent by a broadcast, the Automations engine could match its opens and clicks back to a workflow. When the same email was sent by a trigger, a drip group, an admin notification, or an Automations Send Email action, the resulting open and click URLs were missing the metadata the engine needed — so those opens and clicks couldn't be tied back to any workflow and the next step never ran.
The tracking metadata is now attached the same way for every send path. An automation that waits on a contact opening a drip email, clicking a link in a triggered campaign, or interacting with anything sent by a Send Email action now fires reliably.
First-open timing race
A timing issue between Mumara's tracking handler and the Automations engine was causing the very first open of a recipient to be skipped by the workflow, even when everything else was configured correctly. Subsequent opens on the same email by the same recipient were caught, but the first one — typically the most important — was lost.
The handoff has been re-ordered so the Automations engine sees the open as a brand-new event instead of mistaking it for a duplicate. The first open of every email now fires the workflow as expected.
What you'll notice (combined effect of all three fixes):
- "When a contact opens an email" triggers fire on every open, including the first one
- "When a contact clicks a link" triggers fire on every click, including on masked tracking domains
- Automations attached to drip groups, triggers, admin notifications, and Send Email actions match opens and clicks the same way they do for broadcasts
- No re-configuration of existing automations is required — they begin working correctly the moment the update is installed
If you've had automations that depend on Open or Click triggers sitting idle or only catching a fraction of expected events, re-test them after the update. The fixes apply to new opens and clicks once the update is installed — historic events from before the update are unaffected.
Breaking Changes
None. 7.0.4 is fully backward-compatible with 7.0.3 — no configuration changes, no schema changes, and no API contract changes.
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 22, 2026