Publish a changelog customers can use
Explain what changed and connect shipped work to its original requests.
Last updated 9 September 2026
On this page
Write for the person using the change
A changelog should answer three questions: what is new or better, who it helps, and how to use it. Replace internal implementation notes with the visible outcome. “Save routes for offline use” is more helpful than a list of internal components.
Create the update
Open Changelog and create an entry.
Add a clear title, summary, and release date. Use the relevant New, Improved, or Fixed category.
Write a short explanation and include any steps customers need to take.
Link the related requests or roadmap items when they explain the work behind the release.
Preview, publish, and open the public entry to verify the final result.
Use images and links sparingly
A screenshot is useful when a new control is hard to find. Link to a help article for detailed instructions instead of putting a complete tutorial into every release note. Keep related work links relevant to the actual scope of the release.
Keep status and announcements aligned
Moving a roadmap item to Shipped does not by itself write a changelog entry. Publish the explanation as a separate step and update only the requests that the release addresses. If you edit a published entry, publish its changes again so customers see the revised version.