Change
ITIL defines Change as "the addition, modification, or removal of any authorized, planned, or supported service or service component that could affect IT services." In other words, a Change is adding, removing, or modifying anything that could directly or indirectly affect the organization's services and operations. The changes could include documentation, processes, applications, or IT infrastructure changes.
Change Management is a set of processes defined to manage the lifecycle of a change request from start to closure. It aims to minimize risks and disruptions to IT services and business operations while the changes are being implemented.
How does it work?
Domain experts, management, architects, or solution architects are involved in planning and implementing a change request.
Types of Change
Type
Description
Example
Standard Change
Standard Changes are the ones that frequently occur in an organization. These changes are low-risk and have a pre-defined set of documented and approved processes to be followed. This pre-defined and approved process is called a template.
Reset the Password of an email account.
Minor Change
A minor change is a small, low-impact, and low-risk change that only occasionally occurs in an organization. It needs approval from the Change Advisory Board(CAB). It is essential to document all the important information for future reference. A minor change could be converted to a standard change in the future.
Changes to the company website.
Major Change
A major change is a high-risk and high-impact change that could impact an organization's services if it is not planned properly. It requires an in-depth proposal on risk analysis, financial implications, and cost-benefit analysis. It also requires approval from the Change Advisory Board(CAB) and management.
Changes to Network Infrastructure
Emergency Change
Emergency changes are unexpected disruptions that must be assessed and implemented as soon as possible to restore an organization's normal functioning.
Dealing with a server outage
Retrospective Change
Designed to record changes that were implemented urgently without prior documentation or approval. These ensure compliance by logging the change post-implementation for audit and visibility.
Fixing a critical bug without prior approval.
Emergency Change
Emergency changes are used in urgent situations where immediate change implementation is necessary to fix major issues or avoid significant business impact.
Created when a critical issue (like a server outage or security flaw) needs resolution.
Follows an accelerated approval path or may skip it altogether depending on settings.
A CAB review may still be scheduled post-implementation for audit compliance.
Documentation and justification are mandatory to ensure traceability.
Use Case Example:
The production server crashes at midnight. The support team performs a hotfix immediately. Right after, an emergency change is logged to ensure that this change is recorded and reviewed.
Retrospective Change
Retrospective changes are created to record already implemented changes, often outside of standard workflows. These are essential for capturing unexpected or reactive actions taken in real-time.
Useful for manual interventions or critical on-the-spot fixes.
Allows post-facto documentation including reason, impact, and CI information.
Ensures visibility and inclusion in audit logs or reports.
Can be routed for post-change review if needed.
Use Case Example:
A network engineer applied a configuration fix during a late-night alert. Since no prior change request was raised, they document it afterward using this change option for internal tracking and compliance.
What do you see on the screen?
The "Change" page lists all change requests in two views: Panel View and Grid View. It lists all changes with details like a summary card, change description, status, subject, team, requester name, and actions, sorted by time.
Working on a Change
Change Management involves people from different dimensions of a business. They work together to analyze, plan, and implement the change request.
Views of the Change Request
There are two ways to view change details in the right-side panel. They are:
Panel View - You see change details as a Summary Card in the Panel view. The summary card gives a brief summary of the change. This summary contains all the important information needed to work on the change. Details include:
Change ID: Auto-generated when a change is created.
Requester: Name of the requester
Change Manager: Name of the manager overlooking the change request.
Status: Displays the current status of the change. Users can change the status from here as well.
Priority: Displays the priority of the change. Technicians can change the priority of the change.
Service: Service category in which change is requested.
Actions: Quick action icons to work on the change.
The panel view for tickets has been revamped. The improved interface offers enhanced data visibility, with aging metrics conveniently displayed. This helps in faster navigation and reduced system load for a seamless user experience.
Grid View- In the Grid view, you see change details in tabular form. Clicking on the Change ID shows the change details.
Change ID: This is auto-generated when a change is created. Click on the Change ID to view the communication history, reply to and forward emails, add notes, analyze, view, and add work logs.
Subject: Subject of the change (derived from the change subject line).
Reason for Change: The reason for detailing why the change was requested.
Change Type: Type of change: Standard, Major, Minor, and Emergency.
Status: Displays the current status of the change. Users can change the status from here as well.
Impact Service: Service Category which the change could impact.
Priority: The priority of the change.
Risk: Risk level of the change.
Requester: Displays the name of the requester (initial)
Change Manager: Name of the manager overlooking the change request.
Change Implementer: Name of the user responsible for change implementation.
Actions: Quick action icons to work on the change.
Relation
Change relationships follow the same structure as defined in Problem Management. For a detailed explanation of how linked records work, refer to the Problem Management page.
Delegate Approval
Delegation enables users to assign their approval responsibilities to another user for a specified period. Ensures that ongoing approvals are not delayed when the primary approver is unavailable due to planned leave, travel, or other reasons.
Click here to learn more.
Planning and Risk Analysis
Implementing a change requires intensive planning, risk analysis, defining tasks, and approvals. To help users achieve this, the "Change" module has the following tabs:
Planning - A comprehensive plan is essential for successfully implementing a change. In the planning tab, a user can enter the following details:
Rollout Plan - A rollout plan is a detailed step-by-step description of how the change will be implemented in the production environment. The rollout plan is created in such a way that there is minimal impact on the organization. A rollout plan describes whether the change will be implemented in a phased manner or as a whole.
Rollback Plan - A rollback plan is a verified step-by-step fallback or back-out plan in case the change implementation doesn't go as expected. It is essential to have a rollback plan when implementing a major change.
Impact - A user can enter the anticipated impact of the change on various dimensions of the organization. It can be categorized into the following:
Business
Location
Department
Group
User
Planned Start Date - The intended date to begin implementing the change.
Planned End Date - The intended date to end implementing the change.
Tasks - This allows users to define and manage individual tasks involved in executing a change. Each task can be customized with fields such as title, type, priority, due date, and assignee.
Label
Action
Description / Example
Title*
Enter text
Name or heading for the task.
Example: Database Backup, Server Reboot
Description*
Enter content using the editor
A short explanation of the task.
Example: Perform a full DB backup before deployment.
Type*
Select from the drop-down
Choose the nature of the task:
Default – Generic task with no specific category.
Pilot – Task for trial or limited rollout.
Staging Development – Tasks in staging/testing environments.
Automation – Tasks handled via scripts or automation tools.
Field – On-site/field-level tasks.
Recurring – Tasks that repeat on a schedule.
Maintenance – Preventive or scheduled maintenance tasks.
Work Order – Actionable job-oriented tasks.
3rd Party – Task assigned to an external vendor.
NCCM – Tasks related to NCCM configurations or templates.
Status
Select from the drop-down
Choose the current task status:
To-Do (Open)
Ongoing (In Progress)
Blocked (On Hold)
Done (Close)
Cancelled (Close)
Priority
Select from the drop-down
Indicates task urgency:
Low
Medium
High
Critical
Due Date
Select date
Target completion date for the task.
Actual Start Date
Select date
Date when the task was actually initiated.
Actual End Date
Select date
Date when the task was completed.
Team
Select from the drop-down
Choose the team responsible for executing the task.
Assignee
Select from the drop-down
Assign the task to a specific team member.
Submit
Click
Saves the task to the change ticket.
Cancel
Click
Discards the task and closes the dialog.
Attachments - When uploading attachments to a change ticket, Users can classify and organize files for clarity and compliance.
Label
Action
Description
Upload Area
Drag and drop / Browse to upload
Upload files (Formats: PNG, JPEG, PDF, DOCX, XLSX, etc., Max size: 20MB).
Category*
Select from the drop-down
Choose a category to classify the attachment:
Default Category
Change Screenshot
Team Document
Team Docs
Test Plan
Dev Plan
Impact Assessment
Risk Assessment
Requirements
Rollout Plan
Rollback Plan
Other
Description
Enter text
Provide a brief note or context about the uploaded attachment.
Upload
Click to confirm
Uploads the selected file(s) to the Change record.
Cancel
Click to abort
Closes the pop-up without saving the changes.
Risks - It helps identify, evaluate, and reduce potential risks associated with a change before it is implemented. It offers visibility into possible business, technical, financial, or operational impacts and ensures that suitable mitigation plans are established.
Risk Records
Risk Records are used to document or create a knowledge base of the risks associated with a change. They capture critical information such as the risk name, type, description, and mitigation plan.
Add Record
Click on Add Record to add the details below:
Label
Action
Description / Example
Name
Enter a name
Specifies the unique title or identifier of the risk. Example: Database downtime risk.
Risk Type
Select from the dropdown
Defines the category of the risk.
Business – Risks affecting operations or service delivery
Technical – Risks related to systems, infrastructure, or technology
Financial – Risks impacting costs, budget, or revenue
Other – Any risk outside the above categories
Mitigation Plan
Add mitigation details
Outlines the steps or strategy to reduce, transfer, or eliminate the identified risk. Example: Schedule backup before change and prepare rollback plan
Description
Provide description
Offers detailed context about the risk, including possible causes, expected impact, and scenarios in which the risk might occur.
Example: Risk of service outage if the server upgrade fails during peak hours
Risk Assessment
It provides a structured way to evaluate the potential risks associated with a change. It involves defining questions with multiple options, assigning weights, and mapping the responses to criticality levels.
The outcome of the assessment is represented through a riskometer, which indicates the overall risk level associated with the change.
Authorized Role: Only Change Managers can perform risk assessments.
Riskometer: Displays the criticality level based on assessment responses.
Workflow Dependency: Workflows can be configured so that changes move to CAB Approval only after risk assessments are completed.
Risk Level: Change priority is automatically updated based on the assessment result.
Workflow Integration
Risk Assessment Mandatory Toggle – Available in every workflow state; disabled by default. If enabled, the assessment must be completed before moving to the next state.
CAB Approval Dependency – Transition to CAB Approval can be restricted until the Change Manager completes the risk assessment.
Priority Adjustment – Assessment results can automatically update the change request’s priority based on evaluated risk.
Workflow Toggle: By default, the Risk Assessment Mandatory toggle is disabled. If enabled, completing the risk assessment becomes mandatory during state transitions.
Add Assessment
Risk Assessments cannot be added directly from the Risk tab. Instead, they are created using Risk Templates, which define the assessment questions, weights, and criticality values.
Skip Assessment: This toggle can only be updated by the Change Manager. When enabled, the risk assessment step can be bypassed.
Sample Questions | Basic Details
Question
Weight
Options
Option Value
How many assets will be affected by this server change?
4
More than 50 assets
Critical
Between 20 and 50 assets
High
Less than 20 assets
Low
What is the expected downtime duration for the change?
5
More than 4 hours
Critical
1–4 hours
High
Less than 1 hour / Zero downtime
Low
What level of business services will be impacted?
3
Core services (e.g., customer-facing apps, payment systems)
Critical
Internal services (e.g., reporting, HR, internal tools)
Medium
Non-critical services (e.g., test/dev environments)
Low
How complex is the rollback or recovery plan for this change?
2
No rollback possible
Critical
Rollback possible but time-consuming
High
Simple and tested rollback plan
Low
What level of dependency exists on external vendors or third-party systems?
3
Multiple critical vendor/third-party dependencies
Critical
Limited vendor dependency with partial risk
Medium
No vendor dependency
Low
Riskometer Functionality
The Riskometer dynamically evaluates the overall risk involved in a change request based on the answers provided.
Each question is assigned a weight, and each selected option contributes a predefined risk value. The system then calculates the weighted percentage and displays the cumulative risk score on the Riskometer.
This visual indicator updates automatically and represents the level of risk associated with the change.
Risk Level Calculation
The Riskometer determines the final risk level using the total risk weight. The calculation follows these rules:
Critical (Red): Risk score above 80
High (Orange): Risk score between 61–80
Medium (Green): Risk score between 41–60
Low (Blue): Risk score between 21–40
Very Low (Blue): Risk score 20 or below
The selected answers are:
Q1: Between 20–50 assets → High → Value = 2 (80%)
Q2: 1–4 hours downtime → High → Value = 2 (80%)
Q3: Core services impacted → Critical → Value = 1 (100%)
Q4: Rollback possible but time-consuming → High → Value = 2 (80%)
Q5: Limited vendor dependency” → Medium → Value = 3 (60%)
Total Weight = 17
Step 2: Weight % Calculation
Q1 → (4 ÷ 17) × 100 = 23.53%
Q2 → (5 ÷ 17) × 100 = 29.41%
Q3 → (3 ÷ 17) × 100 = 17.65%
Q4 → (2 ÷ 17) × 100 = 11.76%
Q5 → (3 ÷ 17) × 100 = 17.65%
Step 3: Risk Contribution of Each Question
Formula:
Risk Contribution = Risk Value Percentage × Weight Percentage of Question/ 100
Q1: (80 × 23.53) ÷ 100 = 18.82
Q2: (80 × 29.41) ÷ 100 = 23.53
Q3: (100 × 17.65) ÷ 100 = 17.65
Q4: (80 × 11.76) ÷ 100 = 9.41
Q5: (60 × 17.65) ÷ 100 = 10.59
Step 4: Final Risk Score
18.82+23.53+17.65+9.41+10.59=80
Total Risk Score = 80
Step 5: Riskometer Result
Score = 80
According to thresholds: High Risk (Orange)
Miscellaneous
Additional Icons
Name
Description
Comment
A user/technician can see the comments on the change and also can add new comments.
History
Shows the history of the current change request from the time it was created.
Interaction
Shows the history of the change request created by the requester.
Attachment
Shows all the attachments of the current change request.
Change Source
Shows the source of the change, like email, web, phone, etc.
Quick Actions
Name
Description
Quick Edit
To perform quick edit actions like change manager, status, priority, urgency, severity, impact service, and the assignee. Use the "Detailed Edit" button to edit the Change details.
Edit
To edit the Change in detail.
Delete
To delete the Change. This action is irreversible.
Task
Shows the tasks involved in the change.
*Risk
Shows the risks involved in the change.
*Add Ticket
If any issues occur while implementing the change, a ticket can be raised.
Change aging for helpdesk/ ITSM close and resolve conditions
Grid View includes Aging Metric. Track Change resolution time accurately. Click 'Resolve' or 'Close' to stop the aging clock. Get detailed aging reports based on resolved status.
*These quick action tools are available only for Major and Minor Changes.
Page Actions
The Change page also has the following actions.
Label/ Icon
Description
Expand Icon
To View the change filters.
Search Bar
To help search for a specific change request using the Change ID, assignee, etc.
Calendar
To filter the change requests by a specific day, date, or date range.
Workspace task App
Enjoy a seamless and streamlined experience with the powerful capabilities of the Task Common Module for enhanced task management within the application.
*Tag
Select a change request to view the tag option. Tagging is a way to group change requests.
*Assignment
Select one or more change requests to assign to a team.
*Delete
Select one or more change requests to delete them.
Pause
To pause the auto-reload.
Configure
To configure the summary card and column selection.
*Select at least one change request to enable these options
Close Change
This pop-up allows change managers or authorized users to close change requests with the appropriate closure type, category, notes, and timestamped records.
Label
Action
Description / Example
Status
Auto-filled or selected manually
Displays the change status (It will be closed).
Close Change*
Enter closure summary
Add final remarks on what was done, implementation outcome, or lessons learned. Example: “ES3 server restored with latest patch deployment.”
Closed by
Select from the drop-down
Choose the user who is closing the change. Example: Deepak Kumar
Close Type
Select from the drop-down
Defines the method and reason for closure:
Auto Closure: The system was closed due to no further updates after a set period.
Not Solved: Change was implemented, but the issue was not resolved.
Solved: The issue was resolved successfully via this change.
Actual Closure Date
Auto-filled or editable
Actual date and time when the change was completed or formally closed. Example: Aug 01, 2025, 12:53 PM
Agreed Closure Date
Select date
The closure date agreed during CAB or planning discussions. Example: July 31, 2025
Closure Category
Select from the drop-down
Captures the outcome of the change:
Successful: Change achieved the intended goal without issues.
Successful with Issues: Change succeeded with minor/managed issues.
Rollback: Change was reverted due to failure or risk.
Partially Implemented: Some objectives were met; others deferred or missed.
Cancelled: Change was withdrawn before implementation.
Unsuccessful: Change failed and caused no improvement.
Complete (Button)
Click to confirm closure
Finalizes the closure and updates records. Post-closure changes require admin override.
Last updated
Was this helpful?