See what one shipped change becomes for each audience
These are complete, representative Mergelay output packs rather than generic writing advice: one source, a clear release boundary and distinct drafts for customers, colleagues and the public record.
The facts stay fixed; the job of the message changes
A pull request is written for the people deciding whether code is safe to merge. A customer email has a different job: tell the affected person what will change, when it will change and whether they need to act. An internal Slack post must name rollout context, the owner and the questions support may receive. Reusing the same paragraph everywhere saves typing by sacrificing comprehension.
Each pack below starts from a plausible merged change and preserves the same supported outcome across three formats. The vocabulary, emphasis and next action change with the reader. That is the product behaviour being demonstrated. The examples do not claim that Northwind, Acme or another invented logo uses Mergelay; there is no borrowed social proof hidden in the design.
The short drafts are intentionally publishable rather than exhaustive. Evidence links, uncertainty and the complete source list remain in the workspace for review. A public message should not expose a private repository path merely to prove that automation ran, and an attractive sentence should not survive review when the merge does not support it.
THE OUTPUT PACKS
Five changes that demand different communication
Open each scenario as a miniature release: the source boundary appears first, followed by three drafts written for the destinations that actually need it.
01 · API breaking change5 related pull requests
Invoice API fields retire on 30 June
A migration with a real deadline must make the required action impossible to miss while giving the internal team enough context to answer integration questions.
Customer emailAPI owners
Action required: update Invoice API fields by 30 June
The legacy customer_id and issued_at fields will stop being returned after 30 June. Replace them with customer.id and issuedAt before that date; requests and authentication do not change.
Open the migration guide
SlackSupport + Sales
Invoice API migration is ready for customer notice
The compatibility window closes on 30 June. Support can use the migration guide for field mappings; route accounts with custom invoice exports to the API team before promising a deadline exception.
Owner · Platform API
Release notePublic record
Clearer field names for Invoice API responses
Invoice responses now expose nested customer details and ISO-style timestamps. The former flat fields remain available during the migration window and are removed after 30 June.
Migration details
02 · UX feature3 related pull requests
Saved views keep the filters a team uses every morning
The implementation touches query persistence and permissions, but the useful story is that recurring work no longer begins by rebuilding the same filter set.
Customer emailWorkspace admins
Save the view your team returns to
A filtered workspace view can now be named, saved and shared with colleagues who have access to the same records. Existing bookmarks continue to work and no saved view changes record permissions.
Create a saved view
SlackCustomer success
Saved views are rolling out today
Customers can preserve filters and share the resulting view inside their workspace. The feature does not grant access to hidden records, so permission questions should still be handled through the existing role settings.
Support note · No migration
SocialProspective users
Your morning view should already be waiting
Save a filtered workspace view once, then return to the same working set or share it with the teammates who need it. Less setup before the useful work begins.
See saved views
03 · Production hotfix1 focused pull request
Stale sessions no longer bounce between login and inbox
A hotfix needs restrained language. Customers need to know the symptom has stopped; internal teams need the trigger, verification and escalation path without an invented incident narrative.
Customer noticeAffected users
Login now recovers from an expired session
Some expired browser sessions repeatedly redirected between sign-in and the inbox. The session is now cleared before sign-in resumes, so reloading the page returns you to a usable login screen.
Sign in again
SlackSupport + Engineering
Hotfix deployed for the login redirect loop
The fix clears the stale cookie before redirecting to authentication. The regression test covers the former login-to-inbox loop; escalate only if a fresh session reproduces it after a hard reload.
Status · Deployed
Release notePublic record
Expired sessions return cleanly to sign-in
The application now removes invalid session state before redirecting, preventing the repeated navigation that could occur when an old browser cookie outlived its server session.
No customer action required
04 · Workflow improvement2 related pull requests
Scheduled exports now run every hour
A frequency change sounds small in code but alters when operational teams can rely on the data. The message should state the new cadence and preserve confidence in existing schedules.
Customer emailOperations leads
Your scheduled exports now refresh hourly
Exports that previously ran overnight are now produced every hour. Existing schedules keep their destination and historical files remain unchanged, so there is nothing to reconfigure.
Review export schedules
SlackSupport + Operations
Hourly export cadence is live
The scheduler now processes existing export jobs once per hour. Watch for customers who built a daily downstream import around file arrival time; their destination is unchanged but they may see additional files.
Rollout · Complete
Release notePublic record
Fresher data in every scheduled export
Scheduled exports are generated hourly instead of once overnight. The more frequent cadence applies automatically to existing schedules without altering their format, destination or prior export history.
Read export documentation
05 · Admin capability4 related pull requests
Permission changes appear in the audit log
Security-facing work must separate what is recorded now from what the feature does not promise, while giving administrators a precise place to verify sensitive workspace changes.
Customer emailWorkspace owners
Review role and permission changes in one audit trail
The audit log now records who changed a workspace role, which member was affected and when the change occurred. Earlier permission events are not reconstructed retroactively.
Open the audit log
SlackSecurity + Support
Permission events are now auditable
Role assignments and permission changes now write an immutable audit entry with actor, target and timestamp. This improves investigation context but does not replace the customer’s external identity-provider logs.
Owner · Workspace security
Release notePublic record
A clearer history of workspace access changes
Workspace owners can now trace role and permission changes in the audit log. Each new entry identifies the person who made the change, the affected member and the recorded time.
View audit logging
These examples demonstrate the product format using representative scenarios. They are not customer case studies, measured outcomes or evidence that a named company uses Mergelay.
THE REVIEW TEST
How to judge whether an output is ready
01
Compare every consequential claim with its source
Dates, removals, defaults, availability and customer actions deserve a direct evidence check. Smooth prose is not a substitute for support in the merged work.
02
Read it as the named audience
A support lead needs escalation context; a customer needs the consequence; a public reader needs a durable explanation. If one draft tries to serve all three, split it.
03
Remove the channel when interruption is not earned
Not every change deserves email or social distribution. Keep the private record, and publish only the drafts whose readers benefit from knowing now.
WHAT THIS PAGE CANNOT PROVE
Examples show the output, not your future result
The gallery does not predict how much editing a particular repository will need. Pull request quality, product context and the evidence available in the diff still determine the starting point.
No delivery shown here is automatic merely because a draft exists. Internal communication can follow a workspace policy; customer-facing email, public and social communication still require the applicable review path.
Mergelay does not host a public changelog page. The release-note output is private Markdown that you copy or deliver to your own CMS through a configured destination.
Questions
Are these examples generated from real customer repositories?
No. They are representative product scenarios built to expose the complete output shape without presenting an invented customer as social proof. Real customer material will appear only with the customer’s permission.
Does every Update create all three drafts shown here?
Only the formats enabled for that workspace and selected on that Update are prepared. A release can remain a private record, go to an internal destination, reach customers, or combine those paths.
Can one Update contain several merged pull requests?
Yes. Related merged work can be grouped into one ordered release with up to ten sources. Unrelated changes should remain separate rather than being forced into one story.
RELATED
Where to read next
Invoice API email exampleRead one complete migration email with its subject, body, action and editorial reasoning.