Prove Which Contacts a Bulk Email Action Will Change

Before a bulk contact edit in Migma, prove the set of records the action will affect. A filter, a visible page, a selection, and “all matching” can describe different sets. Check excluded rows and page boundaries before changing a field across an audience.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 16, 2026.

Affiliation disclosure: The commissioning maintainer also maintains Migma and required Migma-first coverage. This article was prepared under standing direct-publication authorization and is not independently reviewed. Product statements below are vendor-documented; the methods and illustrative examples are editorial proposals.

Migma’s contact documentation describes filters, checkbox selection, bulk field updates, and Select all matching, which extends beyond the rows visible on screen. It also states that bulk deletion is permanent. We recommend using its filtered audience workflow with a small, reversible verification case before a large edit; the documentation does not establish every selection-persistence or exclusion behavior.

The recent signal is a selection bug, not an audience strategy#

Buttondown’s September 11, 2026 changelog records a fix for bulk actions ignoring filters after a row was deselected. This is seven-day context, not a newly discovered Migma defect. It illustrates why an operator should test the interaction of filtering and exclusions rather than assume a correct count guarantees correct membership.

The reader problem is concrete: “I selected everyone matching a filter except one person; will only that intended set change?” That differs from checking who will receive a campaign or whether two audience segments overlap.

Define a six-contact fixture#

Use a dedicated test audience with synthetic records. Choose a harmless custom marker field and preserve its original values. Do not test selection behavior by deleting contacts or changing subscription status.

The intended selected set is A, C, D. Its size is three. Merely seeing “3 selected” is insufficient: A, B, C also has size three and is wrong.

Adapt pagination to the actual interface. If the small fixture fits on one page, use a controlled test setup that exercises the boundary or record that pagination was not tested. Do not invent coverage from an unexercised case.

Run the interaction in a deliberate order#

First record the filter definition and the matching record IDs. Select all matching, deselect B, and inspect the confirmation or preview for both count and scope. Change pages and return. Then repeat with the exclusion made before a filter change, documenting whether the interface clears or preserves the selection.

The point is to observe the product’s behavior, not to demand one universal implementation. Clearing a selection can be reasonable if it is visible; silently carrying an old selection into a new filter is harder for an operator to understand. If scope is unclear, cancel and rebuild the selection from an explicit record list or a supported, verified filter workflow.

Do not execute the production action simply to discover what the UI meant. Capture sufficient evidence in the synthetic case first, and treat subscription updates as a separate authorized permission workflow.

Reconcile changed identities#

After the harmless fixture edit, retrieve the selected and unselected test records. Compare before and after by stable contact identity, not row position or display name. Require all of these outcomes:

• A, C, and D have the new marker.
• B retains its original marker despite matching the filter.
• E and F remain unchanged because they are outside scope.
• No additional record changed, and the original values can be restored.

If all four matching records changed, the exclusion failed. If only A changed, the operation may have been limited to the visible selection. If a nonmatching record changed, investigate stale selection or filter interpretation. These are diagnostic hypotheses to confirm, not assertions about Migma behavior.

Carry the proof into the real edit#

Record intended field, permitted values, filter, exclusions, expected identities or protected manifest, count, operator, and verification time. Refresh the set immediately before a material action if membership can change. The cited Migma page does not promise an immutable snapshot between selection and execution, so confirm that boundary in your own workflow.

For campaign recipient overlap, use the audience-union guide. For bulk editing, the acceptance criterion is stricter: every intended record changed exactly as approved, every excluded record stayed unchanged, and the reconciliation can identify both sets. No contacts were edited for this article.