Campaign Approval After an Edit: Decide Which Changes Require Another Review

TL;DR

• Approve a specific reviewed package—not just a label—by naming subject, preview text, rendered content, sender identity, audience rule, links and schedule so the approved version matches the dispatched message.
• Enforce version identity at dispatch and make reviews focused: record a revision fingerprint server-side, verify the worker uses the approved version, and show compact diffs of material changes for quick re-review.
• Treat changes to price, audience, main link or sender as material, stop or re-review partial dispatches, and test stale-approval scenarios so backend enforcement proves the policy works in practice.

Approval should identify the version that was reviewed

A campaign approval is meaningful only when it refers to a specific message and sending plan. If the body, audience or destination can change afterward without another check, the approved object and the dispatched object may no longer be the same.

Start by defining the approval package: subject, preview text, rendered content, sender identity, audience rule, important links and schedule. Include the facts the reviewer is responsible for verifying.

The aim is not to make every edit bureaucratic. It is to preserve a clear relationship between the reviewed decision and the actual communication sent to recipients.

Separate material changes from harmless metadata

Define which edits require renewed review. A changed price, recipient group, primary destination or sender identity can materially alter the campaign. An internal note that does not affect the message may not.

For an illustrative product announcement, changing “available to all customers” to “available on selected plans” affects meaning and audience expectations. Correcting an internal campaign label may not. The policy should reflect these consequences rather than treating every database field equally.

When uncertain, show the actual difference to a reviewer instead of silently preserving approval because the edit looked small in code.

Include destinations in the reviewed package

A message can keep identical visible text while its main link changes. That can redirect recipients to a different product, environment or access flow without making the body diff look significant.

Store or display the destination associated with each important action during review. If the URL contains dynamic parts, define which parts are expected to vary and which route or domain must remain fixed.

For the product announcement, a production feature page and a staging preview may have the same button label. The approval needs to cover the real destination, not only the label's appearance.

Treat audience changes as content-risk changes

Expanding a campaign from existing customers to prospects can change what the message needs to explain and which preferences apply. The same wording may be appropriate for one group and misleading for another.

Approval should therefore include the audience definition and whether membership is frozen or evaluated later. A preview count alone is insufficient when the rule can expand substantially before sending.

If an audience edit changes the meaning of the campaign, invalidate the relevant approval and make the changed scope visible. Do not treat recipient selection as an unrelated operational field.

Use revision checks at dispatch

Record a revision or content fingerprint for the approved package. Before the worker authorizes dispatch, verify that it is using the approved version and that the campaign remains eligible to run.

A check performed only in the browser cannot protect against a later API edit or concurrent worker. The server-side boundary must enforce the relationship between approval and the dispatched content.

The PostgreSQL transaction-isolation documentation illustrates why concurrent state changes require deliberate handling. The exact mechanism depends on the application's architecture, but a stale read should not silently authorize a newer unreviewed revision.

Make the new review focused and understandable

When approval becomes stale, show what changed and why another review is needed. A useful diff can highlight altered claims, links, audience criteria and timing rather than forcing the reviewer to compare two large messages manually.

For the product announcement, the reviewer might need to inspect only the changed availability claim and the associated recipient rule. The system should still retain the complete revised package as the new approved version.

Avoid a generic “approval invalid” message with no explanation. The operator needs to know which decision must be revisited before the campaign can proceed.

Handle edits after partial dispatch separately

Once some messages have been submitted, editing the remaining campaign can create two recipient experiences. Decide whether the system permits that behavior and how it will be recorded.

A safer operational choice may be to stop pending work, review a new revision and explicitly decide the audience for the continuation. Do not silently mix old and new content while presenting the campaign as one uniform send.

Keep the original revision associated with each delivery record so support can explain what a particular recipient actually received.

Related reading: Scheduled Email Delivery: Store the Time, Content and Cancellation State.

Test stale approval as a real failure case

Use fixtures where the subject changes after approval, a link changes without visible text changes, the audience expands and two operators edit concurrently. Include a worker that claimed the campaign before the edit but has not yet dispatched.

Verify that the documented material changes prevent unauthorized dispatch and that harmless internal edits follow the intended policy. The feature should enforce the rule at the backend boundary, not merely display a warning badge.

When integrating SendDart, do not assume the delivery API supplies your organization's approval policy. The application must ensure that the approved package is the package it sends. That makes approval an enforceable release decision rather than a historical checkbox.

Related reading: How to Reduce Email Bounce Rate with Better Diagnostics.