Introduction In ServiceNow, Scheduled Jobs are used to run scripts automatically at a defined time or interval. They are commonly used for tasks like sending reminder emails, updating records, cleaning up old data, or monitoring SLAs. This blog explains: What a Scheduled Job is When to use it How it works One real-time example with script What is a Scheduled Job in ServiceNow? A Scheduled Job is a server-side script that runs: At a specific date and time Daily / Weekly / Monthly At regular intervals (for example, every 15 minutes) It runs in the background without user interaction. When Should You Use a Scheduled Job? Use a Scheduled Job when: You need automation based on time No user action is involved You want to run reports or checks regularly Common Use Cases Send daily or weekly reports Notify users about SLA breaches Auto-close old incidents Escalate tickets stuck in a state Scheduled Job Types in ServiceNow Run once – Executes only one time Repeat – Runs daily, weekly, or monthly Run at intervals – Runs every X minutes or hours Example Scenario (Real-Time Use Case) Requirement Send an email every day at 7:00 AM to the IT Manager listing all Incidents that are still Open for more than 3 days. Step-by-Step: Create Scheduled Job Step 1: Navigate to Scheduled Jobs System Definition → Scheduled Jobs → New Step 2: Fill Basic Details Name: Daily Open Incident Reminder Run: Daily Time: 07:00:00 Active: true Step 3: Script (Example Code) (function () {    var gr = new GlideRecord(‘incident’);    gr.addQuery(‘state’, ‘!=’, 7); // Not Closed    gr.addQuery(‘opened_at’, ‘<=’, gs.daysAgoStart(3));    gr.query();     var incidentList = ”;     while (gr.next()) {        incidentList += gr.number + ‘ – ‘ + gr.short_description + ‘n’;    }     if (incidentList != ”) {        gs.eventQueue(‘daily.open.incident.alert’, null, incidentList, ”);    }})(); Step 4: Email Notification Create an Email Notification: Table: Incident Event name:daily.open.incident.alert To: IT Manager Subject: Daily Open Incidents Older Than 3 Days Body: Hello Team, Below are the incidents open for more than 3 days: ${parm1} Regards,ServiceNow Output Every morning at 7:00 AM: Scheduled Job runs Checks for old open incidents Sends one consolidated email to the IT Manager Best Practices Always test scripts in Background Scripts first Avoid heavy queries during business hours Log messages using gs.log() for debugging Keep scheduled jobs simple and efficient Conclusion Scheduled Jobs are powerful automation tools in ServiceNow. With proper planning and scripting, they help reduce manual effort and improve operational efficiency.

Change Management 1. Definition: ServiceNow change management is a module that provides a structured approach to managing changes within an IT environment, ensuring they are implemented safely and efficiently while minimizing disruptions. 1.1Types of Changes 1.1.1 Standard Change Pre-approved, low-risk, and common (e.g., password reset, software update). No CAB (Change Advisory Board) approval is required.  1.1.2 Normal Change Requires risk assessment and CAB approval. (within 24 Hours) Goes through various stages: creation, assessment, approval, implementation, review.  1.1.3Emergency Change For urgent repairs (e.g., production outage). Requires expedited approval process. 2.  Normal Change Management (Flow) States in any ServiceNow application serve a specific purpose. They are designed to make it clear where in a process a record currently resides and to display progress. States should represent a unique phase in a process where a specific set of related activities are grouped together designed to achieve a particular outcome to move to the next phase of the process. 2.1 New When a Change Request is first created in ServiceNow, it enters the New state, which represents the very beginning of the change of lifecycle. At this stage, the change has only been submitted with basic details, and no evaluation, approvals, or workflow activities have started yet. The New state acts like a draft phase where the Change Manager or Change Coordinator reviews the initial information to verify whether the request is valid, complete, and ready for further processing. Only after this review does the Change move out of the New state—usually into the Assess or Authorize stage—where detailed analysis, risk and impact assessment, and approval workflows begin. 2.2 Assess In the Assessed state of a Change Request, all the necessary analysis—such as impact, risk, complexity, and resource requirements—has already been completed by the technical and change teams. Once this evaluation is done, the Change Request moves into a stage where it needs authorization before it can proceed further. At this point, the Service Owner plays a key role by reviewing the assessment details and deciding whether the change should move forward. The Service Owner approves the change in the Assessed state, ensuring that the proposed modification is beneficial, aligns with service goals, and does not pose unacceptable risks. This approval is crucial because it confirms that the change is justified, planned properly, and safe to advance toward scheduling and implementation 2.3 Authorize In Change Management, the Authorized state is the stage where all required approvals—especially from the Change Advisory Board (CAB)—are handled for Normal changes. When a Normal change reaches this state, it automatically triggers the CAB approval workflow, ensuring that the proposed change has been reviewed from technical, business, and risk perspectives. The Authorized state is also the point where the change start and end dates are finalized and confirmed. By the time a change is authorized, all assessments are complete, stakeholders have approved it, and the schedule is locked in so the change can proceed confidently toward implementation. 2.4 Scheduled In the Scheduled state of a Change Request, all approvals have already been completed, and the change is fully authorized for implementation. At this stage, no further activities or reviews take place because everything required for execution—such as risk assessment, planning, approvals, and scheduling—has already been finalized. The change simply remains in the Scheduled state until the Planned Start Date arrives. Once that date and time are reached, the change will move forward into the Implementation phase, where the actual work begins. 2.5 Implement When a Change Request moves into the Implement state, the system automatically populates the Actual Start Date field with the exact date and time the implementation begins. This marks the official start of the execution phase. During this state, all work related to the change is carried out, and the Work Notes field or associated Change Tasks are used to record every activity performed as part of the implementation. These notes help maintain complete transparency, provide technical documentation, and ensure accurate tracking of progress throughout the implementation process. 2.6 Review When a Change Request moves into the Review state, the system automatically fills in the Actual End Date with the exact date and time the implementation work is completed. This marks the official end of the execution phase. The Review state is used to verify whether the change was successful, evaluate any issues encountered, and confirm that all implementation tasks were completed as planned. The Implementer will populate the mandatory fields: 2.7 Close code & Close note has three options 1) Successful 2) Successful with issues 3) Unsuccessful 2.8 Closed The Closed state represents the final completion of a Change Request (CR). It indicates that all stages of the change—planning, approvals, implementation, and review—have been fully completed and documented. Once a change reaches the Closed state, no further actions are required, and the record is effectively archived for future reference, reporting, or audit purposes. 2.9 Canceled The Canceled state represents a Change Request (CR) that is no longer required, deemed invalid, or should not continue through the change lifecycle. When a change is canceled, it means that it will not move forward to assessment, approval, implementation, or any further stage. The request is officially stopped and closed out of the active change process, typically because the need no longer exists, requirements have changed, or the change was created in error. 3 Emergency Change Management (Flow) 3.1 New In Emergency Change Management, when a change is first created, it begins in the New state, just like other change types. However, this stage is extremely brief because emergency changes are time-critical and require immediate attention. The New state simply captures the initial details of the urgent issue—such as the impact, affected services, and the reason for emergency treatment—before the change is quickly reviewed by the Change Manager or Emergency CAB (ECAB). Unlike normal changes, the New state in an emergency scenario is not used for extended analysis or planning; instead, it acts as a rapid starting point from which the change moves almost immediately into authorization and implementation