Imagine approving a customer announcement on Monday. On Tuesday, someone adds another merged change and regenerates the drafts. The title still looks familiar, but a sentence now promises a feature you never reviewed. What, exactly, did Monday’s approval authorise?
That hypothetical situation explains an important design choice in Mergelay: an Approval belongs to an exact Update revision. The familiar title of an Update is not enough to establish that its current contents have been reviewed.
Make the unit of review explicit
An Update brings together Changes, channel drafts and destinations. Review needs to establish the content that is ready and where it is intended to go. “We approved the release” is too vague if the customer email has changed since that decision.
Binding the decision to a revision gives the team a concrete reference. The relevant question becomes whether the current revision has the required approval, rather than whether someone once clicked an approval button on an object with the same name.
Revision 4: reviewer checks the customer email. A new Change is added and the Update’s drafts are regenerated. Revision 5: the new content requires its own review under the applicable approval policy.
Treat changed meaning as a reason to review again
A small edit can change the obligation a sentence creates. “Available to workspace admins” and “Available to everyone” differ by only a few words, but they tell different audiences to expect access. A migration date is another short piece of text with a large consequence.
In Mergelay, changing the source Changes in an Update regenerates its drafts and replaces pending approvals. Editing a draft also creates a new revision and re-evaluates the selected channels under the applicable policy. Reviewers should work from the current revision rather than rely on wording remembered from an earlier email.
The goal is not to make every sentence a ceremony. It is to avoid silently transferring a decision from content that was checked to content that was not.
Check the destination as carefully as the copy
A candid internal team message may be useful in a private channel and inappropriate in a customer announcement. A release note stored privately is also different from a message sent to an external destination. Review should make that distinction visible.
Before publishing, check the selected destination, the audience where applicable, and whether the action stores a draft or sends it. These checks are especially useful when an Update contains several channel drafts with different purposes.
State where policy applies
Mergelay’s default is automatic analysis and drafting with human approval before publication. That default should not be described as a claim that every possible action always requires the same manual step: authorised policies can permit certain internal drafts to proceed without a separate approval.
A useful review system makes the applicable authorisation clear. It should be possible to tell whether publication relies on a person’s decision for this revision or on a permitted policy, rather than showing an approval that never took place.
In the current workflow, ready channels can be published without inventing a human approval for policy-authorised content. Customer email keeps its separate test-send and scheduling flow. Check the actual channel state and destination: a polished draft does not establish that it is authorised to send.
Keep approval and delivery as separate facts
Approval answers whether content is authorised. Delivery records what happened when the system attempted publication. One should not be used as a substitute for the other: an approved email can still fail to send, and a provider accepting it does not prove a person read it.
When investigating a release, look for the revision, the decision, the intended destination and the delivery result. That sequence makes it easier to explain what happened without guessing from a single success label.
For your next release review, try recording one sentence: “This revision, with these drafts, is approved for these destinations.” If the content or intended publication changes afterwards, return to the relevant decision before sending.
Start with one meaningful change.
Bring your GitHub Changes into Mergelay and prepare an Update for review.
Start free