Recording a change

Who this is for: an agent — a member of a project role your administrator bound. Before you start: the issue must be of a type your administrator nominated as a change issue type. If it is not, see what the panel says.

Where to go

Open the Jira issue and find the Concessa panel on it.

A change record is the Jira issue. Concessa does not create a second object somewhere else; it adds the handful of things Jira has no field for — how risky the change is, what kind it is, what it touches, when it is planned, and where it has got to. Everything else about the change stays in Jira, where it is searchable, reportable and subject to the project’s permissions.

Step 1 — Open the panel

On an issue that is not yet governed, the panel invites you to start:

Nothing has been written yet. The lozenges show what the record would start as — Draft, Medium risk, Normal — not what it is.

Step 2 — Record the details

Choose Record change details.

Editing an approved change. The panel warns you before you start: an approval covers the window it was given for. Moving the planned dates outside that window withdraws the approval, returns the change to In review and asks its approvers again (guide 3). Shortening the window inside what was approved is fine and changes nothing. Editing anything else — the summary, the risk, the impacted service — leaves the approval alone.

Times are read and shown in the timezone Jira knows you are in.

If Jira already has dates for this issue, the panel says so. Jira Service Management’s change management adds four date fields of its own — Planned start, Planned end, Actual start and Actual end — and its change calendar reads them. Concessa reads them too, and compares them with the window you are typing:

Concessa never takes those dates on its own, and never writes them back. Taking them is rescheduling, and rescheduling can retire a freeze override or withdraw an approval — so it waits for you to press the button and then Save change details, and the audit entry names you. If the two are meant to match, you are the one who decides which is right.

One thing worth knowing: once all four Jira fields are filled, Jira’s own calendar switches to the actual dates. The panel follows it and says which pair it compared.

Choose Save change details. This is the moment the change comes under governance: the first audit entry is written, and from here everything you do to the record is recorded.

The two change types

Why there is no Standard type

Concessa has no Standard change type, and that is deliberate rather than an omission.

In ITIL a standard change is genuinely pre-authorised — the authority to proceed was granted in advance, once, for a whole class of work. Earning that takes real effort inside a project: a documented delivery model or procedure, evidence the work is repeatable, a risk assessment done once and up front, and someone with the authority to delegate it deliberately doing so.

None of that is something you can assert by choosing a value from a dropdown on the form you are filling in. A self-declared exemption is the opposite of pre-authorisation: it would let the person making the change grant themselves the permission to skip its approval. So Concessa offers only the two types it can actually enforce, and leaves genuine pre-authorisation to be expressed where it belongs — in how your project is set up.

If your standard changes are real, keep them on their own Jira issue type and have your administrator decide whether Concessa governs it. Both answers are supported and the trade-off is explained in guide 1.

Step 3 — Live with the record

Once saved, the panel shows the record in full:

Reading the lozenges, left to right: the governance status, the risk, the change type, any freeze state, and the audit chain’s verdict for the whole project.

From here:

• Edit change details to change anything you recorded. Every edit is audited. Once an outcome is recorded, the details are locked — see guide 4. The change type cannot be edited once the change is approved, whether or not an outcome has been recorded yet — see below.
• Request an approval — see guide 3.
• The buttons along the bottom move the change on — see guide 4.
• Audit trail, further down the panel, is this change’s own history.

The change type is fixed at approval

An emergency change can be approved with no approvals at all — that is what “restores service now” means. Relabelling it Normal afterwards would keep an approval that a normal change could never have received, so once a change is approved, its change type cannot be changed. The panel shows it as plain text rather than a menu once you reach that point, and the resolver refuses the edit regardless of how the request arrived:

“The change type cannot change after approval, because emergency and normal changes are approved under different rules. If this one was classified wrongly, raise a new change record.”

If a change really was classified wrongly, raise a new record with the right type. The old one stays as the record of what was actually approved.

If the panel says this is not a change issue type

Your administrator has nominated which issue types are change records, and this issue is not one of them. There is no form and no button, because there is nothing you could do with them.

Two ways forward: move the work onto an issue of a governed type, or ask a project administrator to nominate this one (Project settings → Concessa). If the panel instead says No issue types are governed yet, nobody has chosen at all — that is guide 1, step 2.

If your record’s issue type stops being governed

An administrator narrowed the scope while your change was in flight. Your record is unaffected — you can still edit it, get it approved, and close it out. What you cannot do is start a new record on that issue type. Finish this one here.

What can go wrong

What this guide does not cover

Approvals (guide 3), the statuses and what moves between them (guide 4), and freeze windows (guide 5).