Administrator setup

Who this is for: a Jira project administrator — somebody with the Administer projects permission on the project. How long: about two minutes. Before you start: Concessa must already be installed on the site from the Atlassian Marketplace. That is a one-off job for whoever administers your Atlassian site; each project is then set up separately, by whoever administers it.

There is nothing to provision — no database, no keys, no network access to open.

Where to go

Project settings → Concessa.

You need Administer projects on this project to reach that page at all; Jira gates the route itself, before Concessa ever renders anything.

Step 1 — Decide who can use Concessa here

Under Who can use Concessa here, pick the Jira project role or roles whose members should be Concessa agents, and choose Save agent roles. You can pick more than one — useful when, say, change managers and release managers are separate roles in Jira and both need access.

Everyone in any of those roles can record changes, request approvals and answer them — whether they are in a role directly or through a group. Membership stays in Jira, so removing somebody from the project removes their access here in the same instant. Concessa never keeps its own list of people.

Choosing the roles again replaces the whole list, so it is also how you take a role back off it. Until you bind at least one role, only project administrators can use the app here. The page warns you plainly:

A role containing a broad group grants broadly. A project role that contains jira-servicedesk-users, for example, makes every agent on the site a Concessa agent here. That may be exactly what you want; check before you assume it is not — and check it for each role you bind, since access is the sum of all of them.

Step 2 — Decide which issue types are change records

Under Change issue types, tick the issue types that count as changes in this project, then choose Save issue types. An agent cannot start a change record on any other type.

• On a JSM IT service management project, the template already ships a Change work type — Normal change and Emergency change are request types on it. Types whose name contains “change” are pre-ticked for you as a suggestion. Nothing is stored until you press save.

• On a company-managed Jira project with no such type, create one in Jira first (Project settings → Issue types), then come back and tick it. Concessa does not create it for you: doing so would mean the app holding site-configuration rights in every customer’s Jira to solve a per-project filtering problem (ADR-027).

• More than one type is fine. Sites that keep Standard change and Emergency change as separate types can tick all of them — but read the next bullet before you tick a standard-change type.

• Standard changes are a deliberate choice, not a default. Concessa has no Standard change type of its own (guide 2): in ITIL a standard change is genuinely pre-authorised, and that authority comes from a documented delivery model, demonstrated repeatability and a risk assessment done once and in advance — work your project does, not a value someone picks on a form. If you have done that work and keep those changes on their own Jira issue type, you decide here what happens to them:

  • Leave it unticked and they run under their delivery model with no per-change approval, which is what pre-authorised means. Concessa never asks for one — and keeps no record of them, so they will not appear in an export or the audit trail.
  • Tick it and they are governed like any other change: every approval in before the change can be approved, no shortcut. Choose this when you want the evidence more than you want the exemption.

  The choice is per project, so different projects on the same site can answer differently.

• Sub-tasks are never offered. A change record belongs on the work being changed, not on a fragment of it.

Newer Jira screens call these work types. Same thing.

If you skip this step

Concessa accepts a change record on any issue type in the project. That is the deliberate default, so that installing or upgrading the app cannot strand a project mid-flight — but it is not a good place to stop. The audit trail is append-only and has no delete path, so a change record opened by mistake on a Story is permanent evidence of an event that never happened.

If you narrow the scope later

Records that already exist stay open and fully editable, whatever their issue type, so nothing in flight is stranded with no way to close it. Only new records are refused. The audit entry for the scope change names the open records the narrowing affected — up to fifty of them, with an exact count — so “why is there an open change record on a Task?” has an answer in the trail rather than in somebody’s memory.

Step 3 — Optional: declare your freeze windows

Under Freeze windows, add any period in which changes should not ship. See guide 5 for what a freeze window does and how an override works.

If your site also uses Jira Service Management’s change calendar, its freeze and maintenance windows are separate from these and Concessa cannot read them. Declaring a freeze in one place does not declare it in the other.

Step 4 — Optional: set the CAB schedule and standing agenda

If your board meets on a regular cadence, under CAB schedule set how often it meets — weekly, fortnightly, or a particular weekday of the month — a start time, a duration, a time zone and a repeat-from date. Concessa then creates the board’s meetings for you, up to a rolling horizon, so nobody has to type a meeting’s date into a calendar by hand. A plain-English description of the rule updates as you edit it, before you save — “Every second Tuesday at 14:00 (Europe/London), 60 minutes” — so you can check it reads the way you mean it to.

Horizon (weeks) is how far ahead meetings are created, between 2 and 26. Eight is the default. Raising it creates the meetings in between immediately; lowering it leaves meetings that already exist alone, because they may already have attendees, an agenda or attached changes.

Remove schedule stops new meetings being created. Meetings that already exist stay on the workbench, with everything recorded against them intact — removing the rule is not a way to delete a board’s history.

Under Standing agenda, list the items every new meeting should start with. Changing this template never alters a meeting that already exists; it only shapes the ones created after you save it.

Neither block is required. Skip them and the CAB workbench (guide 7) opens on an empty meetings section — explaining that an administrator sets the cadence when you are ready to — above the change agenda, which works regardless.

What a configured project looks like

The lozenge beside the heading is the audit chain’s verdict, recomputed from the first entry every time the page loads. It should read Project chain verified. If it ever reads Project chain BROKEN, treat it as an incident — see guide 8.

Check it worked

1. Open an issue of a type you nominated. The Concessa panel offers to record change details.
2. Open an issue of a type you did not nominate. The panel says the type is not governed here, and offers no form.
3. Ask an agent in one of the bound roles to open the panel. They should see the same thing you do, minus the settings page.

One thing that will surprise you

The Concessa panel still appears on every issue. It cannot be hidden per project: Jira evaluates an app’s display conditions from fixed values in the app’s manifest, and those cannot read a per-project setting. What changes is what the panel says when somebody opens it on an issue you did not nominate.

What this guide does not cover

Deploying or upgrading the app (../runbooks/deploy.md), and anything that happens after something has gone wrong (../runbooks/incident.md). Running a CAB meeting once the schedule exists — that is guide 7. The terse operational version of this guide is ../runbooks/onboarding.md.