From a Hiccup to a Fix: Creating Change Requests from Incidents

From a Hiccup to a Fix: Seamlessly Creating Change Requests from Incidents

In the dynamic world of IT service management, encountering issues is not a matter of if, but when. These issues, often categorized as incidents, are the bread and butter of support teams. However, what happens when an incident points to a deeper, underlying flaw in a system or process that requires a proactive modification? This is where the power of integrating incident management with change management comes into play, allowing for the creation of change requests directly from incidents. This article will delve into the “why” and “how” of this crucial workflow, offering practical insights and real-world relevance for IT professionals.

The Synergy Between Incidents and Change Requests

Before we dive into the technicalities, it’s essential to understand the relationship between these two core ITIL processes. As reference point (29) suggests:

“If a person faces some issue, he will create an incident. If the same issue is happening again and again, then he will create a problem. And if the support team feels like some changes are required in their software, then they will create a change request.”

This perfectly encapsulates the lifecycle. An incident is a disruption to normal service operations. A problem investigates the root cause of one or more incidents. A change request, on the other hand, is a formal proposal for an alteration to an IT service or configuration item. The magic happens when a support engineer, while resolving an incident, identifies that the fix isn’t just a temporary workaround but a permanent solution requiring a formal change. This is where the workflow bridges the gap.

Why Create a Change Request from an Incident?

The benefits of this direct link are numerous:

Proactive Problem Solving: Instead of merely resolving an incident with a workaround, creating a change request allows for a permanent fix, preventing future occurrences of similar incidents.
Improved Documentation: The incident record provides valuable context for the change request, including the symptoms, impact, and initial troubleshooting steps. This saves time and ensures a comprehensive understanding for the change implementers.
Streamlined Workflow: It eliminates manual steps. Support engineers don’t have to re-enter information or initiate a separate process to request a change.
Enhanced Visibility: The link between the incident and the change request provides traceability, allowing stakeholders to see the origin of the change and its impact on incident reduction.
Reduced Risk: By formalizing changes and ensuring they go through the proper approval and testing processes, the risk of unintended consequences or further disruptions is minimized.

The “How-To”: Implementing the Workflow

In most modern ITSM platforms, creating a change request from an incident is a built-in feature. The exact steps might vary slightly depending on the system (like ServiceNow, BMC Helix, Jira Service Management, etc.), but the core concept remains the same. Let’s explore the common approaches.

User Interface (UI) Driven Creation

This is the most common and user-friendly method. When a support engineer is working on an incident and determines a change is necessary, they typically follow these steps:

Open the Incident: Navigate to the specific incident record that requires a change.
Locate the “Request Change” Option: Most platforms have a dedicated button or menu option, often labeled “Request Change,” “Create Change,” or similar. This might be found in the form header, a related list, or a context menu.
Initiate the Change Request: Clicking this button will typically open a new change request form.
Pre-populated Information: Crucially, the system will often pre-populate fields in the new change request form with relevant data from the incident. This can include:
- Short Description: Often inherited from the incident’s short description or a synthesized version.
- Description: The full description of the incident, providing detailed context.
- Affected Configuration Item (CI): If the incident is linked to a CI, this will be carried over, helping to identify the scope of the change.
- Caller/Requester: The original reporter of the incident might be linked.
- Reference to Incident: The new change request will have a direct link back to the originating incident.
Supplement and Submit: The support engineer then supplements this information with details specific to the proposed change, such as the proposed solution, implementation plan, rollback plan, risk assessment, and required approvals. They then submit the change request for review.

Real-World Example (UI-Driven):

Imagine a user reports that the company’s internal HR portal is intermittently failing to load. The support engineer investigates and discovers that the issue stems from a poorly optimized database query that is causing timeouts during peak hours. Instead of just advising the user to try again later (a workaround), the engineer realizes this requires a permanent fix by optimizing the query. They use the “Request Change” button on the incident form. The new change request form automatically pulls in the HR portal’s application as the affected CI, the user’s report as the description, and the support engineer adds details about the specific database query that needs optimization, along with a plan to test the fix in a staging environment before deploying it.

Scripted Creation (For Automation and Advanced Workflows)

While UI-driven methods are standard, sometimes you might need to automate the creation of change requests. This is particularly useful for integrating with other systems or for triggering changes based on specific incident patterns. Reference point (25) provides a glimpse into this with GlideRecord in the ServiceNow context:


    // Example script to create a change request from an incident context
    // This snippet would typically be part of a business rule or workflow
    
    var grChange = new GlideRecord('change_request'); // Target table for change requests
    grChange.initialize(); // Prepare to create a new record
    
    // Populate essential fields from the incident
    grChange.short_description = 'Proposed change based on Incident: ' + current.number + ' - ' + current.short_description;
    grChange.description = 'Details from incident:\n' + current.description + '\n\nRecommended Solution:\n[Engineer to add specific change details here]';
    
    // Linking back to the incident (Crucial for traceability)
    // Assuming 'incident' is a reference field on the change_request table for this purpose
    // The exact field name might vary depending on your platform's configuration.
    // If not directly linked, a custom field or related list might be used.
    // For ServiceNow, you might link using 'caused_by' or a custom field.
    
    // Let's assume there's a field named 'u_related_incident' on change_request
    // which is a reference to the incident table.
    grChange.u_related_incident = current.sys_id; 
    
    // Example of setting other relevant fields (adjust as per your CMDB and categories)
    if (current.cmdb_ci) {
        grChange.cmdb_ci = current.cmdb_ci; // Inherit affected CI from incident
    }
    
    // Setting category, subcategory, assignment group etc.
    // These would ideally be determined by logic based on the incident.
    grChange.category = 'standard'; // Example: Standard change category
    grChange.subcategory = 'software_update'; // Example subcategory
    grChange.assignment_group = 'YOUR_DEFAULT_CHANGE_ASSIGNMENT_GROUP_SYS_ID'; // Replace with actual sys_id
    
    // You might want to set the state to 'New' or 'Assess' depending on your workflow
    grChange.state = '1'; // Assuming '1' is the sys_id for 'New' state in your change workflow
    
    var sysId = grChange.insert(); // Insert the new change request record
    
    if (sysId) {
        // Optionally, link tasks or activities back to the incident
        // Or, update the incident to indicate a change request has been created
        current.work_notes = 'A change request (CHG0012345) has been created from this incident.'; // Example update to incident
        current.update();
        
        gs.addInfoMessage('Change Request created: ' + grChange.number);
    } else {
        gs.logError('Failed to create change request from incident: ' + current.number);
        gs.addErrorMessage('Failed to create change request.');
    }

In this script:

We use GlideRecord to interact with the change_request table.
initialize() prepares a new record.
We populate short_description and description, often incorporating the incident’s number and details for context.
A crucial step is linking back to the incident. This might be through a dedicated field (like u_related_incident in the example) or by using fields like caused_by (depending on the ITSM platform’s schema). This establishes the parent-child or related relationship.
Other relevant fields like cmdb_ci, category, and assignment_group are populated. The specific values would be determined by the nature of the incident and predefined logic.
insert() saves the new record.
Feedback is provided to the user, and potentially the incident is updated to reflect that a change has been initiated.

When to Use Scripted Creation:

Automated Triggering: When an incident meets specific criteria (e.g., multiple recurring incidents of the same type, a high-priority incident impacting a critical CI), a business rule can automatically generate a change request.
Integration: When integrating with external systems that report issues, these can be translated into incidents, which then trigger automated change requests.
Bulk Operations: If a single underlying issue is causing multiple incidents, a script can be used to create one change request that addresses all of them.

Ensuring a Smooth Transition: Best Practices

Simply having the capability to create a change from an incident isn’t enough. For this workflow to be effective, consider these best practices:

Clear Criteria for Escalation

Support engineers need clear guidelines on when to escalate an incident into a change request. This prevents unnecessary change requests that clutter the system and burden the change advisory board (CAB).

Permanent Fix Required: If the incident cannot be resolved with a simple workaround or requires code modification, configuration change, or infrastructure update.
Preventative Maintenance: If the incident reveals a weakness that, if not addressed, is likely to cause future incidents.
Standard vs. Normal Changes: If the required change is well-defined, low-risk, and follows a pre-approved procedure, it might qualify as a ‘standard’ change. If it’s more complex, higher risk, or requires significant planning and approval, it becomes a ‘normal’ change.

Linking is Key: Traceability

As highlighted in our script example, ensuring a robust link between the incident and the change request is paramount. This allows for:

Impact Analysis: Understanding how many incidents are being resolved by a specific change.
Auditing: Tracing the lineage of changes back to the issues that prompted them.
Knowledge Management: Using the incident to inform the change and the resolved change to update knowledge base articles for future incidents.

Defining the Scope of Pre-population

Leverage your ITSM platform’s capabilities to pre-populate as much relevant information as possible. This reduces manual effort and ensures consistency. However, ensure that the system doesn’t over-automate, forcing engineers to review and correct potentially incorrect inherited data.

Workflow and Approvals

The change request created from an incident must enter the standard change management workflow. This includes:

Assessment and Planning: The change request details should be reviewed for feasibility, risk, and impact.
Approval: The change request needs to go through the appropriate approval process (e.g., CAB, technical approvers).
Implementation: The change is scheduled and executed.
Testing and Verification: The implemented change is tested to ensure it resolves the original issue without introducing new ones.
Closure: Once verified, the change request is closed.

Handling Dependencies and Constraints

It’s important to recognize that incidents, problems, and changes are all part of a larger ecosystem, and tasks play a crucial role. Reference point (32) reminds us that “incident, problem, change request which are extending task table.” This means they share common functionalities and can have associated tasks.

Incident Tasks and Change Closure

A common scenario is ensuring that an incident cannot be closed if its associated tasks are still open. Reference point (27) demonstrates this with a script:


    // Script to prevent closing an incident if tasks are open
    // This would typically be in a 'before' business rule on the incident table
    
    var grTask = new GlideRecord('incident_task'); // Table for incident tasks
    grTask.addQuery('incident', current.sys_id); // Filter for tasks related to the current incident
    grTask.addQuery('state', '!=', 3); // Assuming '3' is the state value for 'Closed' or 'Resolved'
    grTask.query();
    
    if (grTask.hasNext()) {
        gs.addErrorMessage('Cannot close the incident because there are open tasks.');
        current.setAbortAction(true); // Prevent the incident from being closed
    }

This logic also applies to problems and changes. If a change request has open implementation tasks, it shouldn’t be closed. This ensures that the entire lifecycle of the change, including its execution and verification, is completed.

The Relationship with Problem Management

As noted earlier, recurring incidents often lead to a problem record. A change request can also be initiated from a problem record. When a root cause is identified in a problem investigation, and the solution involves a change, a change request is created. This maintains the flow from incident -> problem -> change.

Troubleshooting Common Issues

While the process is designed to be seamless, you might encounter hiccups. Here are some common troubleshooting points:

1. Change Request Not Populating Correctly

Check Business Rules/Workflows: The logic for populating fields on the change request form from the incident is usually controlled by business rules or workflow activities. Verify these are active and configured correctly.
Field Mappings: Ensure that the correct fields on the incident are mapped to the intended fields on the change request. Sometimes custom fields or incorrect reference fields can cause issues.
Permissions: Does the user creating the incident have the necessary roles to create change requests and populate the required fields?

2. Link Between Incident and Change is Broken

Reference Field Configuration: Verify that the field used to link the incident to the change request (e.g., `caused_by`, `u_related_incident`) is correctly configured as a reference field to the incident table.
Script Errors: If using scripted creation, check the system logs for any errors occurring during the `insert()` operation or field population.

3. Change Request Workflow Not Triggering

State Transitions: Ensure that the initial state of the created change request (e.g., ‘New’, ‘Assess’) is correct for triggering the subsequent workflow or approval processes.
Assignment Rules: Verify that assignment rules are correctly configured to route the change request to the appropriate group or individual.

4. Users Unable to Create Changes

Role and ACL Checks: The user needs appropriate roles (e.g., ITIL, Change Manager) and Access Control Lists (ACLs) to create and modify change requests.
UI Action Configuration: The “Request Change” button or UI Action itself might be incorrectly configured or disabled for certain user groups.

Interview Relevance

Understanding the relationship and workflow between incident and change management is a common topic in IT service management interviews. Be prepared to discuss:

Your experience creating change requests from incidents.
The benefits of such a workflow.
The key information that should be transferred from an incident to a change request.
How you would handle a situation where an incident fix requires a change.
The potential challenges and how you would overcome them.
Your understanding of ITIL processes like Incident Management, Problem Management, and Change Management and how they interconnect.

When asked about scripting, being able to explain the purpose of GlideRecord (or equivalent in other platforms) and how you would use it to automate such processes demonstrates valuable technical acumen.

Conclusion

The ability to seamlessly create change requests from incidents is a cornerstone of efficient and proactive IT service management. It transforms reactive problem-solving into a more strategic approach, preventing recurring issues and ensuring system stability. By understanding the underlying principles, leveraging the available tools (whether UI-driven or scripted), and adhering to best practices, IT teams can significantly enhance their service delivery capabilities, reduce downtime, and foster a culture of continuous improvement. This integrated approach not only benefits the IT department but also contributes to a more reliable and productive experience for the entire organization.