Release notes & changelog
This page explains how to read Helpin product updates and where to confirm current behavior. It does not list a release unless that release has been verified and published.
What belongs in release notes
A release note should describe a customer-visible change, including:
New capabilities.
Meaningful improvements to an existing workflow.
Changes to access, limits, configuration, or billing.
Important fixes that affect how customers use the product.
Deprecations, migrations, or actions customers must take.
Internal refactors, test-only changes, and implementation details should not be published unless they affect customers.
How entries should be written
Each entry should include:
The release date or version.
A concise description of the customer-visible change.
Who the change affects.
Any action the customer must take.
Links to the relevant help article when setup or behavior needs more explanation.
Limitations, rollout conditions, plan requirements, or edition differences.
Use confirmed product language. Do not describe planned work as released.
Rollouts and availability
A feature can depend on plan, edition, workspace configuration, module access, integration setup, or staged rollout. Release notes should state those conditions explicitly.
If a feature is visible only to selected workspaces or is still in preview, label it accordingly.
Verify current behavior
For the most accurate instructions, use the task-specific Help Center article and the current in-product settings. Release notes explain what changed, but they are not a replacement for maintained product documentation.
Useful starting points include:
Current publication status
No dated customer release entries have been added to this article yet. This statement is intentional. It prevents unverified repository activity or planned roadmap work from being presented as a shipped release.
When the first verified entry is ready, add it above this section and keep entries in reverse chronological order.
Was this article helpful?