The Pulse of IT: Why We Need Efficient Service Management

In the bustling digital landscape of any modern organization, the IT department is often the unsung hero, keeping the gears turning and the lights on. But even the best-oiled machines encounter hiccups. When those hiccups turn into outright stoppages, it’s IT to the rescue. This is where IT Service Management (ITSM) truly shines, providing structured processes to handle disruptions, find root causes, and prevent future occurrences.

We’ve all been there: that moment when an essential service grinds to a halt, or a critical application refuses to load. These are more than just minor annoyances; they’re direct interruptions to productivity, capable of derailing projects and costing businesses precious time and money. Our goal in ITSM is to minimize these disruptions, and a significant part of that involves not just reacting, but proactively seeking out and eliminating the underlying issues.

This article delves into the crucial world of Problem Management, particularly focusing on how scripting can revolutionize the way we create and manage problem records. While the concepts apply broadly, we’ll be looking through the lens of a popular ITSM platform (think ServiceNow, given the `GlideRecord` syntax you’ll see). So, grab your virtual coffee, and let’s explore how a bit of code can transform your ITSM workflow from merely reactive to strategically proactive.

Incident, Problem, and Change: The Core Trinity of ITSM

Before we dive into the code, let’s ensure we’re all on the same page regarding the fundamental building blocks of effective IT service delivery. These three pillars – Incident, Problem, and Change – form the backbone of a resilient IT environment.

What is an Incident? The Immediate Firefight.

Imagine you’re knee-deep in a crucial presentation, and suddenly, your screen freezes. Or perhaps your email client inexplicably refuses to send messages. This, my friend, is an Incident. As the name suggests, it’s a sudden, unplanned interruption to an IT service or a reduction in the quality of an IT service. The key here is “sudden” and “interruption.”

Incident: A sudden interruption in the service when an employee works in the organization. If something suddenly stopped working, the employee will get support from a support engineer by creating an incident.

When an incident occurs, the primary goal is rapid restoration of service. Think of it as putting out a fire. We don’t necessarily care *why* the fire started in that moment; we just need to extinguish it and get things back to normal. This often involves quick fixes, workarounds, or restarting services.

What is a Problem? Uncovering the Root Cause.

Now, let’s extend that scenario. What if your screen freezes not once, but every Tuesday morning at 10 AM? Or what if three of your colleagues in different departments report their email clients crashing simultaneously, experiencing the *exact same issue*? This is where an incident transcends its initial definition and morphs into a Problem.

Problem: If the same issue is repeatedly happening to the same employee, then it is called a problem. If the same problem is happening to multiple people at the same time, then it’s an incident where we’ll create a parent incident, and the rest will be child incidents. Whenever you close the parent incident, the child incidents will also get closed.

A problem is the underlying cause of one or more incidents. While an incident focuses on restoring service, a problem focuses on identifying, understanding, and resolving the root cause to prevent future recurrences. This involves a deeper investigation, often spanning multiple teams and requiring more time than a typical incident resolution. The parent/child incident relationship described above is a clever way to manage widespread incidents – acknowledging that a single underlying problem might be causing a cascade of individual service interruptions.

What is a Change Request? Planned Evolution.

Once you’ve identified the root cause of a problem – say, an outdated software version or a misconfigured network device – you can’t just fix it on the fly. Implementing a solution often requires a planned, controlled modification to the IT infrastructure. This is where a Change Request comes into play.

Change Request: Whenever you create an incident, if the support engineer feels that there should be some change in the software, then they will raise a change request from that incident.

A change request is a formal proposal to modify, add, or remove anything that could have an effect on IT services. It’s about careful planning, impact assessment, and controlled execution to minimize risk. For instance, if a problem investigation reveals a critical vulnerability in a server operating system, a change request would be initiated to schedule and perform the necessary patching or upgrade.

The Interconnected Web: Incident, Problem, and Change Relationship

These three processes are not isolated; they form a symbiotic relationship:

Relationship: If a person faces some issue, they will create an incident. If the same issue is happening again and again, then they 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.

An incident alerts us to a symptom. If that symptom persists or spreads, it points to a problem – the underlying disease. The diagnosis of the problem often necessitates a change – the prescribed treatment – to eradicate the disease and prevent future symptoms. Understanding this lifecycle is paramount for any IT professional aiming for a proactive, stable, and high-performing IT environment.

The Magic of Automation: Why Scripting is Your Best Friend in ITSM

In a world increasingly driven by speed and efficiency, manual processes are often bottlenecks. Imagine manually creating hundreds of incident records after a major outage, or meticulously linking every affected incident to a newly identified problem. It’s tedious, error-prone, and frankly, a waste of valuable human talent.

This is where scripting steps onto the stage as a true game-changer. Automation through scripting allows us to:

• Boost Efficiency: Automate repetitive tasks, freeing up support engineers for more complex issues.
• Ensure Consistency: Standardize record creation and field population, reducing human error.
• Enable Integration: Seamlessly create records from external monitoring systems, emails, or other platforms.
• Implement Complex Logic: Orchestrate workflows, link records, and enforce business rules that would be cumbersome or impossible manually.

For platforms like ServiceNow, the primary tool for server-side scripting interactions with records is the GlideRecord API. Think of GlideRecord as your programmatic window into the platform’s database, allowing you to query, create, update, and delete records with precision.

Deep Dive: Creating Records Using Scripts with GlideRecord

Let’s get our hands dirty with some code. The core principle for creating any record programmatically in a ServiceNow-like environment is quite consistent. We instantiate a GlideRecord object for the target table, initialize a new record, set its field values, and then insert it.

The Anatomy of Record Creation: GlideRecord Fundamentals

The basic pattern looks like this:

var gr = new GlideRecord('table_name'); // Step 1: Instantiate GlideRecord for the target table
gr.initialize();                     // Step 2: Initialize a new, empty record
gr.field_name = 'value';             // Step 3: Set field values
// ... set more field values
gr.insert();                         // Step 4: Insert the record into the database
        

• var gr = new GlideRecord('table_name');: This line creates an object that represents a database query. By passing the table name (e.g., ‘incident’, ‘problem’, ‘change_request’), we tell the system which table we want to interact with.
• gr.initialize();: This is crucial for creating new records. It prepares the GlideRecord object to accept new data, essentially creating an empty row in memory that we can populate. Without this, calling insert() would typically fail or behave unexpectedly.
• gr.field_name = 'value';: Here, we assign values to the fields of our new record. The field_name should match the actual column name in the database (e.g., short_description, caller_id).
• gr.insert();: This command executes the creation, committing the new record with all its populated fields to the database.

Important Note on Reference Fields: `sys_id` vs. Display Value

When you’re setting values for reference fields (fields that link to another record, like ‘Caller’ linking to a user record, or ‘Configuration Item’ linking to a CI record), you typically need to provide the Sys ID of the referenced record, not its display name. The Sys ID is a unique, 32-character identifier assigned to every record in the platform.

For example, gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; uses the Sys ID of a specific user. If you tried gr.caller_id = 'John Doe';, it wouldn’t work unless ‘John Doe’ was an actual Sys ID (which it won’t be!).

Example 1: Creating an Incident Record Programmatically

Let’s say a monitoring tool detects an issue and needs to automatically create an incident. Here’s how you’d do it:

// 23) How to create incident record using script?
// Answer) Using GlideRecord as follows

var grIncident = new GlideRecord('incident'); // Instantiate GlideRecord for the 'incident' table
grIncident.initialize();                    // Initialize a new incident record

// Set field values for the new incident
grIncident.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_ID of the user who reported the issue
grIncident.category = 'inquiry';                           // Category of the incident
grIncident.subcategory = 'antivirus';                      // Subcategory
grIncident.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';   // Sys_ID of the Configuration Item (e.g., a server or application)
grIncident.short_description = 'Automated test incident created by script'; // Concise summary
grIncident.description = 'This incident was created automatically by a script to demonstrate GlideRecord functionality. Antivirus definitions are outdated on server XYZ.'; // Detailed description
grIncident.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_ID of the assignment group

grIncident.insert(); // Insert the new incident record into the database

gs.info("Incident " + grIncident.number + " created successfully!"); // Log a message with the incident number
        

This script would typically be part of a larger automation, such as a scheduled job, an inbound email action, or an integration with another system. It ensures that all necessary fields are populated, leading to a standardized and actionable incident record.

Example 2: The Main Event – Creating a Problem Record Using Script

Now, for the star of our show: creating a problem record. This is incredibly powerful when you identify a recurring issue (perhaps through analytics on incident data) or if a major outage clearly points to a systemic problem requiring root cause analysis.

Consider a scenario where a script periodically analyzes closed incidents. If it finds five or more incidents with the same short description and Configuration Item within a week, it could automatically trigger the creation of a problem record. This shifts your IT department from being purely reactive to proactively addressing potential systemic issues.

// 24) How to create problem record using script?
// Answer) Using GlideRecord as follows

var grProblem = new GlideRecord('problem'); // Instantiate GlideRecord for the 'problem' table
grProblem.initialize();                    // Initialize a new problem record

// Set field values for the new problem
// Note: Some fields like caller_id might be less common on a problem record directly,
// as problems are often created by IT staff after analyzing incidents,
// but the example shows a general pattern.
grProblem.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_ID of the person who might have reported the initial incident or the Problem Coordinator
grProblem.category = 'inquiry';                            // Category of the problem
grProblem.subcategory = 'antivirus';                       // Subcategory
grProblem.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';    // Sys_ID of the Configuration Item identified as problematic
grProblem.short_description = 'Repeated antivirus service failures on server farm'; // Concise summary of the problem
grProblem.description = 'Multiple incidents reported concerning antivirus service (e.g., definitions not updating, service crashing) across several servers linked to CMDB_CI. Root cause analysis required.'; // Detailed description
grProblem.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_ID of the group responsible for problem investigation

grProblem.insert(); // Insert the new problem record into the database

gs.info("Problem " + grProblem.number + " created successfully!"); // Log a message with the problem number
        

You might also ask: “Can we create a problem record from an incident?” (Reference 21). Absolutely! If an issue is repeatedly occurring, an incident record is the perfect launching point for a problem. This is often achieved via a UI Action (a button on the incident form) which would trigger a script very similar to the one above, but it would also automatically link the original incident to the new problem record, perhaps using a field like problem_id on the incident table.

Example 3: Creating a Change Request Programmatically

Following our ITSM lifecycle, once a problem’s root cause is identified and a fix proposed, a change request is often the next step.

// 25) How to create change request using script?
// Answer) Using GlideRecord as follows

var grChange = new GlideRecord('change_request'); // Instantiate GlideRecord for the 'change_request' table
grChange.initialize();                           // Initialize a new change request record

// Set field values for the new change request
grChange.category = 'Infrastructure';           // Category of the change
grChange.subcategory = 'Patching';              // Subcategory
grChange.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_ID of the Configuration Item being changed
grChange.short_description = 'Patching server operating system for antivirus vulnerability'; // Concise summary
grChange.description = 'As a result of problem investigation PRB12345, it was determined that server OS patching is required to address the repeated antivirus service failures. This change will apply the latest security patches during the next maintenance window.'; // Detailed description
grChange.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_ID of the group responsible for executing the change

grChange.insert(); // Insert the new change request record into the database

gs.info("Change Request " + grChange.number + " created successfully!"); // Log a message with the change number
        

Just like with problem records, a change request can easily be spawned from an incident (Reference 22) if the support engineer immediately identifies that a software change is needed to resolve the issue. Scripting enables this seamless transition, ensuring traceability and process adherence.

Advanced Scripting Scenarios: Orchestrating Your ITSM Workflow

Creating individual records is powerful, but the real magic of scripting unfolds when you use it to automate and enforce complex business logic across interconnected records. These scenarios often involve Business Rules, which are server-side scripts that run when a record is displayed, inserted, updated, or deleted.

Scenario 1: Closing Child Incidents with a Parent Incident

Remember the definition of a problem where a single underlying issue causes multiple incidents? Often, a “parent incident” is created to track the overarching event, with individual “child incidents” linked to it. When the root cause is resolved and the parent incident is closed, it’s logical for all associated child incidents to also be closed, reflecting the resolution of the widespread impact.

// 26) Write a logic for whenever a parent incident is get closed all the child incidents should also get closed.
// Answer: Write an After Business Rule

// Business Rule Details:
// When: After
// Update: true
// Condition: current.state.changesTo(7) && current.parent.nil() (or current.parent == '')

// Script:
if (current.state == 7 && current.parent.nil()) { // Check if the current incident's state just changed to 7 (Closed) AND it is a parent (has no parent itself)
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for incidents where the 'parent' field matches the current parent incident's Sys ID
    grChild.query();                            // Execute the query

    while (grChild.next()) {                    // Loop through all found child incidents
        grChild.state = 7;                      // Set the state of each child incident to 7 (Closed)
        grChild.update();                       // Update the child incident record in the database
    }
}
        

Explanation:

• current.state.changesTo(7): This condition checks if the ‘state’ field of the current record (the incident being updated) has just changed *to* the value 7 (which typically represents ‘Closed’).
• current.parent.nil(): This ensures the script only runs for incidents that are *parents* (i.e., they don’t have a parent themselves). We don’t want child incidents closing their siblings!
• grChild.addQuery('parent', current.sys_id);: This is key. It filters for child incidents whose ‘parent’ field explicitly points to the Sys ID of the incident that just closed.
• grChild.update();: This is performed within the loop for each child incident, effectively closing them one by one.

This script exemplifies how automation ensures data consistency and reduces manual effort, especially during major service restoration.

Scenario 2: Preventing Closure with Open Tasks

Imagine an incident, problem, or change request that involves multiple smaller steps, tracked as “tasks.” It’s bad practice to close the main record if its associated tasks are still outstanding. Scripting can enforce this business rule, maintaining data integrity and ensuring all work is completed.

// 27) There is an incident and that incident has associated 2 tasks. When you try to close that incident,
// if any incident task is open, the employee should not close the incident. Similarly for problem, and change request.
// Answer: (This would be a Before Update Business Rule on the Incident table)

// Business Rule Details:
// When: Before
// Update: true
// Condition: current.state.changesTo(7) // Assuming 7 is the state value for 'Closed'

// Script:
// Use the appropriate task table: incident_task for incidents, problem_task for problems, change_task for changes
var grTask = new GlideRecord('incident_task'); // Instantiate GlideRecord for 'incident_task' table
grTask.addQuery('incident', current.sys_id); // Query for tasks associated with the current incident
grTask.addQuery('state', '!=', 3);           // Add a condition: where the task's state is NOT 3 (assuming 3 is 'Closed' for tasks)
grTask.query();                              // Execute the query

if (grTask.hasNext()) {                      // If the query finds any open tasks...
    gs.addErrorMessage('Cannot close the incident because there are open tasks. Please complete all tasks first.'); // Display an error message to the user
    current.setAbortAction(true);            // Prevent the incident from being saved/closed
}
        

Explanation:

• When: Before: This is critical. The script runs *before* the record is saved, allowing us to stop the save operation if conditions aren’t met.
• grTask.addQuery('state', '!=', 3);: This filters for tasks that are *not* in the closed state.
• grTask.hasNext();: This checks if the query returned any results. If it did, it means there are open tasks.
• gs.addErrorMessage(...): Displays a user-friendly message at the top of the form.
• current.setAbortAction(true);: This powerful command halts the current database operation (the update in this case), preventing the incident from being closed.

This ensures that processes are followed rigorously and that no work slips through the cracks.

Scenario 3: Closing Associated Incidents when a Problem is Resolved

This is a cornerstone of effective Problem Management. Once you’ve identified and fixed the root cause of a problem, all the incidents that were *caused* by that problem should logically be closed. This demonstrates the value of Problem Management by showing its direct impact on service restoration.

// 28) Whenever a problem is closed, the associated incident will also get closed.
// Answer: (This would be an After Update Business Rule on the Problem table)

// Business Rule Details:
// When: After
// Update: true
// Condition: current.state.changesTo(7) // Assuming 7 is the state value for 'Closed' on Problem records

// Script:
if (current.state == 7) { // Check if the current problem's state just changed to 7 (Closed)
    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Query for incidents where the 'problem_id' field matches the current problem's Sys ID
    grIncident.addQuery('state', '!=', 7);             // Add a condition: only close incidents that are NOT already closed
    grIncident.query();                                // Execute the query

    while (grIncident.next()) {                        // Loop through all found associated incidents
        grIncident.state = 7;                          // Set the state of each incident to 7 (Closed)
        grIncident.update();                           // Update the incident record in the database
    }
}
        

Explanation:

• current.state == 7: Checks if the problem record being updated has its state set to ‘Closed’.
• grIncident.addQuery('problem_id', current.sys_id);: This is how incidents are linked to problems. The `problem_id` field on the incident table holds the Sys ID of the problem that caused it.
• grIncident.addQuery('state', '!=', 7);: Prevents redundant updates on incidents that are already closed, improving script efficiency.

This script beautifully illustrates the downstream impact of effective problem resolution, cleaning up related records automatically and reflecting the true state of service.

Essential Scripting Concepts & Platform Nuances

Out-of-the-Box (OOTB) vs. Custom Tables

Out-of-the-Box Tables: The tables which don’t start with x_ or u_. For example, incident. x_ means if the table is created in a scoped application.

When you’re working with an ITSM platform, you’ll encounter tables that are provided “out-of-the-box” (OOTB) and those that are custom. OOTB tables like incident, problem, and change_request are designed to adhere to industry best practices and often come with pre-built functionality. Custom tables usually start with a prefix like u_ (for global scope) or x_ (for scoped applications). While custom tables offer flexibility, always prefer OOTB tables when they meet your needs, as they benefit from platform upgrades and extensive documentation.

Base Tables and Task Tables: The Foundation

Base Tables: Tables like task, cmdb_ci. These tables don’t extend any other table but are extended by many tables.

Examples of Task Tables: incident, problem, change_request, which are extending the task table.

Understanding table inheritance is crucial. The task table is a prime example of a base table. It doesn’t extend from anything else, but many other tables—like incident, problem, and change_request—extend from it. This means they inherit all the fields and functionalities of the task table (e.g., State, Assignment Group, Short Description). This common foundation allows for consistent reporting and simplified scripting across different types of “tasks.”

The cmdb_ci (Configuration Item) table is another critical base table. It’s the repository for all your IT assets and services, and linking incidents, problems, and changes to CIs provides context and helps understand impact.

Multiple Ways to Create Records

Ways to Create Records: Record Producer, Email, GlideRecord, Form, and Excel sheet, from external system as well.

While scripting with GlideRecord is powerful for automation, it’s just one way to get data into your system:

• Form: The most common method, used by end-users and IT staff directly through the UI.
• Record Producer: A specific type of catalog item that allows end-users to create records (often incidents or tasks) from a simplified, user-friendly form in the service portal.
• Email: Inbound email actions can parse incoming emails and create records (e.g., incidents from support emails).
• Excel Sheet (Import): For bulk data loading, often used during initial setup or migrations.
• External System: Through APIs or integrations, data can flow in from other tools (e.g., monitoring systems, HR platforms).

The `current` Object: Your Contextual Companion

Current Object: It is used to set and get the values on the form at the server side.

In server-side scripts like Business Rules, the current object is your window into the record that triggered the script. It holds all the field values of that record as it exists *during the execution of the script*. This allows you to inspect its values (e.g., current.state), and even modify them (e.g., current.state = 'Closed').

Setting Field Values with `current`

How to set the field values on the current form: current.setValue('field_name', value); If we are writing this for a reference type of field, then we should give sys_id in place of value. current.setDisplayValue('field_name', value); Here if a reference field, give value as value only, not sys_id.

While direct assignment (current.field_name = 'value';) often works, setValue() and setDisplayValue() offer more robust control, especially for reference fields:

• current.setValue('caller_id', '86826bf03710200044e0bfc8bcbe5d94');: This is the preferred way to set a reference field, always using the Sys ID. It’s explicit and handles underlying data types correctly.
• current.setDisplayValue('caller_id', 'John Doe');: This is useful when you have the display name but not the Sys ID. The system will look up the Sys ID corresponding to that display name and set the reference field accordingly. Use with caution, as non-unique display names can lead to unexpected results.

For non-reference fields, direct assignment like current.short_description = 'My new short description'; is perfectly fine and commonly used.

Troubleshooting Common Scripting Issues: When Things Go Wrong

Even the most seasoned developers encounter issues. Here’s a quick guide to common pitfalls and how to approach them:

• Sys ID Mismatches: The most common culprit for reference fields not populating. Double-check that the Sys ID you’re using is correct for the target record. Use the global search, a list view, or background scripts to verify Sys IDs.
• Field Name Typos: A single character off can break your script. Ensure `short_description` isn’t `shortdescription` or `short_desc`. Check the field’s actual ‘Name’ in the dictionary.
• Business Rule Order & Conditions: If your script isn’t running, check the “Order” of your Business Rule (lower numbers run first). Ensure your “When” condition (Before/After/Async) and “Condition” script (e.g., `current.state.changesTo(7)`) are precisely met.
• Infinite Loops (Especially with `update()`): If an “After” Business Rule triggers an `update()` on the *same record* that triggered it, without proper conditions, it can create an infinite loop. Always ensure your `update()` statements are carefully considered or apply to *other* records.
• Permissions: The user context under which your script runs might not have the necessary permissions to read or write to certain tables or fields. Check ACLs (Access Control Lists).
• Debugging:
  • gs.log('Your message here'); or gs.info('My variable value: ' + myVar);: The workhorse of server-side debugging. These messages appear in the System Logs.
  • Script Debugger: For interactive debugging, platforms like ServiceNow offer a Script Debugger that allows you to set breakpoints and step through your code.
  • Background Scripts: A fantastic way to test small snippets of code and `GlideRecord` queries in isolation without affecting production records.
• Missing `initialize()` or `insert()`: If you’re creating new records and nothing appears, verify these two essential `GlideRecord` calls are present.

Interview Relevance: A Glimpse into Technical Acumen

Every concept and script we’ve discussed is prime material for technical interviews. Being able to articulate these points demonstrates a strong understanding of ITSM processes and the underlying technical capabilities of the platform.

Interviewers often look for:

• Conceptual Clarity: Can you clearly differentiate between an Incident, Problem, and Change? Do you understand *why* they are distinct but related?
• `GlideRecord` Proficiency: Can you explain how to create, query, and update records using `GlideRecord`? What’s the purpose of `initialize()`, `addQuery()`, `query()`, `next()`, and `insert()`/`update()`?
• `current` and `gs` Objects: Do you know when and how to use `current` (for the triggering record) and `gs` (for global system functions like logging or error messages)?
• Business Rule Logic: Can you describe the “When” options for Business Rules and how they impact script execution? How would you use a Business Rule to enforce a specific workflow, like preventing closure with open tasks?
• Problem-Solving Scenarios: You’ll likely be asked to “write a logic” for scenarios similar to closing child incidents or associated incidents/tasks. Focus on explaining your thought process, choice of `GlideRecord` operations, and Business Rule configuration.
• Best Practices: Mentioning the importance of using `sys_id` for reference fields, logging for debugging, and considering performance implications (e.g., avoiding too many `update()` calls in loops) will set you apart.