Releases

A release groups the entries that ship together. It has a start and end date, a status, and the sign-offs and checks that tell you whether it is ready to ship.

You plan releases in the Plan workspace. With a project open, choose Plan in the left navigation.

The Plan workspace

The Plan workspace has five views. Use the switcher under the page title.

View	What it shows
Plan	An outline of the project's releases, epics, milestones and tasks against time.
List	One row per release, with its status, dates, item count, progress, approval chips and a readiness chip.
Board	The Backlog beside each release. Drag an entry from the backlog into a release, between releases, or back to the backlog.
Milestones	The project's milestones and what each one contains.
Epics	The project's epics and their progress.

Show filters the releases to Active, All or Shipped & archived.

Clients and people with the User role can open the Plan and List views but can't change anything there. The Board is not available to them.

The List view, with each release's status, progress, approval chips and readiness chip.

Creating a release

Admins and managers create releases.

1. In the Plan workspace, click New and choose Release.
2. In Schedule Release, fill in:
   • Use Template (Optional): shown when your workspace has release templates. Choosing one sets the release type and, once you pick a start date, the end date.
   • Release Name: for example v1.2.0 or Q1 Update.
   • Release Type: Major, Minor or Hotfix.
   • Risk Level: Low, Standard or High.
   • Team (Optional): one of the project's teams.
   • Approval Flow: the approval template that signs this release off. The project's default template is selected for you. See Approvals.
   • Start Date and End Date.
3. Click Create Release.

A new release starts in Planning. If the approval template has stages, Align creates the release's approval chain straight away.

New also creates an Epic or a Milestone. Admins, managers, tech leads and product owners can do this.

Adding entries to a release

• Board: drag an entry card from the Backlog into a release. Entries that are pending approval or were rejected can't be moved.
• Entry page: set the entry's Release field. No release returns it to the backlog.

Editing a release

Admins and managers edit a release from its menu in the List view: choose Edit Release. The dialog has three tabs.

Tab	Fields
General	Release Name, Status, Type, Team (Optional), Start Date, End Date, Version Tag (Optional) and Release Dependencies. It also names the approval workflow the release is using.
Rollout	Rollout Percentage, Risk Level and Target Audience.
Retrospective	Retrospective Notes.

Statuses

You can choose these statuses in Edit Release:

Status	Meaning
Planning	Scope is still being decided.
In Progress	Work is under way.
Testing	The release is in QA or user acceptance testing.
Released	The release has shipped.
Archived	Kept for the record.

A release can also show Active or Completed, which the dialog doesn't offer. Align treats Completed, Released and Archived as shipped.

Changing a release's status does not change the status of its entries.

Release checks

Moving a release to Released or Completed first meets the project's release checks. They look for what is still open on the release:

Open item	What it means
Release approval	The release's approval workflow is pending or was rejected. A release that has no approval of its own is under the project's default release approval workflow.
Approval gates	An approval gate on the release is pending or rejected.
Client approval	An entry in the release is still waiting for the client to approve it, or the client rejected it.
Cost sign-off	An entry's cost, or the release's committed cost, was submitted for approval and the approval isn't finished. A cost that was never submitted doesn't count.

These are the items that can block. A project that uses none of these features never has anything blocking. Unfinished dependencies between entries, a release this one depends on that hasn't shipped, open checklist items and open bugs are always shown as warnings and never block.

SonarQube quality gate. When the project is bound to a SonarQube project, the checks also show its quality gate. A failing gate is a warning: "Quality gate failing in project: conditions". It blocks only when the project turns on SonarQube quality gate can block (beside Release checks in the project's Settings) and the release checks are set to Block; an admin's override then works as for any other blocking item. An analysis that is out of date or missing is a softer warning ("No SonarQube analysis since date") and never blocks. The gate is read from the main branch's latest analysis. When that analysis's version matches the release's Version the message says so; otherwise it names the analysis it used. Only the workspace's staff see the gate's details: anyone else who meets a blocking gate is told only that a check the workspace's staff can see is failing.

What happens depends on the project's setting:

Setting	When something blocking is open
Block	The release can't be marked shipped. The dialog lists what is blocking and what to finish. An admin of the workspace can override it by writing a reason and choosing Override and mark shipped; the override is recorded in the audit log with the reason and what was open.
Warn	The dialog lists what is open and asks you to confirm. Mark shipped goes ahead.
Off	Nothing is checked.

A project with no setting uses its default: Block for a project owned by a client, Warn for an internal project (one owned by an admin or manager). Admins and managers change it in Settings → Projects → the project → Settings → Release checks. The readiness strip shows the setting in force.

Only the move into a shipped status is checked. Editing a release that is already Released or Completed is not checked again. The same checks apply when a release is created already shipped, and when it is changed through the API, the MCP server or Max.

Importing releases. The import wizard meets the same checks. In a project in Block mode, a release row imported as Released or Completed is refused while anything is blocking it; for a new release that is usually the project's release approval workflow, which starts pending. When the person importing is an admin of the workspace (or a platform operator), the wizard stops at the first such row and asks once for a written reason. That reason overrides the checks for every release in the import, and each release it overrides is recorded in the audit log with it. Without a reason, those rows are not imported. Anyone else is told to ask an admin to run the import, or to switch the project's release checks to Warn. Projects in Warn or Off import as before.

Dependencies and date cascades

Under Release Dependencies, Depends On makes this release follow another release in the same project. When the parent release's dates move, this release moves with it:

• A delay to the parent always delays this release.
• An earlier finish moves this release earlier only if Auto-advance when parent finishes early is ticked.

If the project requires approval for cascading date changes (Approve cascading date changes in the project's Cost & billing setup step, or Require approval for cascading date changes in Settings → Projects → the project → Settings), the move waits for an admin or manager to approve it, and it is listed in My Approvals.

Deleting a release

Choose Delete Release from the release's menu, and choose where its entries go: Move to backlog (no release) or another release in the same project. The release's approval gates and quality checklists are deleted with it.

Approval gates and quality checklists

A release can carry its own checks, separate from the approval chain that comes from the project's approval templates. Open them from the release's menu with Approvals & Checklists. The Release Controls dialog has two tabs.

Approval Gates. Add a named gate, such as "QA Sign-off". A gate is Pending until someone approves or rejects it. Admins and managers add and remove gates. A gate is decided by an admin or by someone with the gate's required role (manager by default). The tab shows how many gates are approved.

Quality Checklists. Add a named checklist, then add its items. Tick an item when it is done.

The release page's Approval Workflow card shows the same gates, with an Approve button for the people who can decide each one. A release with no gates shows Manager, Admin and Client review placeholders there, with the note "Approval gates need to be configured for this release".

Release readiness

In the List view, each release that hasn't shipped has a readiness chip:

Chip	Meaning
Ready to ship	Nothing is holding the release back.
N to clear	N things are holding it back.
Early	Nothing is holding it back, but the release is still in Planning with less than half its entries delivered.

Click the chip to open the readiness strip:

Signal	What it shows
Approvals	Approval gates approved, out of the total. A rejected or pending gate holds the release back.
Checklist	Checklist items done, out of the total. Open items hold the release back.
Pipeline	Entries that have reached test, staging and production, when the project tracks deployment stages.
Crash-free	The crash-free session rate from Sentry, when Sentry is connected.
Forecast	The date the release is likely to land, based on the team's recent throughput.
Budget risk	The chance the release goes over its committed cost. Shown only to people who can see committed costs.
Waiting on	The item holding up the most work in the release, from entry dependencies.
Blockers	Open bug reports in the release. Any open bug holds the release back.
Release checks	The project's release checks setting, and whether it is the default.
Quality gate	The SonarQube quality gate the release meets, when the project is bound to SonarQube, and whether it would block shipping. Staff only.

To clear lists what still holds the release back. A signal that isn't set up shows a dash.

The release page

Open a release's page from its name in the List view. It shows:

• Release Cost Range: the low, medium and high estimates for the release's entries, for people who can see costs. See Cost Management.
• Release commitment: the cost committed for the release as a whole, beside the sum of its entries' commitments, with its approval status. See A release's committed cost.
• Included Work Entries: the entries in the release.
• Quality gate: when the project is bound to SonarQube, the gate the release meets, which analysis it was read from, and whether it warns or blocks (see Release checks). Staff only.
• Approval Workflow: the release's approval gates (see above).
• Release Evidence: the evidence package (see below).
• Release Advisor: suggestions about which entries to include, defer or decide on. Admins, managers, tech leads and product owners see the full scores; developers, testers and DevOps engineers see a readiness view.
• AI Release Notes: generates a client-ready summary of the release's entries.

When time tracking is on, the header also shows the time logged against the release's entries. See Time Tracking.

Release evidence

The Release Evidence card on the release page assembles an evidence package. Admins and managers can open it and download it as JSON. It contains:

• The approval chain, with who approved each stage and when.
• The release's quality checklists and how many items are done.
• For each entry, its linked commits with their CI result, and its merged pull requests.
• A Completeness score from 0 to 100%, and a status.

The score is the average of three parts: the share of entries with a linked commit, the share of entries with a passing CI result, and whether every checklist is complete. The package is Complete once the release is Completed or Released, and Incomplete before that.

If your workspace has an evidence signing key, the download carries a signature. The package is also available through the Release Evidence API.

Release notes

The Release notes button on each row of the List view shows notes generated from the release's entries.

When a release is released

When a release is set to Released and the project creates invoices automatically, Align generates a draft invoice for the release. If the project also bills from logged time, approved hours that haven't been invoiced yet are added to it. See Cost Management and Time Tracking.

Release templates and blackout periods

Admins manage both in Settings → Plan Settings.

Release templates

Release Templates give a release a type and a default length. They appear under Use Template (Optional) when you create a release.

• Click Add Template, fill in Template Name, Description, Release Type and Default Duration (days), and click Create Template.
• A workspace with no templates can click Initialize Defaults to add three: Major Release (28 days), Minor Release (14 days) and Hotfix (3 days).

A template's Requires Approval switch is shown in the Approval column. It does not decide which approval chain a release gets: the project's approval templates do. See Approvals.

Blackout periods

Blackout Periods mark dates when releases should be avoided, such as a holiday code freeze. Click Add Blackout, fill in Period Name, Reason (Optional), Start Date and End Date, and save.

Blackout periods appear on the roadmap as a Blackouts row. They are a reminder only: Align does not stop you scheduling a release inside one.

The roadmap

Portfolio → Roadmap puts every project you can see on one timeline: milestones as diamonds, releases as phase bars, and the epics inside each phase.

• Range: Quarter, Half or Year.
• Lens: Commitments leads with milestones; Delivery leads with progress.
• Expand a project's row to see its epics. Click a phase or an epic to zoom the page into it. Use the breadcrumb, or press Esc, to zoom back out.

Clients see their own projects at phase and milestone level, without the lens switch.

The portfolio roadmap, with milestone diamonds and release phase bars across projects.

Increment planning

The Increment item in a project's navigation opens increment planning boards. They are off by default. Align's platform team switches them on per workspace; until then, a board can't be created.