Changelog vs Knowledge Base: What to Publish When Your SaaS Changes

The update sounds useful. Then a customer tries to use it. A worked CSV-export example shows where an announcement ends and a help article earns its place.

A tactile cut-paper megaphone and an open instruction book connected by a ribbon from a product-release parcel.

Imagine opening a product update that says you can finally schedule the report you export every Monday. Good news. You click through, ready to set it up, and find the same announcement again: a benefit, a screenshot, and no explanation of which filters the export will use.

The team communicated the release. You still cannot finish the task.

That small gap is where a changelog and a knowledge base need to work together. The announcement helps you notice a useful change; the help article stays beside you while you use it. Writing both from one release brief makes sense. Copying the same text into both places usually leaves one of those jobs unfinished.

Changelog vs knowledge base: two different reading moments

A person opens a changelog to catch up. They want to know whether a change affects their work, whether they have access, and where to try it. A useful entry can answer those questions in a few paragraphs.

A person opens a help article with a task in mind. They need prerequisites, steps, expected results, and answers when something does not work. They might arrive months after the original announcement, without knowing when the feature launched.

Does every release need two pieces of writing?

A fix that requires no action may need only a short announcement. A new configuration deserves instructions. When an existing workflow changes, revising its current guide is often more useful than creating another article that competes with it.

Availability belongs in both places. If only administrators can use the feature, say so before a reader invests time in it. If a rollout is gradual, describe who has access now. These are small editorial choices, but they can spare customers a fruitless search through their settings.

Bringing these surfaces together is also showing up in the tools themselves: AnnounceKit introduced a Knowledge Base beta beside its changelog in August 2026. Sharing a home makes the connection easier to find. The writing still needs to serve each reader's purpose.

A worked example: scheduled CSV exports

The following example describes a fictional reporting SaaS. Its interface, behavior, and feature are illustrative; they are not Sinalio features.

Suppose the release brief confirms that report administrators can schedule a weekly CSV export from a saved report. The schedule stores the selected filters, runs in the workspace time zone, and places the completed file in the export history. Editing the saved report later does not change an existing schedule.

That last detail deserves attention. An announcement should introduce the benefit, while the documentation should explain the behavior that could otherwise surprise someone.

Example changelog entry

Schedule your weekly CSV exports
Report administrators can now schedule a weekly CSV export using a saved report. Choose the day and time once, then find each completed file in your export history.
Open Reports → Exports and select New schedule to get started. The schedule uses the workspace time zone and keeps the filters selected when you create it.
Read the setup guide for instructions, filter changes, and troubleshooting.

The entry gives readers a reason to care and a next step. It does not need every troubleshooting branch. The setup guide carries that detail.

Turn the same brief into a useful help article

Example help article

Before you start
You need report administrator access and a saved report. Check the workspace time zone and the filters you want the export to use.
Create the schedule
  1. Open Reports → Exports and select New schedule.
  2. Choose your saved report.
  3. Select Weekly, then choose the day and time.
  4. Review the filters and workspace time zone.
  5. Select Save schedule.
Expected result: the schedule appears in the schedule list with its next run time. After a successful run, the CSV appears in the export history.
Changing filters: edit the schedule when you want future exports to use different filters. Changing the original saved report does not update an existing schedule.
If the next run time looks wrong: check the workspace time zone and the selected day and time before saving again.

For a real product, follow these steps in the actual interface before publishing. Add screenshots only when they help explain a choice, and avoid including customer data in them.

Claude or ChatGPT can help turn a confirmed brief into these two drafts, especially when the release has several restrictions to carry across. Give the assistant the actual labels and behavior, and ask it to flag missing facts. Read its output against the product: a fluent sentence about a setting that does not exist is still a broken instruction. Our earlier AI workflow article explores that drafting process in more detail.

The announcement ages; the instructions change

A month later, imagine that our fictional product changes how filters work. Existing schedules can now follow changes to the saved report. The help article needs to explain the new behavior, and customers relying on the old behavior need to hear about the change.

The original announcement can remain a useful record of the launch. Add a dated clarification if someone finding it today could be misled, and point to the current instructions. Rewriting every old announcement as if the product had always worked this way would make the history harder to follow.

This is also why the link between the two matters. Someone arriving through a public update should reach the current guide. Someone following the guide should not need to read a sequence of old releases to reconstruct how the product works.

Before publishing, ask a teammate who did not build the feature to try the instructions. Watch where they hesitate. That pause may reveal more than another editing pass. For the shorter announcement, our changelog writing guide covers choosing what to include.

In the CSV example, success is fairly ordinary: next Monday, the customer knows where the file will appear, which filters it contains, and what to change before the following run. The announcement got their attention. The guide helped them get back to work.

Written by

João Müller

Changelog vs Knowledge Base: What to Publish When Your SaaS Changes