The product updates changelog turns what shipped in your connected repositories into a dated, customer-facing page. Instead of judging raw code changes, entries are written from your repositories' published release notes, in plain, user-facing language.
Any member of your workspace can set up and manage a changelog page. You'll need at least one repository connected and one Notion connection in place before you start.
Entries don't post themselves straight to your Notion page. Depending on your workspace's review setting and the quality of the underlying evidence, a new entry either:
<aside> ✏ An entry that isn't fully grounded in what actually shipped, or that's based on a partial summary of the change, always waits as a draft for you to review, regardless of your workspace's review setting.
</aside>
You need a Notion connection already set up, and the page you want to use as the changelog's home.
Result: the page becomes the changelog's parent. Grouped changelogs (month or week) get one dated child page created per period; a per change changelog gets one page per entry; a running changelog keeps everything on the single page.
<aside> ✏ Grouping and detail level shape entries going forward. Changing them later doesn't rewrite or restructure pages you've already published; those stay as history.
</aside>
A changelog page can be fed by more than one repository, but each repository can only feed one changelog page at a time.
Result: the repository now contributes entries to this page whenever it has a shipped, published release.