Key Highlights
ServiceOps Change Management fixes the root cause with three distinct change types, each with its own lifecycle, so oversight always matches risk: Standard moves fast, Normal gets CAB review, Emergency gets ECAB-expedited restoration.
The right amount of process for the risk at hand, not one queue that punishes routine work and rushes critical work.
Standard: low-risk, pre-approved changes (memory upgrade, new user account).
Minimal planning, with a quick verification close.
Normal: non-standard changes (server upgrade, software deployment).
Requires a detailed RFC, CAB authorization, and a governed Review stage before close.
Emergency: critical fixes (active vulnerability, major incident).
Expedited through ECAB or one approver, then reviewed once service is restored and the change closes.
Authorization that brings the right stakeholders to each decision, eliminating meetings changes do not need
A Change Advisory Board of IT, security, and business stakeholders assesses and authorizes Normal changes.
An Emergency CAB, or one authorized individual, grants expedited approval.
Urgent changes are no longer blocked by a weekly cadence.
Change Risk drives the conversation, with predefined risk levels plus custom levels for any environment.
Impact analysis captures the services, assets, and CIs a change affects before it is approved.
Each RFC, approval, and decision is captured as an immutable audit trail for review and compliance.
Configurable task columns render in Change print output.
Process discipline enforced by the system, not left to whoever happens to be working the ticket.
Submitted rules require Assignee, Change Manager, Location, and Category before a change is accepted.
Planning rules require a documented Rollout Plan, Change Schedule, impact assessment, and Backout Plan.
Rollout Plan Dates can be configured as a mandatory field in Planning rules, so the schedule is committed before work proceeds.
Implementation rules require a Change Implementor and can block execution until all linked tasks are closed.
Review rules require a Change Reviewer and at least one worklog before a change can be closed.
Custom rule enforcement in merge and bulk operations too, with a side panel to capture a mandatory note and clear messages identifying the affected requests.
Status that moves itself when conditions are met, in the environments a change actually travels through.
Change Models transition a request from one state to the next when defined conditions match.
Automatic status propagation through linked tickets, tasks, and workflows.
Default Dev → Test → Production target environments mirror standard promotion practice, with custom environments as needed.
Change Categories (General, Software, Hardware, Network, IT Administration) keep large change queues filterable.
A visual Change Calendar shows scheduled changes for planning and coordination.
Intelligence
One change process works fine at small scale, but as volume grows it breaks in two directions. Low-risk standard changes drag through full CAB review that adds delay and no value, while a critical patch for an exposed web server waits for the next CAB slot when it should reach an ECAB in minutes.
ServiceOps Change Management separates change by type, each with its own lifecycle, approval path, and custom rules. Routine changes flow through pre-approved templates while high-risk changes get the scrutiny they deserve.
How It Works
Classify changes as Standard, Normal, or Emergency, each bound to a specific transition model.
Enforce Assignee, Change Manager, and Location rules before accepting RFC submissions.
Assess Change Risk, routing Normal changes to CAB and Emergency changes to ECAB approvers.
Environment promotion:Promote changes through Dev → Test → Production with automatic status transitions.
Require assigned implementors, closed tasks, and reviewer worklogs prior to closure.
Require Rollout Plan, schedule, Backout Plan, and impact assessment before work proceeds.
Role-Based Value
Oversight matches risk rather than applying one queue to everything, so routine work is not punished and critical work is not rushed.
Oversight matches risk rather than applying one queue to everything, so routine work is not punished and critical work is not rushed.
Completeness stops depending on individual discipline, because custom rules gate Submitted, Planning, Implementation, and Review.
Completeness stops depending on individual discipline, because custom rules gate Submitted, Planning, Implementation, and Review.
Pre-approved standard lifecycles clear routine work, no board review required, reducing the unauthorized changes that follow a slow process.
Pre-approved standard lifecycles clear routine work, no board review required, reducing the unauthorized changes that follow a slow process.
Impact, rollout, and backout plans are enforced before any Normal or Emergency change executes, so the plan exists before the work starts.
Impact, rollout, and backout plans are enforced before any Normal or Emergency change executes, so the plan exists before the work starts.
From Visibility to Control
Fewer change-related incidents: impact, rollout, and backout plans are enforced before any Normal or Emergency change executes.
Faster standard changes: pre-approved lifecycles clear routine work with no board review needed, reducing the unauthorized changes that follow a slow process.
Audit-ready approvals: each RFC, CAB/ECAB decision, status change, and worklog captured as an immutable record for compliance.
Consistent execution: custom rules gate Submitted, Planning, Implementation, and Review, so completeness never depends on individual discipline.
Explore More