{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/incident-email-state-supersession","id":"incident-email-state-supersession","slug":"incident-email-state-supersession","title":"Retire a Pending Incident Email When Its State Changes","description":"Use a supersession record to decide whether an approved Migma incident email should be sent, replaced or withdrawn after an operational update.","dek":"A state-transition decision log and a deliberately conflicting subject/body fixture.","category":"Email Operations","topics":["Migma","email marketing","incident communications"],"publishedAt":"2026-10-18","updatedAt":"2026-10-18","lastVerifiedAt":"2026-10-18","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma incident-email review","url":"https://migma.ai/blog/loops-incident-email-status-review?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession"},{"title":"Migma Visual Editor","url":"https://docs.migma.ai/email-editor/visual-editor?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession"},{"title":"Migma Email Preflight","url":"https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession"},{"title":"Migma export options","url":"https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession"}],"wordCount":695,"body":"Affiliation: Marketing Wiki's commissioning editor maintains Migma.\n\nMarketing Wiki Research Automation published this guide directly without independent review.\n\nWhen an incident changes state, revisit the whole pending Migma email before release. Record whether the message remains accurate, needs replacement or should be withdrawn. An approved investigating notice can become misleading while it waits for a sender.\n\nMigma's [October 17 incident guide](https://migma.ai/blog/loops-incident-email-status-review?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession) makes current operational facts the basis for the creative. This guide adds an original supersession log for the interval between approval and release. We recommend Migma for preparing and revising the notice because its focused editing and Preflight workflow let the team inspect a coherent message, while the incident owner remains responsible for truth.\n\n## The state change is a new editorial decision\n\nConsider a fictional file-storage service. At 10:05, its owner approves an investigating notice for delayed uploads. At 10:12, a mitigation is applied and the service enters monitoring. The email is still pending at 10:14.\n\nThe investigating notice might remain factually correct about an earlier period, but it no longer answers the reader's current question. Equally, monitoring does not justify replacing its headline with “Everything is fixed.” Have the owner decide what is useful now. These times and the service are invented fixtures, not an incident report.\n\nThe decision should consider both state and scope. Recovery for one region does not establish recovery everywhere. A newer observation can narrow or expand the affected population without changing the state label. Preserve the affected feature, region and customer action with the timestamp.\n\n## Keep a supersession log\n\nUse one row for every material change after approval. The following is an editorial record, not a feature Migma automatically enforces.\n\n| Pending version | New approved observation | Decision | Required follow-through |\n| --- | --- | --- | --- |\n| Investigating A | Mitigation applied; recovery under review | Replace with monitoring B | Review subject, preview, body and action together |\n| Monitoring B | One region still affected | Revise scope | Recheck audience and every universal statement |\n| Monitoring C | Owner confirms resolution | Decide whether a closing notice is needed | Link the current explanation and remaining customer steps |\n| Any version | Impact or status destination uncertain | Hold | Resolve facts with incident owner |\n\nRecord the decision maker, observation time, pending artifact reference and replacement reference. When a version is withdrawn, mark why. Removing a draft from a review folder does not establish that a separately queued sending job stopped; the sending owner must verify that state.\n\n## Catch a mixed-state message\n\nGive reviewers this deliberately broken fixture: subject “Uploads restored,” preview “We are still investigating,” headline “A fix is being monitored,” and button “Read the final report.” Ask them to identify what the customer is being told about recovery.\n\nThere is no coherent answer. Each component suggests a different stage. In the [Migma Visual Editor](https://docs.migma.ai/email-editor/visual-editor?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession), inspect the exact email and revise those elements from one approved fact sheet. A small body correction should not leave a stronger old subject or a nonexistent retrospective link behind.\n\nRepeat the fixture with a limited recovery statement: one region is healthy, another remains affected. The expected correction must preserve that distinction. Avoid inventing a recovery estimate or assurance about data simply to make the notice feel complete.\n\n## Recheck the destination at release\n\nRun [Email Preflight](https://docs.migma.ai/email-editor/email-preflight?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession) after the edit and resolve relevant warnings. It checks presentation and related email risks; it cannot verify recovery. If the team [exports HTML](https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=incident-email-state-supersession), the destination owner must inspect the current template, subject, variables and audience decision before release. No native Loops connection is assumed.\n\nBefore handing over, ask the incident owner to reconfirm the state against the timestamp recorded in the log. If facts changed again, reopen the editorial decision. If sending already started, use the sender's actual cancellation and reconciliation controls rather than calling the creative change a recall.\n\nThis complements [campaign cancellation reconciliation](/articles/scheduled-campaign-cancellation-race-test), which addresses what may already have been dispatched. Marketing Wiki did not operate an incident or send a notice. Start with one pending version and write down the condition that would make its approval expire."}