Mautic 7.2 Stage Merging and Weights: What Changed

Mautic 7.2 adds three stage-management entries [1]

About this guide: It reads the published Mautic 7.2.0 release record [1] alongside the Mautic 7.2 stage documentation. [2] It does not report a hands-on test of these changes. It also makes no claim that Deal Flow has been tested with, or declared compatible with, Mautic 7.2.0.

What the release record actually lists

The stable 7.2.0 record was published September 2, 2026 and names the Lynx Edition. [1] Mautic also published a release announcement on its website that day. [3]

Within that record, the stage-related entries are:

• “Warn about duplicate stage weights.” [1]
• “Merge stages.” [1]
• “Add a point trigger for contact stage changes.” [1]

Those entries establish scope, but their short labels do not establish button locations, screen sequences, warning timing, or the configuration fields of the point trigger. This page therefore does not invent an interface walkthrough. If you plan to use the listed point trigger, locate it in your own installation and validate its available conditions and resulting point change there.

How Mautic stage weights order contact stages

Mautic’s 7.2 documentation describes a stage as a lifecycle position for a contact and says each contact can belong to one stage at a time. [2] The same documentation defines weight as the stage’s ordering value: a higher weight represents a point farther along the lifecycle. [2]

Weights must be unique across all funnels, not merely within one funnel. [2] Mautic’s documentation also says movement to a lower-weight stage is prohibited. [2] That makes a weight edit more than a cosmetic reorder: it changes which positions Mautic considers earlier or later. Review the full set before saving a new number, especially if separate teams use different funnel names.

The table is deliberately simple. Its lesson is not that every organization needs four stages; it is that each weight should be unique across the complete instance and should make the intended lifecycle order obvious.

What a stage merge changes

The Mautic 7.2 documentation says merging transfers contacts assigned to the source stage into the target stage and moves related stage history into that target. [2] It then permanently deletes the source stage. [2] The documented operation cannot be undone and requires permission to edit and delete stages. [2]

That combination deserves change-control discipline. Pick one unambiguous target, record both stage names and identifiers, and decide what a contact’s new position means before the source disappears. A backup and a staging rehearsal give you a recovery path and a place to observe your own extensions, automations, and integrations without treating documentation as a substitute for local validation.

Checklist before merging or reweighting stages

1. Define the intended lifecycle order. Write down what each contact stage means and which movement counts as progress. Resolve ambiguous or overlapping definitions before changing weights.
2. Record the current configuration. Capture stage names, identifiers, funnels, weights, and the planned source and target. Include enough detail to compare the result later.
3. Check every weight across the instance. Build one list across all funnels and choose unique values that express the intended order, consistent with the documented global uniqueness rule. [2]
4. Count affected contacts and sample their history. Save baseline counts and select representative records whose stage timeline you will inspect again after the change.
5. Inventory dependencies. Search campaign logic, point logic, reports, exports, API consumers, webhooks, and internal runbooks for the source stage’s name or identifier.
6. Review synchronized mappings. Identify every integration that maps a contact stage to a deal stage or another system’s status. Write down the expected target on both sides.
7. Confirm access and recovery. Verify the operator has the documented edit and delete permissions, take a restorable backup, and rehearse in staging when your deployment process permits it. [2]

Checklist after the change

1. Confirm the intended stage set. Verify the target remains, the source has been removed after a merge, and the surviving weights are unique. [2]
2. Reconcile contact counts. Compare the target-stage population with your baseline and investigate unexplained differences rather than assuming the transfer worked as expected.
3. Inspect representative histories. Open the records selected before the change and confirm their relevant stage history is understandable in the target stage.
4. Test movement rules. Exercise intended forward changes and a controlled lower-weight attempt so your team sees how this installation applies the documented ordering rule.
5. Re-run dependent automation. Validate campaign and point behavior with test contacts. Treat the stage-change point trigger as something to verify locally, not as a workflow this guide has tested.
6. Exercise each integration direction. Send a representative stage change outward, then originate the corresponding change from the connected system. Check payloads, logs, and the final records.
7. Update operating material. Remove the retired stage from reports, mapping tables, runbooks, imports, and onboarding instructions.

Keep contact stages and deal stages distinct

A Mautic contact stage describes one person’s lifecycle position. A deal pipeline stage describes one opportunity’s position in a sales process. The records can inform each other, but they are not interchangeable. The Mautic stage vs pipeline guide explains that data-model distinction, while the guides to customizing deal stages and choosing default deal stages cover the deal side.

This distinction matters after a contact-stage merge. A mapping may still point at the retired source even though the deal stage remains valid. Re-verify every configured stage-synced integration mapping. If a mapping is designed to run in both directions, test contact-to-deal and deal-to-contact movement separately, confirm the intended target stage in each direction, and check that no rule recreates a stale value.

Sources and transparency

1. Release record: Mautic Community 7.2.0 Lynx Edition release record, tag 7.2.0; published September 2, 2026; fetched September 3, 2026. The three quoted entry labels on this page come from that record.
2. Stage documentation: Mautic 7.2 documentation: Stages; fetched September 3, 2026. This source supports the descriptions of weights, ordering, permissions, and merge effects.
3. Release announcement: Mautic 7.2 Lynx Edition released; published September 2, 2026; fetched September 3, 2026.

Verification boundary: This guide attributes release-note text and documented behavior to the sources above. It does not present inferred screen details as facts, and it does not claim first-hand compatibility testing for Deal Flow on Mautic 7.2.0.

Frequently asked questions

What changed about Mautic stages in 7.2?

The Mautic 7.2.0 release record lists three stage-management entries: “Warn about duplicate stage weights,” “Merge stages,” and “Add a point trigger for contact stage changes.” [1] Those labels are release-note entries, not a report of hands-on testing.

How do Mautic stage weights work?

Mautic’s 7.2 stage documentation says weights must be unique across all funnels, a higher weight represents a stage farther along, and movement to a lower-weight stage is prohibited. [2]

What happens when Mautic stages are merged?

Mautic’s 7.2 documentation says a merge moves contacts and related stage history into the target stage, then permanently deletes the source stage. It requires edit and delete permissions and cannot be undone. [2]

What should I recheck after merging or reweighting stages?

Recheck contact placement, representative stage history, weight uniqueness, intended forward and backward transitions, dependent automation, and every integration mapping that stores a stage name or identifier. For a bidirectional mapping, test one change in each direction.