Plan windows and approve a Change

Planning determines when work may run. Approval determines whether implementation has been authorized. Both checks matter: an approval decision does not remove applicable scheduling restrictions.

Before you start

Review the Change type, Service/Offering, risk, planned interval, implementation plan and backout plan. In CSM Full with Configuration Management enabled, review relevant target CIs as well. Eligible approver rights are checked separately from ordinary editing or implementation-team membership.

Steps

1. Check the proposed start and end against tenant-wide and relevant Service-scoped blackout windows.
2. Confirm that the entire planned interval fits every applicable REQUIRED maintenance window. Service Offering, Service, tenant and applicable CI policies may all impose requirements.
3. Resolve a conflict by changing dates or correcting the selected scope. Contact the configuration administrator if the policy itself needs review.
4. For a Normal Change with approval status Pending, open the approval action available to your eligible approver role.
5. Review scope, risk, execution/backout plans and schedule, then submit an approval or rejection with a meaningful comment where needed.
6. Check the resulting approval status before attempting ticket-status or task progression.

Expected result

The planned interval meets applicable requirements and the approval status reflects eligible decisions. A Normal Change becomes Approved after the configured number of approval votes; a single Rejected vote rejects the whole Change, even if others approved.

Blackout exceptions

Standard and Normal Changes cannot be saved with a blocking blackout conflict. An authorized Emergency decision or break-glass activation may explicitly accept a blackout exception for the recorded scope. Justification alone is insufficient, and acceptance is audited.

REQUIRED maintenance windows

Every applicable REQUIRED schedule must allow the whole planned interval. Meeting one requirement does not satisfy another that also applies. In CSM Full, a target CI's maintenance-policy override can add requirements alongside Service Offering, Service and tenant policies.

Even an Emergency Change cannot bypass a REQUIRED maintenance-policy conflict. Adjust the interval or have the relevant configuration reviewed.

Approval and lifecycle guards

The required approval threshold is fixed at creation; subsequent policy changes do not automatically recalculate it for an existing Change. A Standard Change created from an approved model starts Approved after validation. Normal and Emergency Changes start Pending, using different independent authorization rules.

Normal Changes cannot advance ticket status while Pending or Rejected; Emergency Changes use a separate authorization or break-glass execution gate, with independent review before closure. Approval makes normal permitted lifecycle progression available. Only administrators or Change Managers can change a terminal ticket status again, and approval guards continue to apply.

Important behaviour

Being able to edit the Change or work on its tasks does not grant approval authority. Administrator rights do not bypass pending-approval/status restrictions or REQUIRED maintenance policies. Approval status and ticket status are separate fields and should always be reviewed separately.

Delegated Emergency decisions and blackout acceptance

An Emergency authorization is not the **Handling → Status** dropdown. The Decision section is available only to eligible independent users with **Emergency authority** delegation. An eligible delegated manager may authorize LOW/MEDIUM risk; HIGH risk additionally requires an independent, distinct delegated primary/secondary Service Owner. An approval rationale is required. A rejected vote blocks authorization. If the scope overlaps a blackout, explicitly select **Accept blackout exception** and record the rationale; otherwise leave the exception unchecked. This never overrides a REQUIRED maintenance window.

Admins grant **Emergency authority** and separately **May activate break glass** in People / Users when editing an existing user. A manager with both delegations can activate a two-hour, non-renewable break-glass exception by recording why action cannot wait and its exact scope. Approval remains Pending and no retrospective vote is permitted. Completion and independent review are still mandatory.

Related guides