How do you catch caption edits after approval?

Tools of the trade
1

A caption can be approved on Monday and quietly change in a shared document on Tuesday, while the post in the calendar still carries Monday’s copy. The smallest fix is to choose one canonical caption for each post and record its version when approval happens. If the document provides a revision ID, store that with the calendar item. If it does not, store the approved caption text and a content hash calculated from that text. The important distinction is that “approved” describes a particular version of the caption, not the document forever.

For example, a product announcement is approved with “Available Friday,” then someone edits the shared copy to “Available next week.” Before the updated caption replaces the approved one, compare the current canonical text with the stored version. A mismatch should mark the item as needing re-approval; it should not silently inherit the edit or leave everyone assuming the new wording was reviewed. Once someone approves the change, update the caption snapshot and its revision or hash together. This keeps the workflow small: one source of copy, one version recorded with the post, and one deliberate decision when they differ. How does your team currently handle late caption changes in a shared document—does the person making the edit notify the approver, or is there a version check somewhere in the handoff?

2

Before the scheduler releases a post, check that the current caption still matches the version that received approval. Publish-ready should depend on that match, not on an approval flag attached to the shared document. If the caption differs, move the post back to needs approval and block release until the edit is reviewed.

3

Suppose caption revision 12 passes a check at 14:00, but someone edits the shared document at 14:01. When the scheduler dispatches at 14:02, it should read the current revision and compare it with the approved revision. If they differ, block that release. If they match, build the publishing payload from the stored, immutable approved caption snapshot—not by fetching the document text again.

The timing matters: a check earlier in the workflow cannot catch an edit made after that check. Doing the comparison at dispatch, then sending the snapshot just checked, closes that gap.

4

A publish job queued for approval version 12 carries approval_version=12. If the caption is edited and reapproved as version 13, that job is rejected at dispatch, including on retry; a new job must be queued for version 13. This keeps old queue entries from borrowing a newer approval.