User guide
Freeze windows
Declare a freeze, see what it catches — backwards as well as forwards — and record an override bound to the window it excuses.
Who this is for: project administrators declare them; agents run into them.
A freeze window is a period in which changes should not ship — a trading peak, a year end, an audit. Concessa does not stop anybody doing anything in Jira; what it does is refuse to let a change be approved while it is scheduled inside one, unless an administrator has recorded an override.
These are Concessa freeze windows, and they are the only ones it can see. If your site also uses Jira Service Management’s own change calendar, the freeze and maintenance windows declared there are separate. Concessa cannot read them, and nothing reconciles the two lists: a change can be clear in one and in freeze in the other, and each product is right about its own windows. If a freeze is meant to hold in both places, declare it in both places.
Declaring a freeze window — administrators
Project settings → Concessa → Freeze windows → Add a freeze window.
| Field | Notes |
|---|---|
| Name | Required, up to 120 characters. “Year end”, “Black Friday”. |
| Starts | Required. |
| Ends | Required, and must be after the start. |
| Reason | Required. Agents see this, so write it for them. |
Times are read in your own timezone.
Declaring a window looks backwards as well as forwards. Every change already scheduled into the new window, and not already approved or rejected, is moved to Freeze conflict there and then — each one audited. A freeze announced after things were booked is still a control rather than a note, which is the whole point of doing it at declaration time rather than at approval time, when whoever is looking is in a hurry.
Removing a window does not touch any change record. The conflicts simply stop being conflicts the next time each change is looked at.
A change that was already approved
Declaring a freeze does not reopen a decision. A change that was approved before the window existed keeps its Approved status: an approval is a decision the chain has sealed, and a freeze declared afterwards is somebody else’s later act over every change in the project, not a fact about that one.
It is still flagged. The panel, the change agenda and the calendar all work out the freeze state from the windows as they are now, so the change shows In freeze wherever it appears and the board can see it. What the app will not do is move it back to awaiting a decision, and no override is needed for it to proceed — so if the freeze is meant to stop it, somebody has to say so.
Hitting a freeze — agents
If you schedule a change into a freeze window, it moves to Freeze conflict and the panel tells you which window and why:
You have two ways out.
Reschedule. Edit the change details and move the planned window outside the freeze. The conflict clears and the change returns to Draft — send it for review again.
Get an override. Only a project administrator can record one, and only against the window the change actually conflicts with. If you are not an administrator the panel says so rather than showing you a button that would fail.
Recording an override — administrators
In the panel, on a change in freeze conflict, write why in the box and choose Record override. The reason is required, it is stored, and it is in the audit trail and the evidence export permanently.
The change moves to In review, and can then be approved normally.
An override is bound to one window
This is the part worth understanding. An override is not a flag saying “this change may breach freezes”; it names the specific window it excuses.
Move the change into a different freeze window and the conflict is raised again, because nobody has decided anything about that window. Move it somewhere that conflicts with nothing and the override is retired — there is no longer a breach for it to excuse.
What it does survive is a reschedule within the same window. Shifting a change from 22 December to 28 December, both inside “Year end”, keeps the override: it was permission to breach that freeze, and that is still the freeze being breached.
The earlier hosted version of this product carried a plain “overridden” flag, and an override granted for last December went on excusing conflicts with windows created months later. Binding it to the window is the fix.
What can go wrong
| Message | What it means |
|---|---|
| “This change is scheduled inside the “name” freeze window. A project administrator must record an override first.” | You tried to approve through a freeze. |
| “That freeze window is not the one this change conflicts with.” | The change moved. Reload the panel and look at the window it names now. |
| “Only a project administrator can override a freeze window.” | Ask whoever administers the project. |
| “The freeze window must end after it starts.” | Check the dates. |
| “Record why this freeze window exists.” | The reason is required — agents read it. |
| “That freeze window no longer exists.” | Somebody removed it while you had the page open. |
Two things to know
Jira’s own dates are not Concessa’s planned window. If your site uses Jira Service Management’s change management, its four date fields drive its calendar and ours drives ours. The panel shows you when the two disagree and offers to copy Jira’s across (guide 2) — but only you can take that offer, because moving the window can retire an override or withdraw an approval.
A change with no planned start can never conflict. You cannot breach a freeze you have not scheduled into. If you want the freeze to catch a change, the change needs a planned start.
Only the first matching window is named. If a change overlaps two freeze windows, the panel names one of them. Clearing that one may reveal the next.
What this guide does not cover
The statuses themselves (guide 4), and where to see freeze days across a month (guide 6).