Jira Automation: Flag Tickets Added After the Release Freeze Date

[#1]

Your freeze date isn't a field in Jira.
Here's a Jira Automation flow that enforces it anyway.

I've just published an edition of my newsletter Holy Ship - Release with Jira, covering three Jira automations that protect a release.

As five release managers commented already requested I published the flows, here's the freeze date rule: a Jira Automation built on the Fix versions field, which flags tickets sneaking into a Fix version after scope was supposed to be locked.

Here's the full configuration with the smart values that make it work:

The problem

Every release has a moment where scope should stop growing. A cutoff. A freeze.

In practice, tickets keep getting added after that moment. Quietly. Without review. Without anyone flagging the risk.

Nobody is being malicious. There is just nothing in Jira watching for it.

You find out on release day. The scope list is longer than the one you signed off on, and you have no idea when it changed, or who changed it.

Why Jira doesn't catch this on its own

A Fix version has a Start date and a Release date. It does not have a freeze date.

So the freeze lives in a Confluence page, a calendar invite, or someone's head. Automation can't read any of those.

Before you can automate the freeze, you have to give Jira a freeze date it can actually read.

Three ways to give Jira a freeze date

Approach	How it works	Trade-off
Release date minus N days	"minusBusinessDays" smart value (see below)	Zero setup, but assumes every release uses the same freeze window
Encode it in the version description	Put a marker like FREEZE:2026-07-20 in the version description, parse it with a smart value	Flexible per release, more fragile to maintain
Store release dates as real data	Freeze, code cut, and deployment dates as first-class fields on a release timeline	Needs a tool that models a release as more than a version name

Start with the first one. Ship the simple rule, then upgrade it if your freeze window genuinely varies release to release.

Building the Jira Automation

Trigger: Field value changed

Note: restrict to values added, not removed or edited, so the rule doesn't fire on cleanup.

Condition 1: Work item fields condition

Condition 2: {{smart values}} condition

First value

{{issue.fixVersions.releaseDate}}

Condition 3: {{smart values}} condition

First value

{{now}}

Second value

{{issue.fixVersions.releaseDate.minusBusinessDays(5)}}

Action 1: Edit work item

Action 2: Comment on work item

Comment

This ticket was added to {{issue.fixVersions.name}} after the freeze date ({{issue.fixVersions.releaseDate.minusBusinessDays(5)}}). Please confirm this addition is intentional.

Action 3: Send customized email

Email name

Freeze violation notification

Recipient(s)

{{issue.project.lead.emailAddress}}

Subject

Freeze violation: {{issue.key}} added to {{issue.fixVersions.name}}

Content

{{issue.key}} was added to {{issue.fixVersions.name}} after the freeze date ({{issue.fixVersions.releaseDate.minusBusinessDays(5)}}).

Reporter: {{issue.reporter.displayName}}

Summary: {{issue.summary}}

Notes

• No release date on the version → the compare condition resolves to false, silently. The "release date is not Empty" check above prevents this.
• Email can fail even with a valid smart value → {{issue.project.lead.emailAddress}} resolves empty if that person's email is hidden in their profile visibility settings. Not a permissions issue, a recipient-resolution one.
• Bulk edits can fire the rule many times at once. Decide if that's signal or noise.
• minusBusinessDaysvs minusDays: one skips weekends, one doesn't.

Using the label: save this as a filter on your release dashboard for go/no-go review:

fixVersion = "X" AND labels = added-after-freeze

Optional improvements

The rule works as built. These are extras worth considering once it's running:

• Notify even when the release date is missing. By default, a Fix version with no release date makes the rule go silent: no label, no comment, no error. Wrap the compare condition in an If/else block: if the release date is set, run the freeze check as built; else, notify anyway with a specific message.
• Exclude certain issue types. A hotfix landing after freeze is often expected; a new feature isn't. Add a condition excluding Sub-task or a Hotfix issue type so the rule only flags the additions that are actually a risk.
• Auto-remove the label if the ticket leaves the Fix version. Add a second, mirrored rule triggered on Fix versions removed, that strips the added-after-freeze label. Otherwise your go/no-go filter keeps showing tickets that aren't even in scope anymore.
• Different freeze windows per release type. A major release might freeze 5 days out, a patch release 1 day out. Branch on a component, label, or issue type before the compare condition, and use a different minusBusinessDays value per branch instead of one hardcoded number.
• Switch to a weekly digest instead of per-ticket pings. For high-volume teams, a per-ticket notification becomes noise people mute. Replace the notify action with a separate scheduled rule that runs labels = added-after-freeze weekly and sends one summary instead.
• Notify through Slack or Teams instead of email. Both avoid the email visibility gotcha above entirely, since they route through the connected app, not a resolved user email address, and tend to get read faster than an inbox notification. Use the built-in Slack or Microsoft Teams action, pointed at your release channel, in place of Send email.

Pick what's relevant. None of these are required to make the rule useful.

---

This is article 1 of 3 from that newsletter edition.
Two more are coming:

• Alert when a Fix version contains open blockers
  A daily scheduled rule that runs every morning in the two weeks before release, flagging any ticket in the upcoming Fix version still marked blocked. So you don't discover it on Thursday when you're releasing Friday.
• Auto-stamp Fix versions from your CI/CD pipeline
  A developer commits with the ticket ID in the message, the pipeline creates the Fix version if it doesn't exist yet and stamps every related ticket. No reminders, no required fields, no chasing it in standup.

If you run releases in Jira, join the 2'000+ subscribers of Holy Ship to receive regular content like this one.

[lucas_morais]

It's amazing!