Skip to main content
The Changelog module helps you publish product updates and keep users informed about what has changed. Use it for release notes, feature announcements, important improvements, bug fixes, and other updates that users should know about. Published changelog entries appear on your public feedback portal. Users can search updates, read details, and like entries that are useful to them. Public changelog display in Suggix

Changelog list

Open Changelog from the Suggix dashboard sidebar to view and manage all changelog entries. Changelog list in the Suggix dashboard The list includes:
  • Status filters: View All, Draft, Scheduled, or Published entries.
  • Search: Find entries by title or content.
  • Sorting: Sort by publish time, likes, or views.
  • Grouped sections: Entries are grouped by status so drafts, scheduled releases, and published updates are easy to scan.
  • Entry dates: Published and scheduled entries show their relevant release date.
Use the list to review upcoming releases, find older updates, and check which announcements are already public.

Create a changelog

Click the create button in the top-right corner of the Changelog page to add a new entry. Create a new changelog entry When creating an entry, include:
  • Title: A clear release title, such as Version 3.4.0 or Faster loading.
  • Summary: A short opening paragraph that explains the value of the update.
  • Sections: Group related changes under headings such as New Features, Improvements, or Bug Fixes.
  • Details: Explain what changed, who benefits, and whether users need to take action.
  • Images: Add screenshots when the update changes a visible workflow or interface.
Write changelog entries for users, not only for your internal team. Lead with the user-visible benefit before adding implementation details.

Publish now or schedule release

You can publish a changelog immediately or schedule it for a future date and time. Scheduled changelog release date and time picker Use Publish Now when the update is already live. Use a scheduled release when you want the changelog to go public at the same time as a product launch, maintenance window, or marketing announcement. Scheduled changelog entries remain hidden from the public portal until the selected publish time.

Edit a changelog

Open an entry from the Changelog list to edit it. You can update:
  • Title and body content
  • Release details and formatting
  • Embedded images
  • Publish time
  • Draft, scheduled, or published state
The editor also shows entry properties, including creation time, update time, publish time, views, and likes.
For published entries, save changes carefully because updates affect what users see on the public portal.

More actions

Use the more actions menu in the entry editor for destructive or state-changing operations. Changelog more actions menu Available actions depend on the entry state:
  • Delete: Permanently remove the changelog entry.
  • Unpublish: Remove a published entry from the public portal and return it to a non-public state.

Delete a changelog

To delete an entry:
1

Open the changelog entry

Select the entry from the Changelog list.
2

Open more actions

Click the more actions menu in the top-right corner.
3

Choose Delete

Confirm the deletion only after verifying the entry is no longer needed.
Deleting a changelog entry is permanent. If you only need to hide a published entry, use Unpublish instead.

Public changelog experience

Published entries appear in the public portal under the Changelog tab. Users can:
  • Search changelog entries.
  • Read the full update by selecting Read more.
  • Like entries to show interest.
  • Browse updates by release date.
Use concise titles and clear summaries so users can quickly understand what changed from the list view.

What to publish

Publish updates when users need to know about a meaningful change. Good changelog entries include:
  • New features
  • Important improvements
  • Bug fixes that affected many users
  • Workflow or UI changes
  • Integrations and API changes
  • Deprecations or breaking changes
Avoid publishing very small internal changes unless they affect the user experience.

Best practices

  • Use clear titles instead of vague release names.
  • Keep entries concise and user-focused.
  • Mention breaking changes near the top.
  • Add screenshots for visible product changes.
  • Schedule entries when the release should go public at a specific time.
  • Unpublish instead of deleting when you may need the entry again later.
  • Publish consistently so users know the portal is active.

Voting and prioritization

Decide which feedback should move into the roadmap.

Roadmap and status

Keep public statuses aligned with product progress.