Skip to main content

ITSM: Real-World Scenarios for Developer Practice

Mastering ServiceNow ITSM: Real-World Scenarios for Developer Practice

1. Introduction: Setting the Stage for Mastering ServiceNow ITSM with Real-World Practice
This report is designed to guide a 3-year ServiceNow developer towards a deeper understanding of IT Service Management (ITSM) within the ServiceNow platform. By exploring realistic, hands-on scenarios, the aim is to enhance practical skills, boost confidence for interviews, and provide insights into the demands of service-based company projects. A strong grasp of real-world applications is invaluable for any ServiceNow professional looking to advance their career. This document will cover the core ITSM modules, including Incident Management, Problem Management, Change Management, Service Catalog, Knowledge Management, and Configuration Management (CMDB). Each module's section will follow a structured approach, presenting a real-time scenario, followed by detailed assignment questions designed to test and build your development skills. Clear problem-solving techniques will be provided for each question, offering a pathway to finding solutions within the ServiceNow environment or through related research.
2. Incident Management: Mastering Service Disruptions

  • Real-time Scenario 1: High-Priority Incident - Critical Business Service Outage
    • Scenario Description: Imagine a scenario where a core business application, essential for the global sales team, suddenly becomes unavailable. Users across all regions are unable to access crucial customer data, leading to an immediate halt in sales activities and potential significant financial losses. The initial notification of this disruption arrives through an automated monitoring system, quickly followed by a surge of calls to the service desk from frustrated users. This situation demands immediate and effective handling to minimize the impact on the business.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Design a business rule that automatically sets the priority of an incident to 'Critical' (Priority 1) when the 'Service' field is 'Global Sales Application' and the 'Impact' is 'High' and 'Urgency' is 'High'. provides a framework for understanding the relationship between impact, urgency, and priority.
        • Problem-Solving Technique: Navigate to 'System Definition > Business Rules' within your ServiceNow instance. Create a new business rule that is configured to run 'Before Insert' on the 'Incident' table. In the 'When to run' section, define the condition such that the rule executes only when the 'Service' field is 'Global Sales Application', and the 'Impact' and 'Urgency' fields are both set to 'High'. In the 'Actions' section, use the 'Set field values' option to automatically set the 'Priority' field to '1 - Critical'.
      • (Question 2): Configure an email notification to be sent to the 'IT Operations Management' assignment group and the application owner when a Priority 1 incident is created for the 'Global Sales Application'. outlines the steps for delivering email notifications based on record updates.
        • Problem-Solving Technique: Go to 'System Notification > Email > Notifications' and create a new notification. Set the 'Table' to 'Incident'. In the 'When to send' section, specify that the notification should be triggered when a record is 'Inserted' and the 'Priority' is '1 - Critical' and the 'Service' is 'Global Sales Application'. In the 'Who will receive' section, select the 'IT Operations Management' group from the 'Groups' list and identify the application owner (this might involve referencing a user record or a custom field). In the 'What it will contain' section, customize the email subject and body to provide relevant information about the critical incident.
      • (Question 3): Implement a UI policy to make the 'Business Impact' and 'Downtime Start Time' fields mandatory when the incident priority is 'Critical'.
        • Problem-Solving Technique: Navigate to 'System UI > UI Policies' and create a new UI policy on the 'Incident' table. In the 'When to apply' section, set the condition to 'Priority' is '1 - Critical'. In the 'UI Policy Actions' section, add two actions: one to make the 'Business Impact' field 'Mandatory' and another to make the 'Downtime Start Time' field 'Mandatory'. Ensure the 'Applies on load' and 'Applies to all views' options are selected as needed.
      • (Question 4): Create a report showing the number of open Priority 1 incidents for the last week, grouped by 'Assignment Group'. details the process of creating reports on the incident table.
        • Problem-Solving Technique: Go to 'Reports > Create New'. Select the 'Incident' table as the 'Source type'. Choose a report type like 'Bar' or 'Column'. In the 'Filters' section, add conditions to show incidents where the 'Priority' is '1 - Critical' and the 'State' is not 'Closed' or 'Resolved', and the 'Created' date is within the 'Last 7 days'. In the 'Group by' section, select 'Assignment Group'. Run the report to view the results.
      • (Question 5): Configure an SLA definition with a 4-hour resolution time for Priority 1 incidents. Ensure that warning and breach notifications are sent at 50% and 90% of the SLA duration to the assigned-to person and their manager. mentions the configuration of SLA reports and notifications.
        • Problem-Solving Technique: Navigate to 'Service Level Management > SLA Definition' and create a new SLA. Set the 'Table' to 'Incident'. In the 'Start condition' section, specify that the SLA should start when the 'Priority' is '1 - Critical' and the 'Active' field changes to 'True'. Set the 'Stop condition' to when the 'State' is 'Resolved'. Define the 'Resolution time' as 4 hours. In the 'SLA Actions' section, configure two 'Warning' actions: one to trigger at 50% of the duration and send a notification to the 'Assigned to' person and their manager, and another 'Breach' action to trigger at 90% of the duration and send a notification to the same recipients.
    • Problem-Solving Techniques and Approaches: The assignments above require familiarity with core ServiceNow configurations. When designing the business rule, consider the order of execution and ensure it doesn't conflict with other rules. For notifications, pay attention to the recipient selection and the content of the email. UI policies should be carefully crafted to ensure they apply only under the intended conditions. Report creation involves selecting the correct table, applying appropriate filters, and choosing the right grouping. SLA configuration requires understanding start and stop conditions, setting durations, and defining actions for warnings and breaches.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: The immediate outage of a critical business application highlights the direct link between IT service availability and business operations. The inability of the sales team to access customer data directly translates to lost revenue and damaged customer relationships. Establishing automated priority setting ensures that such high-impact incidents are immediately recognized and treated with the necessary urgency, minimizing potential financial and reputational damage. Sending timely notifications to the IT operations team and the application owner facilitates rapid collaboration and speeds up the diagnostic and resolution processes. Making 'Business Impact' and 'Downtime Start Time' mandatory for critical incidents ensures that crucial information for understanding the severity and duration of the outage is captured accurately from the outset, which is vital for post-incident analysis and service improvement. Monitoring the number of open critical incidents provides a real-time pulse on the health of critical services, allowing IT leadership to make informed decisions about resource allocation and focus efforts on the most pressing issues. Defining and adhering to a strict SLA for critical incidents sets clear expectations for response and resolution, driving accountability within the IT organization and ensuring that service levels are maintained, ultimately contributing to improved user satisfaction.
    • Key Tables: Incident (incident), Business Rules (sys_script), Notifications (sysevent_email_action), UI Policies (sys_ui_policy), Reports (sys_report), SLA Definitions (contract_sla).
  • Real-time Scenario 2: Recurring Incident - Frequent User Login Issues
    • Scenario Description: The IT service desk has observed a consistent pattern of incidents over the past month where numerous users, spanning various departments, report being unable to log in to their corporate email accounts. The incident short description is invariably "Email Login Failure," indicating a potential underlying problem rather than isolated user issues.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Create a scheduled job that runs daily and identifies incidents with the short description "Email Login Failure" that have been resolved more than 5 times in the last 30 days. The job should log these recurring incidents in a custom table named 'Recurring Incident Candidates'.
        • Problem-Solving Technique: Navigate to 'System Definition > Scheduled Jobs' and create a new job. Set the 'Run' field to 'Daily'. In the 'Script' section, write a GlideRecord query on the 'Incident' table. Filter for incidents with the 'Short description' as 'Email Login Failure' and the 'Resolved at' date within the last 30 days. Use an aggregate function (like groupBy and count) to identify incidents with more than 5 resolutions. For each such incident, insert a record into your custom table 'Recurring Incident Candidates' (you'll need to create this table beforehand with appropriate fields, such as 'Incident Number' and 'Short Description').
      • (Question 2): Design a UI action on the 'Incident' form that, when clicked, checks if the current incident's short description matches any record in the 'Recurring Incident Candidates' table. If a match is found, display a warning message to the user, suggesting they create a problem record.
        • Problem-Solving Technique: Go to 'System UI > UI Actions' and create a new UI action on the 'Incident' table. Set the 'Client' field to 'True' and the 'Server' field to 'True'. In the 'Client script' section, get the current incident's short description. Use GlideAjax to call a script include (you'll need to create this) that queries the 'Recurring Incident Candidates' table for any matching short descriptions. In the 'Server script' section of the UI action, handle the GlideAjax response. If a match is found, use gs.addErrorMessage() in the client script to display the warning message suggesting the creation of a problem record.
      • (Question 3): Configure a metric definition to track the number of times an incident with the short description "Email Login Failure" is reopened after being resolved.
        • Problem-Solving Technique: Navigate to 'System Definition > Metric Definition' and create a new metric. Set the 'Table' to 'Incident' and the 'Field name' to 'State'. In the 'Conditions' section, specify that the metric should be created when the 'State' changes 'to' 'Reopened' and the 'Short description' is 'Email Login Failure'. This will track every instance an 'Email Login Failure' incident is reopened.
      • (Question 4): Create a report showing the trend of "Email Login Failure" incidents over the last 90 days, displaying the number of new incidents, reopened incidents, and resolved incidents each week.
        • Problem-Solving Technique: Go to 'Reports > Create New'. Select the 'Incident' table. Choose a 'Time Series' report type. In the 'Filters' section, set the 'Short description' to 'Email Login Failure' and the 'Created' date to be within the 'Last 90 days'. In the 'Configuration' section, select 'Calendar' as the 'Trend by' option and 'Week' as the 'Interval'. Add three aggregations: count of records where 'State' is 'New', count of records where 'State' is 'Reopened', and count of records where 'State' is 'Resolved'.
      • (Question 5): Implement a business rule that, when an incident with the short description "Email Login Failure" is resolved, checks if a related problem record exists. If not, display a work note reminding the resolver to consider creating a problem.
        • Problem-Solving Technique: Create a business rule on the 'Incident' table that runs 'Before Update'. In the 'When to run' section, specify that the rule should execute when the 'State' changes 'to' 'Resolved' and the 'Short description' is 'Email Login Failure'. In the 'Condition' section, use a GlideRecord query to check if any problem records exist where the 'Incident' field (or a similar relationship field) references the current incident. In the 'Actions' section, if no related problem record is found, use current.work_notes.addInfoMessage() to add a work note reminding the resolver to consider creating a problem record.
    • Problem-Solving Techniques and Approaches: These assignments focus on identifying patterns in incident data and proactively addressing them. Scheduled jobs are useful for background processing and data analysis. UI actions provide interactive capabilities for users. Metric definitions allow tracking specific events in the incident lifecycle. Reporting is essential for visualizing trends. Business rules can automate checks and provide reminders to users or resolvers.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: The repeated occurrence of "Email Login Failure" incidents across various departments strongly suggests a systemic issue within the email infrastructure or authentication process, rather than isolated user errors. Identifying these recurring incidents through a scheduled job allows for a shift from simply reacting to individual occurrences to proactively investigating the underlying cause. The UI action serves as an immediate prompt for service desk analysts, encouraging them to escalate potential problems, thus fostering a culture of proactive problem management. Tracking reopened incidents for this specific issue provides a metric to gauge the effectiveness of the initial resolutions and further highlights the need for a permanent fix. Analyzing the trend over time can reveal if the problem is worsening, improving, or fluctuating, potentially correlating with other events or changes in the IT environment. The business rule acts as a final check, ensuring that resolvers consider the possibility of a broader problem even when resolving individual incidents, thereby reinforcing the link between incident and problem management.
    • Key Tables: Incident (incident), Scheduled Jobs (sysauto), Recurring Incident Candidates (custom table), UI Actions (sys_ui_action), Script Include (sys_script_include), GlideAjax (GlideAjax), Metric Definition (metric_definition), Reports (sys_report), Problem (problem).
  • Real-time Scenario 3: Incident Requiring Escalation - Complex Application Error
    • Scenario Description: A user reports a persistent and intricate error within a specialized financial reporting application. The initial service desk analyst has diligently followed standard troubleshooting procedures and consulted the knowledge base, but the issue remains unresolved. The analyst now suspects that the problem lies within the application's code or configuration and requires the specific expertise of the application development team.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Configure an assignment rule that automatically assigns incidents with the category 'Application Error' and sub-category 'Financial Reporting' to the 'Financial Application Support' assignment group.
        • Problem-Solving Technique: Navigate to 'Incident > Administration > Assignment Rules' and create a new assignment rule. Set the 'Order' to ensure it's evaluated appropriately. In the 'Filter conditions' section, specify that the rule should apply when the 'Category' is 'Application Error' and the 'Sub-category' is 'Financial Reporting'. In the 'Assign to' section, select the 'Financial Application Support' group in the 'Assignment group' field. Ensure the 'Active' checkbox is selected.
      • (Question 2): Implement a workflow that triggers when an incident with the 'Financial Application Support' assignment group is in the 'Work in Progress' state for more than 8 hours without any updates to the 'Work notes' field. The workflow should automatically escalate the incident priority to 'High' and send a notification to the assignment group manager.
        • Problem-Solving Technique: Open 'Flow Designer' and create a new flow. Set the 'Trigger' to 'Record Updated' on the 'Incident' table. Add a 'Condition' to check if the 'Assignment group' is 'Financial Application Support' and the 'State' is 'Work in Progress'. Add a 'Wait for duration' activity set to 8 hours. After the wait, add another 'Condition' to check if the 'Work notes' field has not been updated within the last 8 hours (you might need to use a script for this). If the condition is met, add an 'Update Record' activity to set the 'Priority' of the incident to 'High', and a 'Send Email' activity to notify the manager of the 'Financial Application Support' group.
      • (Question 3): Create a business rule that prevents the state of an incident from being changed back to 'New' or 'In Progress' once it has been assigned to the 'Financial Application Support' group, unless the user has the 'itil_admin' role.
        • Problem-Solving Technique: Navigate to 'System Definition > Business Rules' and create a new rule on the 'Incident' table. Set the 'When to run' to 'Before Update'. In the 'Condition' section, check if the 'Assignment group' has changed 'to' 'Financial Application Support' and if the new 'State' is 'New' or 'In Progress'. In the 'Script' section, use if (gs.hasRole('itil_admin')) { return; } else { current.setAbortAction(true); gs.addErrorMessage('Incidents assigned to Financial Application Support cannot be moved back to New or In Progress.'); }.
      • (Question 4): Design a UI policy that displays an additional field called 'Escalation Reason' when the incident priority is changed to 'High' by the system (e.g., through the workflow in Question 2).
        • Problem-Solving Technique: Navigate to 'System UI > UI Policies' and create a new UI policy on the 'Incident' table. In the 'When to apply' section, set the condition to 'Priority' 'changes to' 'High'. Add a condition to check if the update was made by the system (you might need to check the 'Updated by' field or use a custom field set by the workflow). In the 'UI Policy Actions' section, make the 'Escalation Reason' field 'Visible' and optionally 'Mandatory'.
      • (Question 5): Configure an on-call schedule for the 'Financial Application Support' group and ensure that the escalated incident notification (from Question 2) also includes the on-call member. provides information on designing escalation processes with on-call schedules.
        • Problem-Solving Technique: Navigate to 'On-Call Scheduling > Schedules' and create a new schedule for the 'Financial Application Support' group, adding the relevant members and their rotation. In the 'Send Email' activity of the workflow created in Question 2, use a script to retrieve the current on-call member for the 'Financial Application Support' group using the SncOnCallRotation API and add them to the 'To' or 'Cc' list of the notification.
    • Problem-Solving Techniques and Approaches: These assignments involve routing incidents to the correct teams, automating escalations based on predefined criteria, ensuring process adherence through business rules, enhancing user experience with UI policies, and leveraging on-call schedules for timely support.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: When a service desk analyst encounters a complex application error that surpasses their troubleshooting capabilities, the incident requires escalation to a specialized team like 'Financial Application Support'. Configuring assignment rules ensures that such incidents are automatically routed to the appropriate experts, reducing the time it takes to reach the right resources. Implementing a workflow to automatically escalate incidents based on inactivity within the specialized group ensures that incidents don't remain stagnant and receive timely attention, potentially indicating a need for further intervention or a different level of expertise. The business rule preventing unauthorized state changes maintains the integrity of the incident handling process by ensuring that once an incident is escalated, it remains with the specialized team until resolution, unless an administrator intervenes. Displaying an 'Escalation Reason' field when the priority is automatically increased provides valuable context for understanding why the escalation occurred, which can be useful for identifying trends or areas where initial support processes might need improvement. Integrating on-call schedules with escalation notifications ensures that even outside of regular business hours, the appropriate on-call personnel within the specialized team are alerted to critical issues, ensuring timely support and minimizing potential delays in resolution.
    • Key Tables: Incident (incident), Assignment Rules (sys_assignment_rule), Workflow (wf_workflow), Business Rules (sys_script), UI Policies (sys_ui_policy), On-Call Schedule (cmn_schedule), User (sys_user).
  • Understanding the Incident Resolution Lifecycle and Key Data Points:
    • The typical stages of the incident lifecycle in ServiceNow generally include: New, where the incident is initially logged; In Progress, indicating that work is being actively performed on the incident; On Hold, used when the resolution is pending external factors or user input; Resolved, signifying that a solution has been implemented and the service is restored; and Closed, the final stage where the user has confirmed the resolution and the incident is considered complete.
    • Capturing key data points throughout this lifecycle is crucial for effective incident management and future analysis. Caller information identifies who is affected. The short description and detailed description provide context about the issue. Category and sub-category help classify the incident for routing and reporting. Impact and urgency determine the incident's priority. The assignment group and assigned to fields track ownership. Work notes and the activity log document the troubleshooting steps and communication. The resolution code and resolution notes explain how the issue was fixed. Finally, closure codes indicate the outcome of the incident.
    • This comprehensive data is invaluable for generating reports on incident trends, identifying recurring problems that might require problem management intervention, measuring the performance of IT support teams against SLAs, and continuously improving the incident management process to enhance efficiency and user satisfaction. By analyzing this information, organizations can make data-driven decisions to optimize their IT service delivery.

3. Problem Management: Uncovering and Eliminating Root Causes

  • Real-time Scenario: Multiple Related Incidents - Intermittent Network Connectivity Problems
    • Scenario Description: Over the past two weeks, the service desk has been inundated with incidents from users across various office locations reporting intermittent loss of network connectivity. Users experience temporary disconnections from network resources, leading to disruptions in their work and decreased productivity. Upon investigation, several of these incidents have been linked to the same configuration item – the main office router.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Configure a business rule that automatically suggests creating a problem record when three or more incidents are linked to the same configuration item (CI) within a 7-day period. The suggestion should appear as a 'Related Link' on the incident form. indicates the possibility of linking incidents to problem records.
        • Problem-Solving Technique: Create a business rule on the 'Incident' table that runs 'After Insert or Update'. In the 'Condition' section, check if the 'Configuration item' field is not empty. In the 'Script' section, query the 'Incident' table for other open incidents where the 'Configuration item' matches the current incident's 'Configuration item' and the 'Created' date is within the last 7 days. If the count of such incidents is three or more, use the action.addRelatedListEntry() method to add a 'Create Problem' related link to the incident form.
      • (Question 2): Implement a workflow that triggers when a problem record is created with a 'Cause' of 'Network Infrastructure' and automatically assigns it to the 'Network Engineering' assignment group.
        • Problem-Solving Technique: Open 'Flow Designer' and create a new flow. Set the 'Trigger' to 'Record Created' on the 'Problem' table. Add a 'Condition' to check if the 'Cause' field on the problem record is 'Network Infrastructure'. Add an 'Update Record' activity to set the 'Assignment group' field of the problem record to 'Network Engineering'.
      • (Question 3): Design a UI policy on the 'Problem' form that makes the 'Workaround' field mandatory when the 'State' is changed to 'Known Error'. highlights the documentation of workarounds for known errors.
        • Problem-Solving Technique: Navigate to 'System UI > UI Policies' and create a new UI policy on the 'Problem' table. In the 'When to apply' section, set the condition to 'State' 'is' 'Known Error'. In the 'UI Policy Actions' section, make the 'Workaround' field 'Mandatory'.
      • (Question 4): Create a UI action on the 'Problem' form that allows a user to easily create a 'Known Error' knowledge article from the problem record, pre-populating the article with the problem's 'Short description', 'Cause', and 'Workaround' information. describes the process of creating known error articles.
        • Problem-Solving Technique: Go to 'System UI > UI Actions' and create a new UI action on the 'Problem' table. Set the 'Client' field to 'False' and the 'Server' field to 'True'. In the 'Script' section, use GlideRecord to create a new record in the 'kb_knowledge' table. Set the 'short_description' field to current.short_description, the 'text' field to a combination of current.cause and current.workaround, and the 'kb_knowledgebase' field to the appropriate knowledge base for known errors. Use action.setRedirectURL() to redirect the user to the newly created knowledge article.
      • (Question 5): Configure a report showing the number of open problem records related to 'Network Infrastructure' over the last month, broken down by 'State' and 'Assignment Group'.
        • Problem-Solving Technique: Go to 'Reports > Create New'. Select the 'Problem' table. Add a filter where 'Cause' is 'Network Infrastructure' and 'State' is not 'Closed' or 'Resolved', and the 'Created' date is within the 'Last 30 days'. Create a 'Pivot Table' report. In the 'Rows' section, add 'State'. In the 'Columns' section, add 'Assignment Group'. In the 'Aggregation' section, select 'Count'.
    • Problem-Solving Techniques for Root Cause Analysis, Workaround Implementation, and Permanent Fix Deployment: Effective problem management involves a systematic approach. Identifying patterns in incidents, as demonstrated by the business rule, is the first step. Documenting workarounds provides temporary solutions to mitigate the impact. Root cause analysis (RCA) aims to identify the fundamental reason for the problem's occurrence. Implementing a permanent fix, often through the change management process, resolves the root cause and prevents recurrence.
    • Leveraging ServiceNow Features for Effective Problem Management: ServiceNow provides several features to support problem management. Problem tasks can be used to break down the investigation into smaller, manageable steps. The platform offers tools for documenting root cause analysis findings. The Known Error Database (KEDB) stores information about known problems and their workarounds, enabling faster resolution of related incidents. Integration with Change Management is crucial for deploying permanent fixes identified during problem investigation.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: The scenario of multiple users experiencing intermittent network connectivity issues, all linked to the same router, strongly suggests a fundamental flaw or misconfiguration within the network infrastructure. The automated suggestion to create a problem record based on linked incidents helps in proactively identifying such underlying issues before they escalate into widespread outages. By automatically assigning network-related problems to the 'Network Engineering' group, the resolution process is expedited by ensuring the right expertise is involved from the beginning. Making the 'Workaround' field mandatory when a problem is marked as a 'Known Error' ensures that a temporary solution is documented and readily available to service desk analysts, minimizing the impact on users. Creating a 'Known Error' knowledge article directly from the problem record facilitates the dissemination of information about the issue and its workaround to a wider audience, empowering users and service desk personnel to resolve future occurrences more efficiently. Tracking open problem records related to network infrastructure provides valuable insights into the ongoing issues within that area, allowing IT management to prioritize resources and efforts for permanent resolution.
    • Key Tables: Incident (incident), Problem (problem), Business Rules (sys_script), Workflow (wf_workflow), UI Policies (sys_ui_policy), UI Actions (sys_ui_action), Knowledge Base (kb_knowledge).

4. Change Management: Navigating the Landscape of IT Modifications

  • Real-time Scenario 1: Standard Change - Monthly Server Patching
    • Scenario Description: The IT department has a well-defined process for applying security patches to all Windows servers on a monthly basis. This is considered a routine and low-risk activity with pre-approved steps and a documented procedure.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Create a standard change proposal for "Monthly Windows Server Patching." Define the pre-approved steps, roles and responsibilities, and the standard risk assessment (low risk, minimal impact). provides details on the standard change template proposal process.
        • Problem-Solving Technique: Navigate to 'Change > Administration > Standard Change Proposals' and create a new proposal. Provide a concise 'Title' like "Monthly Windows Server Patching" and a detailed 'Description'. In the 'Implementation Plan', 'Backout Plan', and 'Test Plan' sections, outline the pre-approved steps for each phase. Define the 'Risk' as 'Low' and the 'Impact' as 'Minor' or 'Low'. Specify the 'Roles' responsible for each step (e.g., Server Operations for implementation, Security Operations for verification).
      • (Question 2): Configure a standard change template based on the proposal in Question 1. Ensure that when a user selects this template from the service catalog, the change request is automatically created and moved to the 'Scheduled' state without requiring further approvals. illustrates the workflow for standard changes.
        • Problem-Solving Technique: Once the proposal is approved, navigate to 'Change > Administration > Standard Change Templates' and create a new template. Link it to the "Monthly Windows Server Patching" proposal. Pre-populate fields like 'Change type' to 'Standard' and 'Assignment group' to 'Server Operations'. In the 'Workflow' section, ensure it's configured to bypass the 'Assessment' and 'Authorization' stages and directly proceed to 'Scheduled'.
      • (Question 3): Design a service catalog item that allows users (with the 'itil' role) to initiate the "Monthly Windows Server Patching" standard change. The catalog item should display a field to select the target servers. mentions initiating standard changes from the service catalog.
        • Problem-Solving Technique: Go to 'Service Catalog > Catalog Definitions > Maintain Items' and create a new item under an appropriate catalog and category (e.g., IT Services > Change Requests). Provide a 'Name' like "Monthly Windows Server Patching". Add a variable of type 'Reference' named "Target Servers" that points to the 'Configuration Item' table (cmdb_ci) with a filter to show only Windows servers (sys_class_name=cmdb_ci_win_server).
      • (Question 4): Implement a business rule that automatically creates 'Change Tasks' for the 'Server Operations' group to perform the patching and for the 'Security Operations' group to verify the patching after the change request reaches the 'Implement' state.
        • Problem-Solving Technique: Create a business rule on the 'Change Request' table that runs 'After Update'. In the 'Condition' section, check if the 'Change type' is 'Standard' and the 'State' changes 'to' 'Implement'. In the 'Script' section, use GlideRecord to create two 'Change Task' records. For the first task, set the 'change_request' to the current change request, 'assignment_group' to 'Server Operations', and 'short_description' to "Perform Monthly Windows Server Patching". For the second task, set the 'change_request', 'assignment_group' to 'Security Operations', and 'short_description' to "Verify Monthly Windows Server Patching".
      • (Question 5): Create a report showing the number of "Monthly Windows Server Patching" standard changes implemented in the last 6 months, grouped by the month of implementation and the success rate (based on the 'Close code').
        • Problem-Solving Technique: Go to 'Reports > Create New'. Select the 'Change Request' table. Add a filter where 'Change type' is 'Standard' and the 'Short description' contains "Monthly Windows Server Patching", and the 'Closed at' date is within the 'Last 6 months'. Create a 'Grouped' report (e.g., a bar chart). Group by the 'Closed at' field (select 'Month' as the display). Add a second level of grouping by 'Close code' to see the success rate (e.g., 'Success', 'Failure').
    • Problem-Solving Techniques for Standard Change Implementation and Automation: These assignments focus on defining and automating a routine change. Standard change proposals and templates are key for pre-approval and consistency. Service catalog integration provides a user-friendly way to initiate the change. Business rules automate the creation of necessary tasks. Reporting allows for tracking and analysis of standard change execution.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: The implementation of monthly server patching as a standard change demonstrates a proactive approach to maintaining system security and stability. By pre-approving this low-risk activity and automating its execution, the IT department can ensure consistent application of critical updates without the need for individual approvals for each change. Providing a service catalog item for initiating this standard change empowers authorized users to schedule the patching as needed, improving efficiency and reducing manual effort. Automating the creation of change tasks ensures that all necessary steps, including the patching itself and the subsequent verification, are performed consistently and tracked within the system. Reporting on the number and success rate of these standard changes provides valuable metrics for monitoring the effectiveness of the patching program and identifying any potential issues. This streamlined process for standard changes allows the Change Advisory Board (CAB) to focus its attention on more complex and higher-risk changes, optimizing the overall change management process.
    • Key Tables: Change Request (change_request), Standard Change Proposal (std_change_proposal), Standard Change Template (std_change_template), Service Catalog Item (sc_cat_item), Business Rules (sys_script), Change Task (change_task).
  • Real-time Scenario 2: Normal Change - Implementing a New Software Application
    • Scenario Description: The marketing department has requested the deployment of a new customer relationship management (CRM) software application to enhance their campaign management and customer engagement capabilities. This is considered a normal change due to its potential impact on multiple departments and the need for thorough planning, assessment, and approvals.
    • Detailed Assignment Questions for a ServiceNow Developer (covering approval workflows, risk assessment, and backout planning):
      • (Question 1): Configure an approval workflow for normal change requests where the approval process involves the Change Manager, the Application Owner, and the CAB (Change Advisory Board). The workflow should trigger when a new normal change request is submitted and move to the 'Authorize' state after all approvals are received. describes the normal change request process.
        • Problem-Solving Technique: Open 'Flow Designer' and create a new workflow. Set the 'Trigger' to 'Record Created' on the 'Change Request' table with a condition that 'Type' is 'Normal'. Add three 'Approval - User' activities in sequence or parallel as per your organization's policy. The first activity should be for the Change Manager (you might need to query the 'sys_user' table based on role or group membership). The second should be for the Application Owner (this might involve a lookup based on the 'Configuration item' or a related service). The third should be for the CAB (you might need to select a CAB approval group). Configure the workflow to proceed to the 'Authorize' state after all approvals are 'Approved'.
      • (Question 2): Implement a risk assessment questionnaire for normal change requests. The questionnaire should include questions related to the complexity of the change, the potential impact on business services, and the availability of a backout plan. The risk level of the change should be automatically calculated based on the answers. mentions risk assessment tools in change management.
        • Problem-Solving Technique: Navigate to 'Change > Risk Assessment > Assessments' and create a new assessment for the 'Change Request' table. Define your questions (e.g., "Complexity of the change (Low/Medium/High)", "Number of business services potentially impacted (None/Minor/Significant)", "Is a backout plan documented and tested? (Yes/No)"). Assign risk scores to each answer option. Configure a business rule on the 'Change Request' table that runs 'On Change' of the assessment answers. In the script, calculate the total risk score based on the selected answers and update the 'Risk' field on the change request accordingly (you might need to define a mapping between risk scores and risk levels like 'Low', 'Moderate', 'High', 'Critical').
      • (Question 3): Design a UI policy to make the 'Backout Plan' field mandatory for all normal change requests with a 'High' or 'Critical' risk level before the change can move to the 'Implement' state. highlights the importance of planning documentation for normal changes.
        • Problem-Solving Technique: Navigate to 'System UI > UI Policies' and create a new UI policy on the 'Change Request' table. In the 'When to apply' section, set the condition to 'Type' is 'Normal' and 'Risk' is 'High' or 'Critical'. In the 'UI Policy Actions' section, make the 'Backout Plan' field 'Mandatory' when the 'State' is 'Scheduled' (or the state just before 'Implement' in your change model).
      • (Question 4): Create a change model for normal changes that defines the standard stages and transitions (e.g., New, Assess, Authorize, Scheduled, Implement, Review, Closed). Ensure that the approval workflow from Question 1 is associated with the 'Authorize' stage. mentions creating custom problem management models, a similar concept applies to change management.
        • Problem-Solving Technique: Navigate to 'Change > Administration > Change Models' and create a new change model named "Normal Change". Define the stages in the correct order (New, Assess, Authorize, Scheduled, Implement, Review, Closed). For the 'Authorize' stage, in the 'Entry conditions' or 'Activities' section, associate the approval workflow you created in Question 1.
      • (Question 5): Configure a notification to be sent to the 'Marketing Department Users' when the new CRM application implementation is successfully completed (change request is closed with a 'Success' close code).
        • Problem-Solving Technique: Navigate to 'System Notification > Email > Notifications' and create a new notification. Set the 'Table' to 'Change Request'. In the 'When to send' section, specify that the notification should be triggered when the 'State' changes 'to' 'Closed' and the 'Close code' is 'Success'. In the 'Who will receive' section, select the 'Marketing Department Users' group. Customize the email subject and body to inform them about the successful CRM implementation.
    • Problem-Solving Techniques for Managing Normal Changes: These assignments emphasize the structured and controlled approach required for significant IT changes. Approval workflows ensure proper authorization. Risk assessments help in understanding potential issues. Backout plans provide a safety net. Change models standardize the process. Notifications keep stakeholders informed.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Implementing a new CRM application, as a normal change, requires a structured approach due to its potential impact on various business processes. The multi-level approval workflow involving the Change Manager, Application Owner, and CAB ensures that the change is thoroughly reviewed and approved by all relevant stakeholders, minimizing the risk of unforeseen issues. The risk assessment questionnaire provides a systematic way to evaluate the potential impact and complexity of the CRM implementation, allowing for better planning and mitigation of identified risks. Mandating a backout plan for high-risk changes ensures that there is a documented procedure to revert the implementation if it fails, safeguarding business continuity. Utilizing a change model standardizes the process for all normal changes, ensuring consistency and adherence to best practices. Notifying the marketing department upon successful completion ensures that the requesting department is informed and can begin utilizing the new CRM system, improving communication and user satisfaction.
    • Key Tables: Change Request (change_request), Approval Workflow (wf_workflow), Risk Assessment (rm_assessment), UI Policies (sys_ui_policy), Change Model (change_model), Notifications (sysevent_email_action).
  • Real-time Scenario 3: Emergency Change - Addressing a Critical Security Vulnerability
    • Scenario Description: A severe security vulnerability has been discovered in a widely used web server, posing an immediate threat to the organization's data and systems. Immediate action is necessary to patch the server and mitigate the risk. This situation necessitates an emergency change.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Configure an emergency change approval workflow that requires approval from the Security Manager and the CAB before implementation. The workflow should trigger when a new emergency change request is submitted. outlines the approval process for emergency changes.
        • Problem-Solving Technique: Open 'Flow Designer' and create a new workflow. Set the 'Trigger' to 'Record Created' on the 'Change Request' table with a condition that 'Type' is 'Emergency'. Add two 'Approval - User' activities. The first should be for the Security Manager (query the 'sys_user' table based on role). The second should be for the CAB (select the CAB approval group). Configure the workflow to proceed to the 'Scheduled' state (or directly to 'Implement' based on your organization's policy) after both approvals are 'Approved'.
      • (Question 2): Implement a UI policy on the emergency change form to make the 'Justification for Emergency', 'Impact', and 'Backout Plan' fields mandatory upon submission. highlights the required fields for emergency change requests.
        • Problem-Solving Technique: Navigate to 'System UI > UI Policies' and create a new UI policy on the 'Change Request' table. In the 'When to apply' section, set the condition to 'Type' is 'Emergency' and 'State' is 'New'. In the 'UI Policy Actions' section, make the 'Justification for Emergency', 'Impact', and 'Backout Plan' fields 'Mandatory'.
      • (Question 3): Create a business rule that automatically sets the priority of an emergency change to 'Critical' upon submission.
        • Problem-Solving Technique: Create a business rule on the 'Change Request' table that runs 'Before Insert'. In the 'Condition' section, check if 'Type' is 'Emergency'. In the 'Actions' section, set the 'Priority' field to '1 - Critical'.
      • (Question 4): Design a UI action on the incident form that allows a user to create a related emergency change request, pre-populating the 'Configuration item' and 'Short description' from the incident. mentions creating emergency changes from incidents.
        • Problem-Solving Technique: Go to 'System UI > UI Actions' and create a new UI action on the 'Incident' table. Set 'Client' to 'False' and 'Server' to 'True'. In the 'Script' section, use GlideRecord to create a new 'Change Request' record. Set the 'type' to 'Emergency', 'configuration_item' to current.cmdb_ci, and 'short_description' to current.short_description. Use action.setRedirectURL() to redirect the user to the newly created emergency change request form.
      • (Question 5): Configure a notification to be sent to the CIO and the Security Team upon successful implementation (change request closed with 'Success') or unsuccessful implementation (change request closed with 'Failed') of an emergency change.
        • Problem-Solving Technique: Navigate to 'System Notification > Email > Notifications' and create two new notifications for the 'Change Request' table. For the first notification, set the 'When to send' condition to 'State' changes 'to' 'Closed' and 'Close code' is 'Success' and 'Type' is 'Emergency'. For the second, set the condition to 'State' changes 'to' 'Closed' and 'Close code' is 'Failed' and 'Type' is 'Emergency'. In the 'Who will receive' section for both, select the CIO and the Security Team (you might need to query the 'sys_user' table based on roles or group membership).
    • Problem-Solving Techniques for Handling Emergency Changes with Speed and Control: These assignments focus on the need for rapid response to critical issues while still maintaining necessary oversight. Emergency change workflows are streamlined for quick approvals. UI policies ensure essential information is captured. Business rules automate critical settings. UI actions facilitate quick creation of emergency changes from related incidents. Notifications keep key stakeholders informed.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Addressing a critical security vulnerability necessitates an expedited change process to minimize the potential for exploitation and data loss. The requirement for approval from the Security Manager and the CAB, even in an emergency, ensures that the proposed patch is reviewed and validated by the appropriate experts before implementation. Making fields like 'Justification for Emergency', 'Impact', and 'Backout Plan' mandatory ensures that the rationale for the urgent change and the potential consequences are clearly documented, along with a plan to revert if necessary. Automatically setting the priority to 'Critical' highlights the urgency of the change and ensures it receives immediate attention from IT teams. The ability to create an emergency change directly from an incident streamlines the process of addressing urgent issues identified through incident management. Notifying the CIO and the Security Team about the outcome of the emergency change ensures that leadership is aware of the critical situation and the actions taken to address it.
    • Key Tables: Change Request (change_request), Approval Workflow (wf_workflow), UI Policies (sys_ui_policy), Business Rules (sys_script), UI Actions (sys_ui_action), Notifications (sysevent_email_action), Incident (incident).

5. Service Catalog: Empowering Users with Self-Service Capabilities

  • Real-time Scenario 1: New Hardware Request - Employee Laptop Provisioning
    • Scenario Description: The organization wants to provide a user-friendly way for employees to request new laptops through the service portal. This process should allow employees to choose from a selection of approved laptop models, require their manager's approval, and initiate a series of fulfillment tasks for the asset management and procurement teams to provision and deliver the hardware.
    • Detailed Assignment Questions for a ServiceNow Developer (covering catalog item creation, workflow design, and fulfillment process):
      • (Question 1): Create a new catalog item named "Request New Laptop" under the "Hardware" category in the service catalog. Include variables for "Employee Name", "Department", "Preferred Laptop Model" (dropdown with options like "Standard", "High-Performance", "MacBook"), and "Reason for Request" (multi-line text). provides an overview of catalog items.
        • Problem-Solving Technique: Navigate to 'Service Catalog > Catalog Definitions > Maintain Items' and create a new catalog item. Choose an appropriate 'Catalog' (e.g., Service Catalog) and 'Category' (e.g., Hardware). In the 'Variables' tab, add the following variables:
          • 'Employee Name' (Single Line Text, mandatory).
          • 'Department' (Reference field pointing to the 'Department' table, mandatory).
          • 'Preferred Laptop Model' (Select Box, mandatory) with the following 'Choices': 'Standard', 'High-Performance', 'MacBook'.
          • 'Reason for Request' (Multi-line Text, mandatory).
      • (Question 2): Configure a workflow that triggers when the "Request New Laptop" catalog item is ordered. The workflow should include an approval activity for the user's manager. Upon approval, it should create a catalog task for the 'Asset Management' group to procure the laptop and another task for the 'Desktop Support' group to configure and deliver it. and describe workflows for service requests.
        • Problem-Solving Technique: Go to 'Service Catalog > Catalog Definitions > Maintain Items' and open the "Request New Laptop" item. In the 'Workflow' tab, select 'Create new workflow'. In the workflow editor, add a 'Manager Approval' activity (using the 'Requested for' field to identify the manager). Upon approval, add a 'Create Task' activity for the 'Asset Management' group with a 'Short description' like "Procure New Laptop for [Employee Name]". Add another 'Create Task' activity for the 'Desktop Support' group with a 'Short description' like "Configure and Deliver New Laptop to [Employee Name]". Ensure the workflow transitions correctly between these activities.
      • (Question 3): Implement a client script on the "Request New Laptop" catalog item to display a warning message if the user selects the "MacBook" model, informing them about a potential delay due to specific procurement processes.
        • Problem-Solving Technique: Open the "Request New Laptop" catalog item and navigate to the 'Client Scripts' tab. Create a new client script with 'Type' as 'onChange' and 'Field name' as 'Preferred Laptop Model'. In the 'Script' section, add the following code: function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading | | newValue === '') { return; } if (newValue == 'MacBook') { g_form.addInfoMessage('Please note that MacBook requests may experience a longer procurement time.'); } }
      • (Question 4): Create a record producer that allows IT staff to quickly log a new laptop request on behalf of an employee, pre-populating some fields like 'Requested for' and 'Department'. describes the functionality of record producers.
        • Problem-Solving Technique: Navigate to 'Service Catalog > Record Producers' and create a new record producer. Set the 'Table' to 'Request Item [sc_req_item]'. Add variables for 'Requested for' (Reference to 'User [sys_user]') and 'Department' (Reference to 'Department [cmn_department]'). In the 'Script' section, use the following code to map the record producer variables to the request item fields: current.request.requested_for = producer.requested_for; current.variables.employee_name = producer.requested_for.name; current.variables.department = producer.department; current.cat_item = 'YOUR_CATALOG_ITEM_SYS_ID'; // Replace with the sys_id of your "Request New Laptop" catalog item.
      • (Question 5): Configure a notification to be sent to the employee who requested the laptop when all the fulfillment tasks are completed and the overall request is closed.
        • Problem-Solving Technique: Navigate to 'System Notification > Email > Notifications' and create a new notification. Set the 'Table' to 'Request Item [sc_req_item]'. In the 'When to send' section, specify 'Record Updated' and add a condition where 'State' 'changes to' 'Closed Complete'. In the 'Who will receive' section, select 'Requested for' from the 'User' lookup. Customize the email subject and body to inform the employee that their laptop request has been fulfilled.
    • Problem-Solving Techniques for Streamlining Hardware Requests: These assignments involve creating a user-friendly request process, automating approvals and fulfillment, providing real-time user feedback, enabling efficient internal request logging, and keeping the requester informed about the status.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Providing a self-service catalog item for new hardware requests like laptops empowers employees to easily obtain the tools they need, reducing the burden on the IT support staff for basic requests. Automating the approval process through a workflow ensures that requests are properly authorized by the employee's manager before fulfillment begins, maintaining budgetary control and departmental oversight. Creating specific catalog tasks for the asset management and desktop support teams ensures that the different stages of the hardware provisioning process (procurement, configuration, and delivery) are handled by the appropriate teams, leading to a more efficient and streamlined fulfillment process. Implementing a client script to warn users about potential delays for certain laptop models, like MacBooks, manages expectations and provides transparency in the request process. Offering a record producer for IT staff to log requests on behalf of employees caters to scenarios where the employee might not have direct access to the service portal or needs assistance, ensuring that all requests are captured in the system. Sending a notification upon completion keeps the employee informed about the status of their request and enhances their overall experience with the IT service.
    • Key Tables: Service Catalog (sc_catalog), Catalog Item (sc_cat_item), Workflow (wf_workflow), Client Script (sys_script_client), Record Producer (sc_cat_item_producer), Notifications (sysevent_email_action), Request (sc_request), Requested Item (sc_req_item), Catalog Task (sc_task), User (sys_user), Department (cmn_department).
  • Real-time Scenario 2: Software Installation Request - Access to Specialized Software
    • Scenario Description: Employees across the organization require access to a variety of software applications to perform their job functions. The IT department wants to implement a self-service mechanism through the service catalog for employees to request software installation. This process should handle different approval requirements based on the software type and user role, and upon approval, trigger a task for the software deployment team to install the requested application. and describe the process of software installation requests through a service catalog.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Create a catalog item named "Request Software Installation" under the "Software" category. Include variables for "Employee Name", "Department", "Software Required" (reference to a custom 'Software Catalog' table), and "Business Justification".
        • Problem-Solving Technique: First, create a custom table named 'Software Catalog' with fields like 'Name' (String, unique), 'Description' (String), 'Approval Required' (Boolean), and 'Approval Group' (Reference to 'Group [sys_user_group]'). Then, navigate to 'Service Catalog > Catalog Definitions > Maintain Items' and create a new catalog item. Add the required variables, ensuring the 'Software Required' variable is a 'Reference' field pointing to your newly created 'Software Catalog' table.
      • (Question 2): Configure a workflow that triggers when the "Request Software Installation" catalog item is ordered. The workflow should check the 'Approval Required' field on the selected software from the 'Software Catalog' table. If approval is required, route it to the 'Approval Group' specified in the 'Software Catalog' table. Upon approval (or if no approval is needed), create a catalog task for the 'Software Deployment' group to install the software.
        • Problem-Solving Technique: Open 'Flow Designer' and create a new workflow. Set the 'Trigger' to 'Record Created' on the 'Requested Item [sc_req_item]' table with a condition that the 'Catalog Item' is "Request Software Installation". Add an 'Action' to 'Lookup Record' from the 'Software Catalog' table where 'Name' matches the selected software from the catalog item. Add a 'Decision' activity to check the 'Approval Required' field of the looked-up software record. If 'True', add a 'Group Approval' activity using the 'Approval Group' from the software record. After the approval (or if no approval was needed), add a 'Create Task' activity for the 'Software Deployment' group with a 'Short description' like "Install for [Employee Name]".
      • (Question 3): Implement a client script on the catalog item to dynamically display the description of the selected software from the 'Software Catalog' table when the user selects a software application.
        • Problem-Solving Technique: Open the "Request Software Installation" catalog item and navigate to the 'Client Scripts' tab. Create a new client script with 'Type' as 'onChange' and 'Field name' as 'Software Required'. In the 'Script' section, use GlideAjax to call a script include (you'll need to create this) that queries the 'Software Catalog' table based on the selected software name and returns the 'Description'. Use g_form.setValue() or update a UI element on the catalog item form to display the description.
      • (Question 4): Create a UI policy to make the "Business Justification" field mandatory if the selected software requires approval.
        • Problem-Solving Technique: Open the "Request Software Installation" catalog item and navigate to the 'UI Policies' tab. Create a new UI policy. In the 'Condition' section, use a script to query the 'Software Catalog' table based on the selected software and check if 'Approval Required' is 'True'. In the 'UI Policy Actions' section, make the "Business Justification" variable 'Mandatory'.
      • (Question 5): Configure a notification to be sent to the employee when the software installation task is completed.
        • Problem-Solving Technique: Navigate to 'System Notification > Email > Notifications' and create a new notification. Set the 'Table' to 'Catalog Task [sc_task]'. In the 'When to send' section, specify 'Record Updated' and add a condition where 'State' 'changes to' 'Closed Complete' and 'Assignment group' is 'Software Deployment'. In the 'Who will receive' section, select 'Requested for' from the parent 'Request Item' record. Customize the email subject and body to inform the employee that their software installation is complete.
    • Problem-Solving Techniques for Managing Software Requests and Licensing: These assignments involve using custom tables to manage software information, creating dynamic workflows based on that data, enhancing the user interface with client scripts, enforcing data requirements with UI policies, and ensuring timely communication through notifications.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Implementing a service catalog for software requests provides a structured and auditable process for employees to access the applications they need. Utilizing a custom 'Software Catalog' table allows for centralized management of software information, including approval workflows and responsible teams, providing flexibility and control over software access. Dynamic workflows that adapt based on the 'Approval Required' flag for each software title ensure that the appropriate authorization steps are followed, maintaining compliance and security. Displaying software descriptions dynamically on the catalog item form helps users make informed decisions about the software they are requesting. Making the business justification mandatory for software requiring approval ensures that there is a valid reason for the request, aiding in cost management and license compliance. Notifying the employee upon completion of the installation task provides transparency and improves user satisfaction.
    • Key Tables: Service Catalog (sc_catalog), Catalog Item (sc_cat_item), Custom Table (x_<your_scope>_software_catalog), Workflow (wf_workflow), Client Script (sys_script_client), Script Include (sys_script_include), UI Policies (sys_ui_policy), Notifications (sysevent_email_action), Request (sc_request), Requested Item (sc_req_item), Catalog Task (sc_task), Group (sys_user_group).
  • Real-time Scenario 3: Access Provisioning Request - Granting Application Access
    • Scenario Description: The organization needs a streamlined process for employees to request access to various internal applications. This should be facilitated through the service catalog, with different approval requirements based on the application and the specific role being requested. Upon approval, the process should trigger a task for the security operations team to provision the necessary access. and describe the management of user access requests.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Create a catalog item named "Request Application Access" under the "Access Management" category. Include variables for "Employee Name", "Department", "Application Name" (reference to a custom 'Application List' table), and "Role Required" (dropdown based on the selected application).
        • Problem-Solving Technique: First, create a custom table named 'Application List' with fields like 'Name' (String, unique), 'Description' (String), 'Approval Group' (Reference to 'Group [sys_user_group]'), and 'Available Roles' (String, comma-separated list). Then, create the catalog item with variables for 'Employee Name' and 'Department'. Add a 'Reference' variable named 'Application Name' pointing to your 'Application List' table. Finally, add a 'Select Box' variable named 'Role Required'. You will need to use a 'Catalog Client Script' and a 'Script Include' (see Question 3) to dynamically populate the choices for this dropdown based on the selected application.
      • (Question 2): Configure a workflow that triggers when the "Request Application Access" catalog item is ordered. The workflow should query the 'Application List' table for the selected application and route the request for approval to the 'Approval Group' specified in that table. Upon approval, create a catalog task for the 'Security Operations' group to provision the access.
        • Problem-Solving Technique: Open 'Flow Designer' and create a new workflow. Set the 'Trigger' to 'Record Created' on the 'Requested Item [sc_req_item]' table where the 'Catalog Item' is "Request Application Access". Add an 'Action' to 'Lookup Record' from the 'Application List' table where 'Name' matches the selected application. Add a 'Group Approval' activity using the 'Approval Group' from the looked-up application record. Upon approval, add a 'Create Task' activity for the 'Security Operations' group with a 'Short description' like "Provision access for [Employee Name] to [Application Name]".
      • (Question 3): Implement a 'Script Include' and 'Catalog Client Script' to dynamically populate the "Role Required" dropdown on the catalog item based on the "Application Name" selected by the user.
        • Problem-Solving Technique: Create a 'Script Include' (e.g., named 'ApplicationRoles') with a function that takes the application name as input, queries the 'Application List' table, retrieves the 'Available Roles' for that application, and returns them as an array of choices suitable for a 'Select Box' variable. Then, create a 'Catalog Client Script' on the "Request Application Access" item with 'Type' as 'onChange' and 'Field name' as 'Application Name'. In the script, use GlideAjax to call your 'ApplicationRoles' script include, passing the selected application name. In the callback function, parse the returned array of roles and use g_form.clearOptions() and g_form.addOption() to populate the 'Role Required' dropdown.
      • (Question 4): Create a UI policy to display a field called "Reason for Role" (multi-line text) when the user selects a specific sensitive role (e.g., "Admin") for an application.
        • Problem-Solving Technique: Open the "Request Application Access" catalog item and navigate to the 'UI Policies' tab. Create a new UI policy. In the 'Condition' section, set the condition to 'Role Required' 'is' 'Admin' (or any other sensitive role you want to target). In the 'UI Policy Actions' section, make the "Reason for Role" variable 'Visible' and 'Mandatory'.
      • (Question 5): Configure a notification to be sent to the employee and their manager when the application access is successfully provisioned (access provisioning task is completed).
        • Problem-Solving Technique: Navigate to 'System Notification > Email > Notifications' and create a new notification. Set the 'Table' to 'Catalog Task [sc_task]'. In the 'When to send' section, specify 'Record Updated' and add a condition where 'State' 'changes to' 'Closed Complete' and 'Assignment group' is 'Security Operations'. In the 'Who will receive' section, select 'Requested for' from the parent 'Request Item' and also use a script to get the manager of the 'Requested for' user. Customize the email subject and body to inform them that the application access has been granted.
    • Problem-Solving Techniques for Implementing Access Control through the Service Catalog: These assignments involve using custom tables for application-specific data, dynamically controlling form behavior using client-side scripting and script includes, implementing approval workflows based on application requirements, and ensuring proper communication through notifications.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Providing a service catalog for application access requests centralizes and standardizes the process of granting user access to various systems, improving security and compliance. Utilizing a custom 'Application List' table allows for flexible management of applications, their associated approval processes, and the roles available for each application. Dynamically populating the 'Role Required' dropdown based on the selected application ensures that users are only presented with relevant options, simplifying the request process and reducing errors. Routing approval requests to the designated 'Approval Group' for each application ensures that the appropriate application owners or security personnel authorize access, maintaining data governance. Requiring a justification for sensitive roles adds an extra layer of control and auditability to the access provisioning process. Notifying both the employee and their manager upon successful provisioning keeps all relevant parties informed and enhances transparency.
    • Key Tables: Service Catalog (sc_catalog), Catalog Item (sc_cat_item), Custom Table (x_<your_scope>_application_list), Workflow (wf_workflow), Script Include (sys_script_include), Catalog Client Script (sys_script_client), UI Policies (sys_ui_policy), Notifications (sysevent_email_action), Request (sc_request), Requested Item (sc_req_item), Catalog Task (sc_task), Group (sys_user_group), User (sys_user).

6. Knowledge Management: Building a Repository of Solutions and Information

  • Real-time Scenario: Creating Knowledge Articles for Common Issues and Service Requests
    • Scenario Description: The IT department recognizes the need to build a robust and easily accessible knowledge base to empower end-users to resolve common issues independently and to provide service desk analysts with quick and accurate solutions for known problems and frequent service requests. This involves the creation, proper categorization, and ongoing maintenance of knowledge articles. and introduce the concepts and benefits of knowledge management.
    • Detailed Assignment Questions for a ServiceNow Developer (covering article creation, categorization, and workflow):
      • (Question 1): Configure two knowledge bases: "End User Help" (visible to all users) and "IT Support Knowledge" (visible only to users with the 'itil' role). describes the configuration of knowledge bases and their permissions.
        • Problem-Solving Technique: Navigate to 'Knowledge > Administration > Knowledge Bases' and create a new knowledge base named "End User Help". In the 'User Criteria' section, define the criteria for who can read articles in this knowledge base to include all users (you might need to create a user criteria record that includes all roles or no roles). Then, create another knowledge base named "IT Support Knowledge". In its 'User Criteria' section, define the criteria for read access to include only users with the 'itil' role.
      • (Question 2): Create a knowledge article template for "How-To Guides" that includes sections for "Problem", "Solution", "Steps", and "Related Articles". and mention the use of knowledge article templates.
        • Problem-Solving Technique: Navigate to 'Knowledge > Administration > Templates' and create a new template. Give it a 'Title' like "How-To Guide". Associate it with the "End User Help" knowledge base. In the 'Template body' section, use HTML or the visual editor to structure your template with headings for "Problem", "Solution", "Steps", and "Related Articles". You can include placeholder text within these sections to guide article authors.
      • (Question 3): Implement a workflow for the "End User Help" knowledge base where newly created articles go through a "Review" state before being "Published". The review should be assigned to members of the "Knowledge Management Team". and describe the lifecycle of knowledge articles and the use of workflows.
        • Problem-Solving Technique: Navigate to 'Knowledge > Administration > Workflow' and create a new workflow. Associate it with the "End User Help" knowledge base. Define the workflow states: 'Draft', 'Review', and 'Published'. Add a transition from 'Draft' to 'Review' when the author clicks 'Publish'. In the 'Review' state, add a 'Group Approval' activity and assign it to the "Knowledge Management Team" group. Add transitions from 'Review' to 'Published' upon approval and potentially back to 'Draft' if rejected.
      • (Question 4): Configure a business rule that automatically suggests relevant knowledge articles to users when they are creating a new incident, based on the short description. and highlight the integration of knowledge articles with incident management.
        • Problem-Solving Technique: Create a business rule on the 'Incident' table that runs 'Before Insert'. In the 'Script' section, retrieve the value of the 'Short description' field. Use a GlideRecord query on the 'kb_knowledge' table to search for articles where the 'Short description' or 'Text' fields contain keywords from the incident's short description. You can use gs.addInfoMessage() to display the titles of the found knowledge articles to the user.
      • (Question 5): Create a scheduled job that runs weekly and identifies knowledge articles in the "End User Help" knowledge base that have not been viewed in the last 6 months. The job should send a notification to the article owner, reminding them to review and update the article. mentions the tracking of knowledge usage.
        • Problem-Solving Technique: Navigate to 'System Definition > Scheduled Jobs' and create a new job that runs weekly. In the 'Script' section, write a GlideRecord query on the 'kb_knowledge' table. Filter for articles where the 'Knowledge base' is "End User Help" and the 'sys_view_count_last_month' (or a similar last viewed field) indicates no views in the past 6 months. For each such article, retrieve the 'Author' (owner) and send them an email notification reminding them to review and update the article.
    • Problem-Solving Techniques for Effective Knowledge Management Implementation: These assignments cover the fundamental aspects of building and maintaining a knowledge base: defining access permissions through knowledge bases, ensuring content consistency with templates, establishing a review and approval process using workflows, integrating knowledge with incident management for proactive issue resolution, and implementing mechanisms for keeping the knowledge base up-to-date.
    • Understanding the Knowledge Article Lifecycle in ServiceNow: The typical lifecycle of a knowledge article in ServiceNow involves several states. It begins in a Draft state where the content is being created and is not yet visible to most users. Once the author deems it ready, it can be submitted for Review, where subject matter experts or knowledge managers assess its accuracy and completeness. Upon approval, the article transitions to Published, making it available to the intended audience. Articles may eventually become outdated or irrelevant, at which point they can be marked as Pending Retirement and then moved to a Retired state, where they are no longer visible to end-users but might still be accessible to knowledge administrators. Some knowledge bases also utilize a Valid To Date, requiring periodic review to ensure the information remains current.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Establishing well-defined knowledge bases with appropriate access controls ensures that the right information is available to the right users, improving self-service capabilities for end-users and providing valuable resources for IT support staff. Utilizing knowledge article templates promotes consistency in the structure and format of articles, making them easier to read and understand, ultimately enhancing the user experience. Implementing a review and approval workflow for knowledge articles ensures the accuracy and quality of the information being published, building trust and reliability in the knowledge base. Proactively suggesting relevant knowledge articles during incident creation can help users find solutions to their issues before even submitting a ticket, leading to a reduction in incident volume and faster resolution times. Regularly reviewing and updating knowledge articles, especially those that haven't been viewed recently, ensures that the information remains current and accurate, maintaining the value and effectiveness of the knowledge base over time.
    • Key Tables: Knowledge Base (kb_knowledgebase), Knowledge Article (kb_knowledge), Knowledge Template (kb_template), Workflow (wf_workflow), Business Rules (sys_script), Scheduled Jobs (sysauto), Incident (incident), User Criteria (sys_user_criteria).

7. Configuration Management (CMDB): The Foundation of ITSM

  • Real-time Scenario 1: Utilizing the CMDB for Incident Impact Analysis
    • Scenario Description: A critical server, vital for several key business applications, has unexpectedly gone down, resulting in a major incident. The service desk urgently needs to determine all the business services and applications affected by this server outage to accurately assess the impact and prioritize the restoration efforts. and highlight the crucial role of the CMDB in incident management.
    • Detailed Assignment Questions for a ServiceNow Developer (covering CI identification, relationship mapping, and impact calculation):
      • (Question 1): Ensure that the 'Configuration item' field is mandatory on all new incident records.
        • Problem-Solving Technique: Navigate to 'System UI > UI Policies' and create a new UI policy on the 'Incident' table. Set the 'When to apply' condition to 'Always' or as per your organization's requirements (e.g., when the form is 'New'). In the 'UI Policy Actions' section, make the 'Configuration item' field 'Mandatory'.
      • (Question 2): Configure the 'Impacted Services' related list on the incident form to automatically display all business services that have a 'Depends on::Used by' relationship with the configuration item selected in the 'Configuration item' field. mentions the use of service mapping in understanding impacted assets.
        • Problem-Solving Technique: Navigate to 'Incident > Configure > Related Lists'. Add the 'Impacted Services' related list (task_cmdb_ci_service). Click the edit icon for this related list. In the 'Condition' field, add a filter that shows records where 'Task' is the current incident record AND 'CI Item' has a relationship with the incident's 'Configuration item' where the relationship type is 'Depends on::Used by'. You might need to explore the cmdb_rel_type table to understand the exact relationship names.
      • (Question 3): Implement a business rule that, when a configuration item is selected on an incident, automatically populates the 'Service' field on the incident with the primary business service associated with that CI (if one exists).
        • Problem-Solving Technique: Create a business rule on the 'Incident' table that runs 'On Change' of the 'Configuration item' field. In the 'Script' section, use GlideRecord to query the cmdb_rel_ci table to find relationships where the 'child' is the selected configuration item and the 'parent.sys_class_name' is 'cmdb_ci_service'. You might need to define what constitutes a 'primary' service (e.g., based on a specific relationship type or a flag on the service CI). Once the primary service is identified, update the 'Service' field on the current incident record.
      • (Question 4): Create a report showing all open incidents where the 'Configuration item' field is populated, grouped by the 'Service' affected and the 'Priority' of the incident.
        • Problem-Solving Technique: Go to 'Reports > Create New'. Select the 'Incident' table. Add a filter where 'Configuration item' is 'is not empty' and 'State' is not 'Closed' or 'Resolved'. Create a 'Grouped' report (e.g., a pivot table). In the 'Rows' section, add 'Service'. In the 'Columns' section, add 'Priority'. In the 'Aggregation' section, select 'Count'.
      • (Question 5): Explore the 'Dependency Views' functionality in ServiceNow. Describe how a service desk analyst can use the dependency view for the impacted server to visually identify all related CIs and services affected by the outage. and mention the usefulness of dependency views.
        • Problem-Solving Technique: Instruct the user to open the CI record for the impacted server in ServiceNow. On the CI form, look for a related link or tab called 'Dependency Views' or 'Map'. Clicking this will open a visual representation of the server and its relationships with other CIs, including applications and business services that depend on it. The analyst can navigate this view to understand the upstream and downstream dependencies and identify all potentially affected services.
    • Problem-Solving Techniques for Leveraging the CMDB in Incident Management: These assignments highlight the importance of linking incidents to configuration items, understanding the relationships between CIs, and utilizing visual tools like dependency views to quickly assess the impact of incidents on business services.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: The ability to quickly identify the business services impacted by a critical server outage, using the CMDB, is paramount for effective incident management. Making the 'Configuration item' field mandatory on incident records ensures that this crucial link is established consistently. Automatically populating the 'Impacted Services' related list based on the 'Depends on::Used by' relationship provides service desk analysts with immediate visibility into the business impact, enabling them to prioritize restoration efforts and communicate effectively with stakeholders. Automatically populating the 'Service' field further streamlines incident categorization and reporting, providing a service-centric view of the disruption. Reporting on open incidents linked to specific services allows for the identification of recurring issues affecting critical business functions. Utilizing 'Dependency Views' offers a visual and intuitive way to understand the complex relationships between IT assets and services, aiding in rapid impact assessment and root cause analysis.
    • Key Tables: Incident (incident), Configuration Item (cmdb_ci), CMDB Relationship (cmdb_rel_ci), Business Service (cmdb_ci_service), UI Policies (sys_ui_policy), Business Rules (sys_script), Reports (sys_report), CMDB Relationship Types (cmdb_rel_type).
  • Real-time Scenario 2: Utilizing the CMDB for Change Risk Assessment
    • Scenario Description: Before implementing a planned change to a critical application server, the IT team needs to thoroughly assess the potential risks and understand the impact it might have on dependent services and underlying infrastructure. The CMDB, with its comprehensive information about configuration items and their relationships, can provide valuable insights for this risk assessment process. and emphasize the role of the CMDB in change management.
    • Detailed Assignment Questions for a ServiceNow Developer:
      • (Question 1): Configure the 'Affected CIs' related list on the change request form to allow users to easily add configuration items that will be directly impacted by the change.
        • Problem-Solving Technique: Navigate to 'Change Request > Configure > Related Lists' and add the 'Affected CIs' related list (task_ci). Ensure the necessary fields like 'CI Class' and 'Relationship Type' are visible in the list view.
      • (Question 2): Implement a business rule that, when a configuration item is added to the 'Affected CIs' list on a change request, automatically populates the 'Impacted Services' related list with all business services that depend on the affected CI (using 'Used by::Depends on' relationship).
        • Problem-Solving Technique: Create a business rule on the task_ci table that runs 'After Insert'. In the 'Condition' section, check if the 'Task' field references a record in the 'Change Request' table (change_request). In the 'Script' section, retrieve the sys_id of the added configuration item. Use GlideRecord to query the cmdb_rel_ci table to find relationships where the 'parent.sys_id' matches the CI's sys_id and the 'type' is 'Used by::Depends on'. For each found business service (child CI), create a new record in the task_cmdb_ci_service table, linking it to the current change request and the identified business service.
      • (Question 3): Design a UI action on the change request form that allows users to visualize the affected CIs and impacted services in a dependency view.
        • Problem-Solving Technique: Go to 'System UI > UI Actions' and create a new UI action on the 'Change Request' table. Set 'Client' to 'False' and 'Server' to 'True'. In the 'Script' section, retrieve all CIs from the 'Affected CIs' related list and all services from the 'Impacted Services' related list of the current change request. Use the CMDBVisualizer API (or a similar method like creating a temporary service mapping) to generate and display a dependency view that includes these CIs and their relationships.
      • (Question 4): Create a risk assessment rule that increases the risk score of a change request if any of the 'Affected CIs' are marked as 'Business Critical' in the CMDB.
        • Problem-Solving Technique: Navigate to 'Change > Risk Assessment > Rules' and create a new rule. Set the 'Applies to' to 'Change Request'. In the 'Condition' section, create a script condition that iterates through the 'Affected CIs' related list of the current change request. For each CI, query the cmdb_ci table and check if the 'Business critical' field is 'True'. If any affected CI is business critical, return 'true'. In the 'Risk Calculation' section, define how the risk score should be increased (e.g., by a specific value or by setting the risk to 'High').
      • (Question 5): Configure a notification to be sent to the owners of all 'Impacted Services' (identified in Question 2) when a change request affecting their service is moved to the 'Scheduled' state.
        • Problem-Solving Technique: Navigate to 'System Notification > Email > Notifications' and create a new notification for the 'Change Request' table. Set the 'When to send' condition to 'State' changes 'to' 'Scheduled'. In the 'Who will receive' section, use a script to query the 'Impacted Services' related list of the current change request. For each service CI, retrieve the 'Owned by' field (or the appropriate field that identifies the service owner) and add them to the 'To' or 'Cc' list of the notification.
    • Problem-Solving Techniques for Integrating the CMDB with Change Management: These assignments focus on leveraging the relationships within the CMDB to understand the impact of planned changes, visualizing these impacts, and using CMDB data to inform risk assessment and communication processes.
    • Insights, Hidden Patterns, Causal Relationships, Broader Implications: Utilizing the CMDB for change risk assessment provides a comprehensive understanding of the potential consequences of a planned IT modification. By automatically populating the 'Impacted Services' related list based on the 'Affected CIs', the IT team gains immediate insight into the business services that might be affected by the change, facilitating better planning and communication. Visualizing the affected CIs and impacted services in a dependency view offers a clear and intuitive representation of the change's scope and potential reach, aiding in decision-making and risk mitigation. Integrating CMDB data with risk assessment rules allows for an automated and data-driven evaluation of the change's risk, ensuring that changes affecting business-critical components receive appropriate scrutiny. Notifying the owners of impacted services keeps them informed about upcoming changes that might affect their services, enabling them to prepare and communicate with their users accordingly.
    • Key Tables: Change Request (change_request), Configuration Item (cmdb_ci), CMDB Relationship (cmdb_rel_ci), Business Service (cmdb_ci_service), Task CI (task_ci), Task CMDB CI Service (task_cmdb_ci_service), UI Actions (sys_ui_action), Risk Assessment Rule (rm_rule), Notifications (sysevent_email_action), User (sys_user).
  • The Importance of CMDB Data Accuracy and Maintenance:
    • Accurate and up-to-date data within the CMDB is the bedrock of effective ITSM processes. Without a reliable CMDB, incident impact analysis will be flawed, problem root cause analysis will be hampered, change risk assessments will be inaccurate, service catalog offerings might be misaligned with the actual infrastructure, and knowledge articles might refer to outdated configurations. The CMDB serves as the single source of truth for all IT assets and their relationships, and its accuracy directly impacts the efficiency and effectiveness of all other ITSM modules.
    • Inaccurate CMDB data can lead to several negative consequences. Incorrect impact analysis during incidents can result in delayed restoration of critical services. Failed changes due to a lack of understanding of dependencies can cause prolonged downtime. Inefficient problem resolution can occur if the underlying infrastructure is not accurately represented. Compliance issues can arise if asset information is incomplete or incorrect. Ultimately, inaccurate CMDB data increases IT operational costs and reduces the overall quality of IT services.
    • Maintaining CMDB accuracy requires a commitment to data governance, regular audits to identify and correct discrepancies, and the implementation of automated discovery tools to ensure that the CMDB reflects the current state of the IT environment. Establishing clear data ownership and accountability, along with well-defined processes for data updates and reconciliation, are essential for ensuring the CMDB remains a trusted and valuable resource for the entire IT organization.

8. Service-Based Company Project Work - Actual Requirements

  • Examples of typical project requirements related to each ITSM module in service-based companies:
    • Incident Management: Implementing a self-service portal for incident submission, integrating with monitoring tools for automatic ticket creation, configuring escalation rules based on business hours and priority, developing custom reports for SLA compliance.
    • Problem Management: Implementing a proactive problem management process to identify and resolve potential issues before they impact users, integrating problem management with change management for implementing permanent fixes, creating a knowledge base of known errors and workarounds.
    • Change Management: Implementing different change models for standard, normal, and emergency changes, configuring approval workflows with multiple levels of authorization, integrating change management with the CMDB for impact analysis and risk assessment, developing a change calendar for visibility.
    • Service Catalog: Designing and implementing a user-friendly service catalog with various service offerings, including request workflows with approvals and task fulfillment, integrating the service catalog with asset management and procurement systems, implementing cost tracking for service requests.
    • Knowledge Management: Implementing a knowledge management system with article templates, workflows for content review and approval, integrating knowledge search with the service portal and incident forms, establishing a process for regular review and update of knowledge articles.
    • Configuration Management (CMDB): Implementing automated discovery tools to populate the CMDB, defining CI relationships and dependencies, establishing data governance policies and procedures for maintaining CMDB accuracy, integrating the CMDB with other ITSM modules for enhanced process efficiency.
  • Assignments based on these real-world requirements:
    • (Incident Management): "Develop a script include and client script to display dynamic fields on the incident form based on the selected category and sub-category in the service portal."
      • Problem-Solving Technique: Create a script include that returns a JSON object containing field configurations (visibility, mandatory status) based on category and sub-category. Create a client script on the incident form that calls this script include using GlideAjax on change of the category and sub-category fields and updates the form fields accordingly using g_form.setMandatory() and g_form.setVisible().
    • (Problem Management): "Configure a flow to automatically create a change request to implement a permanent fix for a problem once the root cause analysis is complete and approved."
      • Problem-Solving Technique: Create a flow that triggers when a problem record is updated and the 'Root Cause Analysis' state is reached and the 'Problem Coordinator' approves the permanent fix. Add an 'Action' to create a new 'Change Request' record, pre-populating fields like 'Short description' (from the problem's short description), 'Justification' (from the problem's root cause), and 'Configuration item' (from the problem's CI).
    • (Change Management): "Implement a CAB workbench to provide a centralized view of all upcoming changes, including risk assessment and approval status."
      • Problem-Solving Technique: Create a new module in ServiceNow. Develop a UI page or a dashboard that displays a list of upcoming change requests (based on the 'Scheduled start date'). Include columns for 'Change Request Number', 'Short description', 'Risk', 'Impact', 'Approval status', and potentially a visual indicator for conflicts based on the change calendar. Use GlideRecord queries to fetch the necessary data and display it on the page or dashboard.
    • (Service Catalog): "Develop a workflow to automatically provision a virtual machine based on a request submitted through the service catalog, integrating with a cloud management platform."
      • Problem-Solving Technique: Use 'IntegrationHub' or Orchestration to create a connection and spoke to your cloud management platform (e.g., AWS, Azure). Create a workflow that triggers when a specific catalog item for VM provisioning is ordered. The workflow should use IntegrationHub steps to call the cloud platform's API to create a new virtual machine based on the user's selections in the catalog item (e.g., size, operating system).
    • (Knowledge Management): "Configure contextual search in the service portal to display relevant knowledge articles based on the user's search terms and their role."
      • Problem-Solving Technique: Navigate to 'Service Portal > Search Sources' and configure a search source for knowledge articles. Ensure that the search source is active on your service portal page. Review the 'Condition' field and the underlying scripts to ensure that the search results are filtered based on the user's roles and the knowledge base user criteria. You might need to customize the script to refine the search logic based on your specific requirements.
    • (Configuration Management (CMDB)): "Implement a reconciliation rule to ensure that data from the discovery source takes precedence over manually entered data for critical server attributes in the CMDB."
      • Problem-Solving Technique: Navigate to 'CMDB > Configuration > Identification/Reconciliation > Reconciliation Rules'. Create a new reconciliation rule for the 'Windows Server' CI class. Define the data sources (e.g., ServiceNow Discovery, Manual Input). For the critical attributes (e.g., 'CPU count', 'RAM size', 'Operating system'), set the precedence order such that the data from the discovery source has a higher priority than manually entered data.

9. Conclusion: Recap of Key Concepts and Encouragement for Continued Learning
This report has provided a comprehensive overview of the core ServiceNow ITSM modules through the lens of real-world scenarios and practical assignments. We explored Incident Management, focusing on handling critical outages, recurring issues, and the importance of escalation. In Problem Management, we delved into identifying root causes and implementing permanent fixes for recurring incidents. Change Management covered the nuances of standard, normal, and emergency changes, emphasizing the importance of approvals, risk assessment, and backout planning. The Service Catalog section highlighted how to empower users with self-service options for hardware, software, and access requests. Knowledge Management demonstrated the creation and maintenance of a valuable repository of solutions. Finally, Configuration Management (CMDB) underscored its foundational role in supporting all ITSM processes, particularly in incident impact analysis and change risk assessment.
Mastering these concepts and practicing these assignments will significantly enhance your skills as a ServiceNow developer. Remember that practical experience is paramount, so continue to explore and experiment within your ServiceNow instance. The ServiceNow community forums, developer documentation, and Now Learning platform are invaluable resources for continued learning and staying up-to-date with the latest features and best practices. As you prepare for interviews and embark on service-based company projects, the ability to articulate your understanding of these real-world scenarios and demonstrate your problem-solving skills will be a key differentiator. Embrace the challenges, continue to learn, and you will undoubtedly excel in your ServiceNow career.

Works cited

1. Try ServiceNow Incident Management - All You Need to Know - GeeksForLess, https://geeksforless.com/try-servicenow-incident-management/ 2. Real time use cases of ITSM examples - ServiceNow Community, https://www.servicenow.com/community/itsm-forum/real-time-use-cases-of-itsm-examples/m-p/2564952 3. IT - Incident Impact, Urgency, and Priority Guide - 3.0 - ServiceNow, https://berkeley.service-now.com/kb_view.do?sysparm_article=KB0010891 4. ITSM Scenarios (use cases) | practice assignments to start with in ServiceNow, https://www.servicenow.com/community/itsm-articles/itsm-scenarios-use-cases-practice-assignments-to-start-with-in/ta-p/2308504 5. Unleashing the Power of ServiceNow Problem Management: Resolving Root Causes for Good - YouTube, https://www.youtube.com/watch?v=JO9rfHEvgpE 6. ServiceNow Problem Management: The Essential Guide - acSoft Inc, https://www.acsoftinc.com/servicenow-problem-management-the-essential-guide/ 7. ServiceNow Problem Management| Benefits| Process| Roles| Best Practices| Tips, https://aelumconsulting.com/problem-management/ 8. Designing an escalation process - ServiceNow, https://www.servicenow.com/docs/bundle/yokohama-it-service-management/page/administer/on-call-scheduling/concept/designing-escalation-process-oncall.html 9. About escalating incidents - ServiceNow, https://www.servicenow.com/docs/bundle/xanadu-proactive-service-exp-workflows/page/product/tmt-assurance-workflows/concept/psew-escalate-incident.html 10. Incident Management Process Servicenow | Restackio, https://www.restack.io/p/issue-management-escalation-strategies-answer-incident-management-process-servicenow 11. What is the difference between Incident Priority and Incident Impact in ServiceNow ITSM?, https://www.servicenow.com/community/developer-forum/what-is-the-difference-between-incident-priority-and-incident/td-p/3061217 12. Problem Management Configuration in ServiceNow - Reco, https://www.reco.ai/hub/problem-management-configuration-servicenow 13. Scenario based and Theoretical interview questions for the ITSM Developer role - 1 year experience - ServiceNow, https://www.servicenow.com/community/virtual-agent-forum/scenario-based-and-theoretical-interview-questions-for-the-itsm/m-p/3033488 14. Problems in ServiceNow - Netenrich, https://support.netenrich.com/hc/en-us/articles/7226686573981-Problems-in-ServiceNow 15. Problem Management in Your Company - ServiceNow Community, https://www.servicenow.com/community/itsm-forum/problem-management-in-your-company/m-p/741222 16. What is ServiceNow Knowledge Management? - YouTube, https://www.youtube.com/watch?v=SK75nFAR3-c 17. Create knowledge article for recurring incidents - ServiceNow Community, https://www.servicenow.com/community/developer-forum/create-knowledge-article-for-recurring-incidents/td-p/3192670 18. difference between standard change and standard proposal change - ServiceNow, https://www.servicenow.com/community/developer-forum/difference-between-standard-change-and-standard-proposal-change/m-p/2853324 19. ServiceNow Standard Change Demo In English - YouTube, https://www.youtube.com/watch?v=Iagy1136Dxk 20. What are examples of standard changes - ITILfromExperience.com, http://www.itilfromexperience.com/What+are+examples+of+standard+changes 21. ServiceNow Change Management (Complete Guide + Free PDF) - NGenious Solutions, https://ngenioussolutions.com/blog/servicenow-change-management/ 22. Information Technology - Normal Change Request - Service Portal - ServiceNow, https://auburn.service-now.com/it/en/normal-change-request?id=kb_article_view&sysparm_article=KB0011372 23. Normal Change Procedure (IET CAB) - Knowledge Base - ServiceHub, https://servicehub.ucdavis.edu/servicehub?id=ucd_kb_article&sysparm_article=KB0001303 24. ServiceNow Emergency Change Demo | Part - 4 - YouTube, https://www.youtube.com/watch?v=sbKA8lEuehc 25. Information Technology - Emergency Change Request - Service Portal - ServiceNow, https://auburn.service-now.com/it/en/emergency-change-request?id=kb_article_view&sysparm_article=KB0011317 26. Difference between Emergency Change and Urgent changes(Expedite) - ServiceNow, https://www.servicenow.com/community/itsm-forum/difference-between-emergency-change-and-urgent-changes-expedite/m-p/2927775 27. Catalog Item vs Service Request - ServiceNow Community, https://www.servicenow.com/community/developer-forum/catalog-item-vs-service-request/m-p/2565830 28. Form and Catalog Items - Services & Support - UCSD Support, https://support.ucsd.edu/services?id=kb_article_view&sysparm_article=KB0034726 29. Manage Hardware Asset Requests Using ServiceNow's Zero Touch Request Flow, https://www.youtube.com/watch?v=4LA-8yPqwPk 30. Creating and Requesting a basic Service Catalog Item - YouTube, https://www.youtube.com/watch?v=gWQApS1Gb1o 31. IT infrastructures service requests - ideas list - ServiceNow Community, https://www.servicenow.com/community/it-service-management-forum/it-infrastructures-service-requests-ideas-list/m-p/880920 32. Service Requests in ServiceNow - Netenrich, https://support.netenrich.com/hc/en-us/articles/7235128340125-Service-Requests-in-ServiceNow 33. ServiceNow Software Request Automation - YouTube, https://www.youtube.com/watch?v=rjLAm3XVdkw 34. Configure ServiceNow for automatic user provisioning with Microsoft Entra ID, https://learn.microsoft.com/en-us/entra/identity/saas-apps/servicenow-provisioning-tutorial 35. Better Together – User Access Requests with SailPoint & ServiceNow, https://www.sailpoint.com/blog/user-access-requests-servicenow 36. Knowledge Management - ServiceNow, https://www.servicenow.com/now-platform/knowledge-management.html 37. ServiceNow Knowledge Management| Process| Benefits| Examples - Aelum Consulting, https://aelumconsulting.com/servicenow-knowledge-management/ 38. ServiceNow Knowledge Must Read - Information Technology - IT Services, https://ucsdservicedesk.service-now.com/its?id=kb_article_view&sysparm_article=KB0033878 39. How to create and publish a knowledge article - ServiceNow Service Management, https://fermi.servicenowservices.com/kb_view.do?sysparm_article=KB0012585 40. Knowledge article states - ServiceNow, https://www.servicenow.com/docs/bundle/yokohama-servicenow-platform/page/product/knowledge-management/concept/knowledge-article-states.html 41. Knowledge Article Workflow States and Valid Dates KB0015037 - UT Service Desk - ServiceNow, https://ut.service-now.com/sp?id=kb_article&number=KB0015037 42. Retire a knowledge article - ServiceNow, https://www.servicenow.com/docs/bundle/xanadu-servicenow-platform/page/product/knowledge-management/concept/c_RetiredKnowledgeArticles.html 43. ServiceNow Knowledge Management Demo, https://www.servicenow.com/lpdem/demonow-knowledge-management.html 44. How AIOps modernizes the ServiceNow CMDB - BigPanda, https://www.bigpanda.io/blog/how-aiops-modernizes-the-servicenow-cmdb/ 45. CMDB Use Cases in Streamlining IT Service Delivery Processes - Device42, https://www.device42.com/cmdb-best-practices/cmdb-use-cases/ 46. Problem Management use case - ServiceNow, https://www.servicenow.com/docs/bundle/yokohama-servicenow-platform/page/product/csdm-implementation/concept/pm-use-case-example.html 47. What can CMDB actually do? : r/servicenow - Reddit, https://www.reddit.com/r/servicenow/comments/1f8aqwq/what_can_cmdb_actually_do/ 48. What is a configuration management database (CMDB)? - ServiceNow, https://www.servicenow.com/products/it-operations-management/what-is-cmdb.html 49. 50 ServiceNow CMDB Use Cases 2024, https://servicenowspectaculars.com/50-cmdb-use-cases-servicenow/ 50. What is CMDB Health? Why it is important in CMDB. - ServiceNow Community, https://www.servicenow.com/community/developer-forum/what-is-cmdb-health-why-it-is-important-in-cmdb/m-p/2503104 51. Explaining the Importance of an Accurate CMDB for ServiceNow Users - ProV International, https://www.provintl.com/blog/explaining-the-importance-of-an-accurate-cmdb-for-servicenow-users 52. Cmdb for change management - ServiceNow Community, https://www.servicenow.com/community/cmdb-forum/cmdb-for-change-management/m-p/3226950 53. How does CMDB help in change management? - Virima, https://virima.com/blog/how-does-cmdb-help-in-change-management 54. Best practices for CMDB Data Management - ServiceNow Community, https://www.servicenow.com/community/cmdb-articles/best-practices-for-cmdb-data-management/ta-p/2841377

No Comments
Back to top