Change Management Lite for JSM

2.1 Installation

1. Install Change Management Lite for Jira Service Management from the Atlassian Marketplace.
2. Grant the requested permissions when prompted. The app is built on Atlassian Forge and runs entirely on Atlassian infrastructure — no external services.
3. Open Apps → Change Management Lite from the Jira navigation to reach the change calendar and its sibling pages.

2.2 Where the app lives

Global page

Under Apps → Change Management Lite. A sidebar groups the Change Calendar, the read-only Stakeholder Calendar, the CAB Workbench, and Change Analytics.

Queue pages

Inside a JSM project’s Queues section: Changes and Problems.

Issue panel

A Change Risk panel on the change issue view — risk score, conflicts, related incidents and failures.

Customer portal

A redacted Approval status panel on the request detail in the JSM help center.

Admin

Jira settings → Apps → Change Management Lite Settings — windows, services, approval flows and CABs, org defaults, governance, audit log, the deployment webhook, and data export/import.

2.3 The setup wizard

The Changes queue detects whether your project has the three change work types — Normal change, Standard change, and Emergency change. If they are missing, the queue offers Run setup wizard, which detects the work types and maps them.

Creating Jira issue types is outside the app’s zero-egress permission set, so if a work type is missing the wizard gives you the exact names to create by hand, then re-detects. It can also seed a few example changes, windows and services so you can explore the calendar before creating real requests — and remove them again at any time.

2.4 Requirements

• Jira Service Management Cloud — the app is a Forge app and supports Cloud only. It runs on the Standard plan (Premium not required).
• A JSM project for the Changes and Problems queues; the global calendar and CAB workbench span projects.
• Jira administrator or project administrator permission to run setup, manage windows and CABs, and configure org defaults.

3.1 Month and week views

Toggle between Month and Week, and move with ‹,Today and ›. Days with more chips than fit show a+N more control. A visually-hidden schedule table mirrors the grid for screen readers.

3.2 Projects and filters

Add one or more project keys to fan the calendar across projects, then filter by status or change type. Selected projects persist between visits. Freeze and maintenance windows render as banded overlays behind the change chips.

3.3 Rescheduling a change

Drag a chip to another day to reschedule it — the change’s planned start and end move, and the edit is recorded in the audit log. A keyboard alternative is available for full accessibility. You need edit permission on the underlying issue; the app writes as you, so Jira enforces your own permissions.

3.4 ICS export

Export .ics downloads the visible range as a standard iCalendar file that imports into Google Calendar, Apple Calendar or Outlook. The download is generated in your browser — nothing is served from an external URL.

4.1 Window types

Freeze window

A blackout period. Changes scheduled inside it are flagged as a freeze conflict.

Maintenance window

A planned maintenance period; whether it counts as a conflict is configurable org-wide.

Change window

A sanctioned window for changes to land.

Windows are created in admin, scoped globally or to a project, and appear as overlays on both calendars.

4.2 Recurrence

Windows can repeat (for example a weekly maintenance window) using recurrence rules. Recurrence is timezone- and DST-aware, so a window that starts at 22:00 local stays at 22:00 across the spring and autumn clock changes.

6.1 The score

Every change is scored automatically the moment it is planned. The Change Riskpanel shows a dial with a 0–100 score and a band — Low, Medium,High or Critical. Scoring is deterministic: the same inputs always produce the same score.

6.2 Factors & breakdown

The score breakdown lists each factor, its contribution and a plain-language detail:

• Change type — Normal, Standard or Emergency.
• Service tier — the most critical affected-service tier.
• Window proximity — how soon the change starts.
• Conflict pressure — conflicting changes and windows.
• Failure history — recent failed or rolled-back changes on the same services (30/60/90-day lookback).
• Lead time — how much notice the change was given.

6.3 Tuning the weights

Admins can tune each factor’s weight per scope from a risk profile. The breakdown always shows which profile scored the change, so the number is never a black box.

6.4 The four tabs

Risk summary

The score dial and factor breakdown.

Changes

Conflicting changes and windows for this change.

Incidents

Related incidents on the affected services (JQL-linked).

Failures

Deployment failures and failed/rolled-back outcomes on the affected services.

8.1 Stages & quorum

Build an approval flow as ordered stages (for example peer review → CAB → change manager). Each stage has an approver set and a quorum mode:

Any-one

One approval clears the stage.

Majority

More than half must approve.

Everyone

All listed approvers must approve.

A stage can be advisory (shows status only) or blocking (enforced — see the workflow gate). Emergency changes can use a fast path that skips stages but flags a mandatory retrospective.

8.2 CAB groups

Create reusable Change Advisory Board groups in admin and reference them from any approval stage. A person who sits on more than one CAB votes independently in each.

8.3 The CAB workbench

The CAB Workbench runs your board meetings: define recurring or one-off meetings, get an agenda auto-built from the changes awaiting the CAB stage, record decisions live (which feed the real approval engine), track attendance, download an ICS meeting invite, and distribute the decision log.

8.4 The workflow gate

An optional workflow validator blocks a transition until a blocking-mode approval flow has been approved. It is opt-in per transition and fails open — a missing flow, an advisory-only flow, or any error never bricks your workflow.

8.5 The customer portal

Customers see a redacted Approval status panel on their request in the help center: stage labels and approval counts only — never approver names or account IDs. Redaction is enforced on the server.

9.1 Problem queues & linking

The Problems queue lists problem records. Link a change to a problem with the “is caused by” relationship, and link problems to incidents, to build the causal picture.

9.2 Known-error database

The known-error database (KEDB) holds known errors with symptoms and workarounds. Search it by substring to find the workaround for a recurring issue fast; each known error opens a detail view with the workaround shown first.

9.3 Post-implementation reviews

Completed and failed changes capture a post-implementation review — outcome (successful, failed, rolled back) plus notes — which feeds the risk engine’s failure-history lookback and the risk panel’s Failures tab.

13.1 JSM Premium import

Downgrading from Premium? The migration assistant reads your existing JSM change history through the Jira API and maps it into the app’s model. It previews what would import (writing nothing), then applies on your confirmation — linking existing Jira issues by key with zero Jira writes, audited and resumable.

13.2 CSV import

Import change data from a CSV export. A stable per-row ledger means a crash or a re-run never double-creates a change — each row is imported at most once.