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

Incident Management 1. Incident   An incident, defined as an unplanned interruption to an IT service.  1.1 Examples  Email not working  VPN down  Application slow  Printer not responding    2. Incident management   Incident management is the process of identifying, analyzing, and resolving incidents that disrupt normal business operations or IT services, with the goal of restoring services as quickly as possible and minimizing impact on users and business operations.    3. Objectives   Restore the service as quickly as possible  Minimize disruption to the user’s work  Manage the incident throughout its entire lifecycle  Support operational activities    4. How Incidents Can Be Created  Incidents can be raised in many ways:  Service Portal (self-service)  Email inbound actions  Phone call to Service Desk  ITSM Mobile app  Integration (API)  Auto-created via Monitoring/Event Management  Manually by agents in ServiceNow  5. Fields in the incident management    5.1 Caller  Caller field identifies the person who is reporting the issue.  5.2 Urgency   Three levels of urgency are given in the list box that are High, Medium, and Low as per the incident type.   5.3 Channel  Incident can be raised through following channels  1)Chat  2)Email  3) Phone  4)Self-service  5)Virtual Agent  6)Walk-in  Short description: A short description is a summary of an incident, typically used to quickly communicate the nature of the problem to relevant parties.    6. States  State: New, In Progress, On Hold, Resolved, Closed, canceled. These are the states where the incident is placed as the status of the incident by the ‘Assigned to person’.  6.1 Incident States in ServiceNow   State  Meaning  New  Raised but not yet acted on  In Progress  Work is ongoing  On Hold  Waiting for user/vendor/approval/information  Resolved  Fix applied; pending confirmation  Closed  Fully closed  Canceled  Invalid or mistakenly created    New: When incident is new and still not Assigned.  In Progress: When the incident is assigned to someone who can solve the incident.  Two fields are mandatory before putting your incident on-hold state that is   On hold reason and comments (visible to both Customer and IT staff)   On Hold: The On-Hold state in incident management is a temporary status where the incident resolution is suspended because the team is waiting for necessary action from the caller. In the On Hold state, the on-hold reason field is mandatory.  Resolved: The incident considered to be resolved when the service has been resolved to its normal state. The two fields are mandatory to fill.  1) Resolution code   2) Resolution notes  Closed: The incident is closed when issues are resolved, and all necessary actions are completed Canceled: The Canceled state represents an incident that is no longer required to be worked on.  This means the incident does not need investigation, troubleshooting, or resolution.  7. Incident Management – Table Fields (ServiceNow)    Table Name: incident  Field Name  Label  Description  number  Incident Number  Auto-generated unique number for each incident.  caller_id  Caller  The user who reported the incident.  short_description  Short Description  A brief summary of the issue.  description  Description  Detailed explanation of the issue.  category  Category  High-level classification (e.g., Network, Hardware, Software).  subcategory  Subcategory  More specific classification under category.  impact  Impact  Scope of the incident (Low/Medium/High).  urgency  Urgency  How quickly the issue needs to be resolved.  priority  Priority  Calculated from Impact + Urgency.  assignment_group  Assignment Group  The group responsible for working on the incident.  assigned_to  Assigned To  The person working on the incident.  state  State  Current status (New, In Progress, On Hold, Resolved, Closed).  on_hold_reason  On Hold Reason  Reason for putting the incident on hold.  resolve_time  Resolve Time  Date & time when the incident was resolved.  close_code  Close Code  Reason for closing (e.g., Solved Permanently, Duplicate).  close_notes  Close Notes  Notes added by resolver when closing.  opened_at  Opened At  Date & time incident was created.  opened_by  Opened By  User who created the incident.  updated_at  Updated At  Last modified date.  u_symptom  Symptom  Description of symptoms (custom field in many orgs).  cmdb_ci  Configuration Item (CI)  CI affected by the incident.  location  Location  Location of the caller or incident.  contact_type  Contact Type  How the incident was reported (Phone, Email, Self-Service).  work_notes  Work Notes  Internal notes by support team.  comments  Additional Comments  Notes visible to the caller.  sla_due  SLA Due  When the resolution is due as per SLA.  reassignment_count  Reassignment Count  Number of times the ticket was reassigned.  problem_id  Problem  Linked Problem record if related.  rfc  Change Request  Linked Change request if created from the incident.  knowledge  Knowledge  Checkbox to suggest a knowledge article.        Additional comment  Additional comments are used to capture information visible to and often entered by the end user (Caller) as well as IT staff. It facilitates communication between the service desk and the user.    Work note    This field is used to document internal notes and technical details about the incident, intended for IT staff and support teams only. 

What is Now Assist in Service Now Now Assist is Service Now’s suite of generative AI-powered experiences integrated into the Now Platform. It leverages domain-specific large language models (LLMs) to enhance productivity, efficiency, and user interactions across various Service Now applications, such as IT Service Management (ITSM), Customer Service Management (CSM), Human Resources (HR), and more. Key capabilities include: Content Generation and Summarization; automatically generate summaries for cases, incidents, chats, emails, and knowledge articles to speed up resolution times. Self-Service and Recommendations: Provide proactive suggestions, answers to queries, and action recommendations in Virtual Agent or search interfaces. Search Enhancement; Use AI-powered search (AI Search) to deliver more relevant results, including a semantic understanding of user queries. Code and Workflow Assistance: Generate code snippets, flows, or scripts for developers using tools like Now Assist for Creators. Multilingual Support: Handles queries in multiple languages with automatic translation for global accessibility. By combining generative AI with Service Now’s workflow automation, Now Assist helps organizations reduce manual effort, improve self-service, and accelerate decision-making. It’s designed for tasks like case summarization, email drafting, and incident avoidance, potentially saving significant time and costs (e.g., up to 54% efficiency gains in some implementations). Required Roles in Now Assist Area / Feature Required Role Purpose / Access Provided Now Assist Administration now_assist_admin Access to Now Assist Admin Console, skill configuration, data governance, embeddings, external search setup. Now Assist Panel (Sidebar) now_assist_panel_user Allows users to access and interact with the Now Assist panel in Next Experience UI. Now Assist for ITSM itil Use AI summaries, resolutions, and recommendations in ITSM workspace. Now Assist for CSM customer_service_agent Use Now Assist in CSM Configurable Workspace for customer cases. Now Assist for HR sn_hr_core_case_writer HR agents can use Now Assist for HR Case Management workflows. AI Search Genius Results None End users can access AI-driven search without special roles. Virtual Agent + GenAI None End users can chat with GenAI-powered Virtual Agent. Administrators admin Full access to all Now Assist features and configuration. 1.     How to Enable Now Assist Enabling Now Assist requires licensing, plugin activation, and configuration. It’s available as a service Now Store app and works on supported releases (e.g., Xanadu or later). Here’s a step-by-step guide: 1.1 Verify Prerequisites and Licensing:    – Ensure your instance is in a compatible version (check service Now release notes).    – You need an active subscription for Now Assist (e.g., Now Assist for ITSM, CSM, HRSD)      Contact your service Now account representative to purchase or confirm entitlements.    – For on-premises or self-hosted setups, ensure infrastructure meets specs (e.g., AWS, GCP, or Azure support). 1.2. Install Plugins from service Now Store    – Navigate to All > System Definition > Plugins (or use the service Now Store).    – Search for and request the relevant Now Assist plugin (e.g., “Now Assist for ITSM”).    – Once processed (may take a few minutes), install it via the Plugins manager. Sync plugins if needed by clicking the Sync button. 2. Access the Now Assist Admin Console    – Log in as an admin and navigate to All > Now Assist Admin Console (or search for “Now Assist” in the navigator).    – Review your Account Information page to verify entitlements, plugin status, and opt-out of data sharing if required (configurable by data stewards for compliance). 3. Activate Skills and Features    – In the Features tab, select the category (e.g., Technology for ITSM).    – Choose a skill (e.g., Case Summarization) and click View Details.    – Configure settings (e.g., data sources, language/region—defaults to English with multilingual detection).    – Click Save & Next through the guided setup, then activate. Plugin   ID   Action   Now Assist in Virtual Agent com.glide.now_assist.va Install Conversational Catalog Request (Bundled) Auto-included Step 4: Turn on Now Assist in Virtual Agent (Guided Setup) Go to Now Assist Admin > Features > Platform > Conversational Experience Click Set up Now Assist in Virtual Agent  Search for “Assistant” in the application navigator Click “Set up Now Assist in Virtual Agent.” Turn on Now Assist Virtual Agent setup. Turn on the Now Assist panel 4.1 Enable Skills: Now Assist Multi-Turn Catalog Ordering → ON Now Assist Q&A Genius Results → ON (recommended) 4.2 Configure Assistant: Information Sources: Match portal search profile Channels: Enable Service Portal / Employee Center LLM Model: Use Hosted (Azure OpenAI) for full features How to Connect Now Assist with Virtual Agent on the Service Portal in ServiceNow LLM model visible in virtual agent Overview Steps-   Step 1: Install/Verify Required Plugins Navigate to System Definition > Plugins. Search and ensure these are Installed/Active: com.snc.now_assist_va (Now Assist Virtual Agent) com.glide.cs.now_assist (Now Assist Core) com.snc.virtual_agent (Virtual Agent base) If missing, install them (may require instance restart).   Use the low-code Setup Assistant for guided configuration – this “connects” Now Assist to Virtual Agent by creating an LLM-powered assistant. Go to Conversational Interfaces > Home. Under Now Assist in Virtual Agent, click Get Started or Setup Assistant. Alternatively: Now Assist Admin > Features > Platform > Conversational Experience. In the wizard: Assistant Name: Enter, e.g., “Service Portal Now Assist Bot”. Enable Skills: Check Now Assist Q&A (for KB/search) and Now Assist Topics (for workflows/catalog ordering). Information Sources: Add Knowledge Base, Service Catalog, and any custom tables. Copy Existing Config: If migrating from legacy VA, select “Yes” to import topics/search sources. Promoted Topics: Add quick-start options like “Reset Password” or “Order Laptop”. Click Create Assistant. This publishes the AI-enhanced VA. Step 2: Enable on Service Portal Open the new assistant: Conversational Interfaces > Assistants > [Your Assistant Name]. Go to the Display Experience tab (or Channels for older releases. Under Portals: Select your Service Portal (e.g., default /sp or a custom one from Service Portal > Portals). Toggle Enable Now Assist (this disables legacy VA automatically). Optional: Enable Pinning for persistent chat (set system property com.glide.cs.now_assist_va.enable_pinning to true via System Properties). Save changes. The chat bubble on /sp now uses Now Assist. Step 3: Configure Agent Chat for the Portal

Policy Exception in GRC 1. What is Policy Exception? A policy exception is a formally documented and approved deviation from a policy when a user or business unit cannot meet specific policy requirements. In simple words it provides temporary relief for control owners that are unable to meet compliance requirements. It allows temporary non-compliance under controlled conditions by capturing the justification, assessing the associated risk, and ensuring the exception is reviewed, approved, and tracked within the GRC framework. 2. Purpose of Policy Exception? Allows users to request documented exceptions when they cannot comply with a policy. Ensures exceptions are reviewed and approved to maintain controlled compliance. Helps identify and manage risks associated with policy deviations. Promotes accountability by requiring justification and transparency. 3. Roles Required Role Name Description sn_grc.business_user A GRC role for users who actively work on risk, compliance, and policy tasks. They can create/update issues, take/approve assessments, respond to evidence requests, and request/approve policy exceptions. Intended for broader participation in GRC processes. sn_grc.business_user_lite A limited-scope role for business stakeholders needing basic GRC interaction. They can report/read issues, respond to assigned tasks (attestations, evidence, questionnaires), and view/submit policy exceptions, but with fewer permissions than full business_user. 4. Process Flow Diagram for Policy Exception 5. Policy Exception – FORM View Navigate to All > Policies and Compliance > Policies Exceptions > My policy Exceptions > New Sections 6. Policy Exception All Fields   Field Description Number Unique identification number. Requester Person requesting the policy exception, usually the control owner. Approval group Group that has the compliance manager role. You cannot edit the approval group if the policy exception reaches Review state. If you do not provide an approval group, then the field defaults to compliance manager. Compliance manager is the default role if the policy exception is raised from any upstream application that is integrated with GRC. Approver User from the approval group. If the exception policy moves to the Analyze State, then you must select an approver. State State of the policy exception within the approval workflow. Substate Approval substate of the policy exception within the approval workflow. Priority Approval priority of this policy exception Watch list Users that are notified when the request is updated. Name Unique name of the policy exception. Reason Reason for requesting the policy exception. The requester can change the reason until the policy exception is approved. Justification Statement of explanation for the policy exception. Justification is also displayed in the additional comments. Source type Type of policy exception that you want to create. The options are: Control objective Control objective associated with this policy exception. Issue Issue associated with this policy exception. Target record Target record table on which the policy exception is applied. This table is also referenced in the Policy eception target table field of the Policy Exception Integration Registry Form. Risk rating Select the risk rating as determined by the risk assessment performed on the policy exception. Risk description Description of the risk as performed by the risk manager during risk assessment. Analysis of risk and impact Details on the likelihood of this risk occurring and residual impacts of this risk on the policy exception. Risk mitigation plan The risk mitigation plan for this policy exception. Valid from Day on which the policy exception begins. Valid to Day on which the policy exception ends. Duration Number of days between the Valid From and Valid to dates. Approved extensions Number of times extensions have been requested so far and have been approved. Remaining extensions Number of times extensions can be requested in future. Created Date on which the policy exception was requested. Date approved Date on which the request was approved. Extension date Requested extension date, which is after the Valid to date. Extension reason Reason for extension. Original valid to Date until which the policy exception was originally requested and approved. The original Valid to date is populated only when the extension is approved. Work Notes Work notes can be used by exception reviewers and approvers to share Information about the exception. Additional comments These comments are used by the reviewer to communicate additional information to the exception requester. 7. Policy Exception States and its Lifecycle 7.1. How to request Policy Exception Login to esc Portal > Open ‘Request Extension’ Record Producer > Submit Fill all the required fields Submit the Request 7.2. States of Policy Exception New When creating new policy exception from Native UI then state is NEW An exception request is created because a user, team, or system cannot meet a specific policy requirement. Person involved in this state is the Requestor (business user, system owner, or application owner). Goal is to document the need for the exception, including justification, scope, risk, and proposed compensating controls. Provide all the mandatory information and save the record then , once request gets created then state changs from New to Analyze      2. Analyze When Policy exception record is created then it is in Analyze state. The exception is being evaluated for risk, impact, and validity to determine whether it should move forward. Persons involved in this state are Risk team, Compliance/GRC analysts, and sometimes the Policy Owner. Goal is to review the justification, assess risks, determine required compensating controls, and confirm whether the request is reasonable. Provide Approver and Risk rating then click on ‘Request Compliance Review’ then state will change from Analyze to Review      3. Review Detailed review of the refined exception request after analysis is complete. Persons involved in this state are, reviewers such as department leads, technical SMEs, or policy owners. Goal is to validate accuracy, check completeness, ensure risks are understood, and confirm alignment with business/legal requirements. Click on UI action ‘Request Additional Approval’ but make sure your requester has manager assigned then state will change from Review to Awaiting Approval.    4. Awaiting Approval The exception has passed review and is now pending formal approval. Designated Approvers such as senior leadership, risk committees, compliance managers, or policy owners are responsible in this state Goal is