What this template is for
Release notes are the boundary between engineering and the rest of the world. If they’re vague, customer support is blindsided by the bug report, sales is selling features that didn’t ship, and the docs site is one release behind reality.
This template fixes that with two layers:
- Fields on the release ticket - the customer-facing summary, internal summary, breaking changes, and the full list of linked issues. The customer-facing field is the canonical source for the changelog page, the in-product banner, and the release email.
- Sub-tasks STM creates on every release ticket - changelog page draft, banner copy, email draft, support enablement, rollback confirmation. Each has an owner the moment the release ticket is opened.
When to use it
Use this template for every customer-visible release - even patch releases. The customer-facing summary may be a single sentence (“Patch 4.13.1 fixes a regression in promo code redemption”) but the discipline of writing one prevents the recurring problem of small changes shipping without anyone in support or sales noticing.
For internal-only releases (test stack upgrades, infra changes) skip this template and use a regular task or the change-request template.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Release 4.13.0 - checkout redesign + 12 fixes | Yes |
Release Version | 4.13.0 | Yes |
Release Date | 2026-05-29 | Yes |
Release Type | Major / Minor / Patch / Hotfix | Yes |
Customer-Facing Summary (custom) | Two-paragraph description in plain English, written for customers | Yes |
Internal Summary (custom) | What changed under the hood; what to watch in metrics | No |
Customer Impact (custom) | All checkout users; opt-in via feature flag for first 7 days | No |
Breaking Changes (custom) | API v1 deprecated; migration guide linked | No |
Linked Issues | Every story / bug shipped in this release | No |
Owner | @release-manager | No |
Components | checkout, billing, web | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Draft customer-facing summary - approved by Product
- Update public changelog page from the summary field
- Draft in-product release banner copy
- Draft customer email (if release warrants it)
- Brief customer support on changes and known issues
- Confirm rollback plan is documented for risky changes
- Post in #releases when shipped with link to this ticket
Common questions
What goes in a Jira release notes template?
A release identifier, the date, the customer-facing summary in plain English, the internal summary covering risk and rollback, breaking changes, the list of linked issues, and the owner. Treat the customer-facing summary as the most important field - that's what ships to changelog, in-product banners, and email.
Should release notes be a Jira issue or a separate page?
Both. The Jira issue is the single source of truth (linked to every shipped story, owner-attributed, archived). The published changelog page is generated from the customer-facing summary field. Keeping them in sync is much easier when the Jira issue is canonical.
Who owns the release notes ticket?
A named release manager, not 'engineering' or 'the team'. Releases without a single owner skip approval steps. The release manager rotates per release in most teams - but it's always one person at a time, accountable for the customer-facing summary being correct and shipped on time.
How do you automate release-notes sub-tasks in Jira?
Create an STM sub-task template containing the close-out steps (changelog page draft, in-product banner copy, email draft, support enablement) and an Executor that fires On Create Issue scoped to the release issue type. Every new release ticket gets the same checklist with the same owners.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →