← Back to blog

How to Publish a Changelog in Heedback

· 7 min read · Heedback Team

Your users want to know what’s changing. Whether it’s a new feature, a bug fix, or a performance improvement, a well-maintained changelog builds trust and keeps your community engaged. Heedback’s changelog lets you publish polished release notes, categorize entries with labels, support multiple languages, and notify subscribers automatically.

This guide walks you through creating your first changelog entry and setting up an ongoing publishing workflow.

Prerequisites

Before publishing changelog entries, make sure:

  • You have an active Heedback organization with a Pro plan.
  • Your account has admin or owner permissions.
  • You’ve configured your portal settings under Settings > Portal (the changelog is published on your public portal).
  • Optionally, set up your supported languages under Settings > Locales if you plan to publish multi-language entries.

Creating a Changelog Entry

  1. Navigate to Changelog in the left sidebar of your dashboard.
  2. Click New Entry in the top-right corner.
  3. Fill in the entry details:
    • Title: A concise summary of the update. “Dark mode for the dashboard” is better than “UI Update v3.2.1.”
    • Body: Write the full release note using the rich text editor. Explain what changed, why it matters, and any action users need to take.
    • Date: Defaults to today. Backdate if you’re documenting a past release.
  4. Click Publish to make the entry live on your portal, or Save as Draft to continue editing later.

Drafts are visible only to your team. Published entries appear immediately on your public portal and in the widget’s Changelog block (if enabled in the App Builder).

Using Labels to Categorize Entries

Labels help users scan your changelog quickly and find what’s relevant to them:

  • New: For entirely new features or capabilities.
  • Improvement: For enhancements to existing features.
  • Fix: For bug fixes and resolved issues.

To assign labels:

  1. Open a changelog entry (new or existing).
  2. In the sidebar panel, click Labels and select one or more labels.
  3. Labels appear as colored badges next to the entry title on the portal.

You can create custom labels under Changelog > Labels if the defaults don’t fit your workflow. For example, you might add “Beta,” “Security,” or “Breaking Change.”

Writing Multi-Language Entries

If your product serves users across different regions, Heedback lets you publish changelog entries in multiple languages:

  1. Open a changelog entry and look for the locale tabs at the top of the editor.
  2. Each tab represents one of your organization’s supported locales. Write the title and body in each language.
  3. The portal automatically serves the correct language based on the visitor’s locale preference.

You don’t need to translate every entry into every language. If a translation is missing, the portal falls back to your default locale. But for major releases, translating the announcement shows your international users they’re not an afterthought.

Managing Subscribers

Heedback’s changelog supports email subscribers — users who want to be notified when you publish something new:

  1. Navigate to Changelog > Subscribers to view your subscriber list.
  2. Users can subscribe through the public portal or the widget’s Changelog block.
  3. When you publish a new entry, subscribers are notified via email automatically.

You can also manually add subscribers by email address, which is useful for onboarding beta testers or key accounts who want early access to release notes.

Connecting Changelog to Feature Boards

One powerful workflow is linking changelog entries to feature board posts:

  1. When creating or editing a changelog entry, use the Linked Posts option to connect it to one or more feature board posts.
  2. Users who voted on those posts will see that their request was shipped — closing the feedback loop.
  3. On the portal, linked posts show a “Shipped” status, reinforcing that you listen to user feedback.

This connection transforms your changelog from a broadcast channel into a two-way conversation with your users.

Tips and Best Practices

  • Publish consistently. Weekly or biweekly cadence is ideal. Users lose interest in changelogs that update once a quarter, and daily updates create noise.
  • Write for users, not developers. “Improved API response caching” means nothing to most customers. “Dashboard loads 2x faster” does.
  • Include visuals. A screenshot or short GIF of a new feature makes the entry more engaging and reduces confusion.
  • Celebrate fixes too. Users appreciate knowing that a bug they reported is resolved. It builds trust faster than new features alone.
  • Use drafts for team review. Write the entry, save as draft, share the link with your team for feedback, then publish once everyone’s aligned.
  • Feature Boards: Link shipped features to changelog entries and close the loop with voters.
  • Public Roadmap: Show users what’s coming next — the changelog shows what’s already shipped.
  • Customer Portal: The changelog lives on your portal, alongside your knowledge base and feedback boards.
  • Widget: Enable the Changelog block in the App Builder to surface updates directly inside your product.