# 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. **Clone Change** The Clone Change option allows technicians to quickly create a new Change Request (CR) by copying key details from an existing change. This reduces manual data entry, ensures consistency, and speeds up the creation of repeat or similar changes.

The following fields are automatically copied from the selected change: * Subject * Change Type * Change Manager * Change Followers * Location * Rollout Plan * Rollback Plan Fields to Update During Cloning:


Field	Description
Requester	Select the requester for the new change. This can be the same or different from the original change.
Assignment Details	Update the assignee or assignment group, if required.

{% hint style="info" %} The new change will retain the same subject structure as the original change, ensuring consistency. {% endhint %} **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. {% hint style="info" %} **Note:** * The quick action bar appears as a floater on each change line and is common in both Panel and Grid views. * The summary card details can be configured to suit requirements. Click on the "Configure" icon to customize the details you want to see on the screen. * The Configure icon is available only in Grid View. {% endhint %} #### Conflict Detection * When an asset is added to a change, the system checks if the same asset is already linked to other active changes. * If a conflict is detected, a **warning message** displays the conflicting Change IDs. * Conflict detection is **informational only** and does not block the user from proceeding. * In the **Change Calendar,** overlapping scheduled changes involving the same asset are highlighted to indicate potential conflicts.

### Relation Change relationships follow the same structure as defined in [Problem Management](https://docs.infraon.io/infraon-help/problem-management#problem-management-and-relation-with-other-processes). For a detailed explanation of how linked records work, refer to the Problem Management page. #### NCCM Job Association with Change Tasks When a Change Task is created from the [NCCM](https://docs.infraon.io/infraon-help/infinity-user-guide/nccm) module, NCCM sends the Job Execution Details, Job Status, and Job ID to the Change Management module through an API call. The Job ID is stored against the Change Task to maintain traceability between the change and the associated NCCM job. If the Change Type is set to NCCM and the user has the required NCCM job permissions, a Job button is displayed next to the Add Task option.

Clicking this button opens the corresponding [CLI Jobs](https://docs.infraon.io/infraon-help/infinity-user-guide/nccm/cli-jobs) page in a new browser tab. The related NCCM job grid is automatically filtered using the Change Summary, allowing users to quickly track the execution status of the job linked to the Change Task. ### 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](https://docs.infraon.io/infraon-help/ticket-management/tickets#hlk208223135) 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. {% hint style="info" %} Risks can be recorded for all change types—**Major, Minor, Emergency, and Retrospective**. They do not apply **to Standard Changes**, since these are pre-approved, low-risk, and follow a predefined process. {% endhint %} **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. {% hint style="info" %} These records can only be created and managed by privileged members, ensuring that risk documentation is accurate and controlled. {% endhint %} 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. {% hint style="info" %} Only the **Change Manager** is authorized to perform risk assessments. {% endhint %} * **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**](https://docs.infraon.io/infraon-help/infraon-configuration/general-settings/template#add-risk-template), 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)**

{% hint style="info" %} Assessment results can automatically update the change request’s priority based on evaluated risk. {% endhint %} ## 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 view **changes and releases** scheduled on the calendar. The calendar supports **Month, Week, Day, and List** views and allows filtering releases based on status, type, priority, risk, team, and other criteria. Filtered releases are displayed according to their scheduled duration. | | 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.