Create a Standard, Normal or Emergency Change

Create a Change for a planned modification to a service or supporting technology. Select the type that matches the work and prepare enough detail for reviewers and implementers to understand both execution and recovery.

Before you start

Know the intended outcome, affected service, proposed dates, risk, implementation steps and backout approach. In CSM Full, identify technical targets where supported. Use the authorized ExpertHub interface rather than treating Change creation as a general ServiceHub request.

Steps

1. Sign in to ExpertHub, open Changes and choose the action to create a Change.
2. Enter a concise title/description explaining the intended modification and expected outcome.
3. Select the Service and, where applicable, Service Offering. Add associated technical targets where your operating view and interface permit.
4. Choose Standard, Normal or Emergency and set the risk level.
5. Enter planned start and planned end, with the end later than the start.
6. Complete the implementation plan with execution steps, and the backout plan with the route back to the previous working state.
7. For an Emergency Change, provide the required justification, precise implementation scope, rollback and validation plans, and an open incident from the affected Service (or eligible monitoring/security evidence for an imminent threat). Select an assignment group.
8. Save. If scheduling checks reject the window, adjust the dates or resolve the service/policy selection and try again.
9. Review the generated CHG reference, initial ticket status and separate approval status.

Expected result

The Change has a unique reference and a validated planned interval. Its initial ticket status comes from your organisation's Change status configuration; its approval state comes from the selected Change type.

Choose the Change type

• Standard: select an APPROVED Standard Change Model from the catalog. The prescribed service scope, plans and optional task blueprints are validated; the created Change is pre-approved only after model and schedule validation.
• Normal: planned work requiring review. The Change starts Pending and must receive the required number of eligible approval votes.
• Emergency: urgent work tied to an active serious incident, imminent service failure or security threat. The Change starts Pending and requires independent delegated emergency authorization or an explicitly recorded break-glass exception.

Risk supports review and prioritization. It does not count as an approval vote. The required approval threshold is determined when the Change is created; later policy changes do not automatically alter that existing Change.

Plans that support execution

Use the implementation plan to explain what will change and how the team will verify the result. Use the backout plan to explain how to restore the previous state if implementation fails. Keep dates and scope consistent with the chosen Service, Offering and applicable CI restrictions.

Important behaviour

Pre-approved does not mean exempt from scheduling rules. Standard and Normal Changes cannot bypass a blocking blackout. Emergency authorization or break glass may explicitly accept a blackout exception for the recorded scope, but neither bypasses REQUIRED maintenance windows. Justification alone does not authorize execution. Backend validation can reject creation even if a window was selectable in the interface.

Governed Standard Change Models

Use **ExpertHub → Changes → Standard Change Catalog** to manage repeatable Standard models. A Change Manager or administrator defines a DRAFT model with implementation and backout plans, optional Service/Offering/team/risk scope and up to 100 ordered CTASK templates. Only an explicitly APPROVED model is selectable for a new Standard Change; RETIRED models cannot be used for new work. Model-generated CTASKs are numbered automatically and remain traceable to the model. Individual Standard Changes cannot switch type or model later.

Emergency authorization is separate from operational status

An Emergency Change starts **Pending**. A delegated, independent emergency manager authorizes LOW/MEDIUM risk; HIGH risk also needs a distinct delegated primary/secondary Service Owner. Requesters and implementers cannot approve their own execution. The **Handling → Status** control does not authorize a Pending Change. A rejected decision blocks authorization. A qualified manager with separate break-glass permission may instead record an immediate two-hour, non-renewable execution exception; approval remains Pending. Closure requires documented outcome and independent emergency review.

Related guides