What changed, who it affects, and whether you need to act

The product ships on a regular cadence rather than in large occasional drops. Smaller and more frequent releases are easier to read, easier to reverse and easier to give notice about, and they mean an administrator can skim a short entry rather than working through a quarterly document trying to find the paragraph that affects their configuration.

Fixes and small improvements ship continuously and are grouped into a single entry rather than generating one entry each. Anything that changes a workflow, a permission, a default, an integration behaviour or a data shape gets its own entry regardless of how small the code change was, because those are the changes that reach an administrator's desk.

Security patches are released as soon as they are ready. They appear in the changelog with the fact of the fix and the affected surface, and with the detail an attacker would need withheld until the fleet has updated. That is standard practice and we follow it rather than pretending disclosure is instantaneous.

Every entry answers four questions in the same order, so the page can be skimmed. What changed, stated in the terms a recruiter or administrator uses rather than in the terms of the pull request. Who it affects, named by role, plan and market, because a change to the India WhatsApp path is not a change to a UK desk. Whether action is required, stated as yes or no, with the action if the answer is yes. And whether anything breaks, with the notice period and the migration path.

Entries are typed so the feed can be filtered: new capability, improvement, fix, security, deprecation, breaking change. A status badge change from the feature status page is its own type, so you can subscribe to the question of what moved from in build to shipping without reading everything else.

A breaking change is any change that can stop a working configuration from working: a removed or renamed API field, a changed webhook payload, a retired integration, a permission default that becomes stricter, an import format that stops being accepted. These are announced before they happen, not described afterwards.

The notice states the date the change takes effect, what specifically breaks, how to tell whether you are affected, and what to do about it. Where we can detect that a given account is affected, the notice goes to that account's administrators directly rather than relying on them reading a feed. An API deprecation runs the old and new behaviour in parallel for the notice period wherever that is technically possible.

We are not going to promise a specific number of days here before there is a released product and a support organisation sized to honour it. What we will say is that the notice period will be stated in the terms of service, that it will not be shortened retroactively, and that a breaking change shipped without notice is treated as an incident rather than as a release.

The changelog publishes an RSS feed at the same address as this page with a feed suffix, containing the full text of each entry rather than a headline and a link. Full-text entries matter because most people read a changelog inside a feed reader, a Slack channel or an internal digest, and a truncated entry forces a click that usually does not happen.

Three ways to subscribe. Point any feed reader at the feed URL. Pipe the feed into a Slack or Teams channel using that platform's RSS application, which is how most operations teams consume this sort of thing. Or opt in to the release email in your account notification settings, which sends the same entries and can be scoped to breaking changes only.

Account administrators receive breaking-change and security notices by email regardless of feed subscription, because those are the two categories where not having noticed is not an acceptable outcome.

Deprecation is announced separately from removal. An entry marking something deprecated says that it still works, that it will not be improved, what replaces it, and when it is scheduled for removal. The removal is a second entry on the date it happens. Two entries rather than one, because the gap between them is where an administrator does the migration work.

Integrations are the common case. A third-party platform changes its API, retires an endpoint or closes a partner programme, and an integration that worked becomes one that cannot. When that happens the entry says which platform, what changed on their side, what we can and cannot do about it, and whether the integration moves to a reduced state or is withdrawn. We do not leave a dead connector on the integrations page with a green tick.

Marketing announcements do not go here. A new pricing page, a new market, a conference appearance and a funding event are not product changes and putting them in a changelog trains people to stop reading it. Nor do internal refactors that no customer can observe, however satisfying they were.

Roadmap items do not go here either. An item moving from planned to in build is a roadmap change and belongs on the roadmap page; it only reaches the changelog when it ships and the status badge moves. Keeping the two apart is what lets the changelog be read as a record of things that actually happened.

Three pages, three jobs. The feature status board answers what is true right now. The roadmap answers what is intended and what it is waiting on. The changelog answers what changed and when, and it is the only one of the three that accumulates rather than being rewritten.

Read together they are the audit trail for every capability claim on this site. A feature page says a capability ships and names the components it runs on; the status board puts it in one of four states; the changelog records the date it entered that state. If those three ever disagree, the changelog is the one to trust, because it is the one with a date attached.