Scripting   How to access last worknotes? We can use “current.comments.getJournalEntry(1)” to access last worknotes. hasRole() It returns true if the current user has the specified role or the admin role How to get system property? getProperty(“PROPERTY_NAME “); How to set system property? setProperty(“PROPERTY_NAME “, “property_value”); How to alert Assigned to user name from client script? var p=g_form.getReference(“assigned_to”).name; alert(p); How to access user data from client script g_user.userName g_user.userID g_user.firstName How to access user data from Server Side Script var firstName = gs.getUser().getFirstName(); var email = gs.getUser().getEmail(); getUser(); How to get sys_id from client script alert(g_form.getUniqueValue()); How to get current form table display value in client script alert(g_form.getDisplayValue()); and alert(g_form.getDisplayValue(“assigned_to”)) How to hide the related list from client script hideRelatedList(“REL:SYSIDOFRELATEDLIST”); How to hide section from script setSectionDisplay(“closure_information”, true); How to fire Event from Server-side script eventQueue(“EVENTNAME”, GlideRecord, Parm1, Parm2) How to write GlideRecord on incident to get active records Var gr=New GlideRecord(“incident”); addQuery(“active”,true); query(); if(gr.next()){ info(gr.number); } G-FORM:GlideForm.js is the Javascript class used to customize forms. getValue(‘short_description’) setValue(‘short_description’, “”) addOption(‘priority’, ‘2.5’, ‘2.5 – Moderately High’, 3) getTableName() addErrorMessage(‘This is an error’) addInfoMessage(‘The top five fields in this form are mandatory’) showFieldMsg(‘impact’,’Low impact response time can be one week’,’info’) showFieldMsg(‘impact’,’Low impact not allowed with High priority’,’error’) flash(“incident.number”, “#FFFACD”, 0) g_user: g_user is a global object in GlideUser, can only used in Client Script contains name and role information about the current user. userName userID firstName getClientData(“loginlanguage”) hasRole(‘admin’) hasRoleExactly(‘util’) hasRoleFromList(“itil, maint”) hasRoles() Client Script 1.To alert fullname of user: function onLoad() {        var p=g_user.getFullName();     alert(‘This is my first client Script= ‘+p); } 2.To alert If the Record is new or not: function onLoad() {     if (g_form.isNewRecord()){         alert(‘This is new Record’);     }     else{         alert(‘This is not a new record’);     } } 3.Use of different API’s: function onLoad() {     g_form.setReadOnly(‘u_email’,true);     g_form.setValue(‘u_description’,’hiiiiiii’);       g_form.clearOptions(‘u_category’);     g_form.getLabelOf(‘u_number’);     g_form.addInfoMessage(‘hi’);     g_form.setMandatory(‘u_first_name’,true);     g_form.setMandatory(‘u_last_name’,true);     if (g_user.hasRole(admin)){     g_form.removeOption(‘u_state’,’Maharashtra’);     } } 4.To make field visible after creating record but not while creating Record function onLoad() {    if(g_form.isNewRecord()){ g_form.setVisible(“u_convert_to”,false); }     else {         g_form.setVisible(“u_convert_to”,true);     } } 5.when Assigned To value changes, populte mail id of changed user in email field and populate user name in short description function onChange(control, oldValue, newValue, isLoading, isTemplate) {    if (isLoading || newValue === ”) {       return;    } var p=g_form.getReference(“u_assigned_to”).email;     g_form.setValue(“u_email”,p);     g_form.setMandatory(“u_first_name”,true);     g_form.setValue(“u_short_description”,’This is :’+g_user.getFullName()); } 6.when Assigned To value changes,populate user’s first name in short description function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === ”) { return;   } var p = g_form.getValue(“u_assigned_to”);     var name= g_form.getReference(“u_assigned_to”);     g_form.setValue(“u_short_description”, ‘This is’+name.first_name); alert(newValue); alert(oldValue);    } 7.Confirm details before submit form function onSubmit() {    //Type appropriate comment here, and begin script below    var a = g_form.getValue(“u_first_name”);     var b = g_form.getValue(“u_last_name”);     var con= confirm( ‘You Entered below datails-n The first name is- ‘+a+’n The last name is- ‘+b+’n  Do you confirm the details?’ );     if(con==true){         return;     }     else{         return 0;     } } 8. On Submit function onSubmit() {    //Type appropriate comment here, and begin script below     var p = g_form.getValue(“u_assigned_to”);     var name= g_form.getReference(“u_assigned_to”);     g_form.setValue(“u_short_description”, name.first_name); alert(p); }  9. On editing first name in list view (onCellEdit Client Script) function onCellEdit(sysIDs, table, oldValues, newValue, callback) {   var saveAndClose = true;     alert(sysIDs);     alert(table);     alert( oldValues);     alert(newValue);     alert(callback);  callback(saveAndClose);  } Advance Client Script Client Script: Client Side Objects: 1. G-FORM:GlideForm.js is the Javascript class used to customize forms. g_form.getValue(‘short_description’)g_form.setValue(‘short_description’, “”)g_form.addOption(‘priority’, ‘2.5’, ‘2.5 – Moderately High’, 3)g_form.getTableName()g_form.addErrorMessage(‘This is an error’)g_form.addInfoMessage(‘The top five fields in this form are mandatory’)g_form.showFieldMsg(‘impact’,’Low impact response time can be one week’,’info’)g_form.showFieldMsg(‘impact’,’Low impact not allowed with High priority’,’error’)g_form.flash(“incident.number”, “#FFFACD”, 0)   2. G-User: g_user is a global object in GlideUser. g_user is a Client Script Object and contains name and role information about the current user. g_user.userNameg_user.userIDg_user.firstNameg_user.getClientData(“loginlanguage”)g_user.hasRole(‘admin’)g_user.hasRoleExactly(‘util’)g_user.hasRoleFromList(“itil, maint”)g_user.hasRoles() Client Side Examples: 1. Problem Statement: For New Record show alert. function onLoad() { if (g_form.isNewRecord()){ alert(‘This is new Record’); } else{ alert(‘This is not a new record’); } } ……………………………………………………………………………………………………….. 2. Problem Statement: To make “Convert to” field visible after creating record but not while creating Record function onLoad() {   if(g_form.isNewRecord()){ g_form.setVisible(“u_convert_to”,false); } else { g_form.setVisible(“u_convert_to”,true); } } 3. Problem Statement: When Assigned To value changes, populte mail id of changed user in email field and populate user name in short description function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === ”) { return; } var p=g_form.getReference(“u_assigned_to”).email; g_form.setValue(“u_email”,p); g_form.setMandatory(“u_first_name”,true); g_form.setValue(“u_short_description”,’This is :’+g_user.getFullName()); } ……………………………………………………………………………………………………….. 4. Problem Statement: Confirm details before submit form function onSubmit() { //Type appropriate comment here, and begin script below var a = g_form.getValue(“u_first_name”); var b = g_form.getValue(“u_last_name”); var con= confirm( ‘You Entered below datails-n The first name is- ‘+a+’n The last name is- ‘+b+’n Do you confirm the details?’ ); if(con==true){ return; } else{ return 0; } } ……………………………………………………………………………………………………….. 5. Problem Statement: Hide the Clouser Information section from form while creating new record function onLoad() {//Type appropriate comment here, and begin script belowif(g_form.isNewRecord()){g_form.setSectionDisplay(“closure_information”, false);}else{g_form.setSectionDisplay(“closure_information”, true)}} ……………………………………………………………………………………………………….. 6. Problem Statement: Remove New state from the choice if it is not New function onLoad() {//Type appropriate comment here, and begin script belowif(g_form.getValue(“state”)==1){}else{g_form.removeOption(“state”,’1′);} } 7. Problem Statement: On change—Comments Make Work Notes Optional function onChange(control, oldValue, newValue, isLoading, isTemplate) {var requireOtherField = (newValue == ”);g_form.setMandatory(‘work_notes’, requireOtherField);} ……………………………………………………………………………………………………….. 8. Problem Statement: On Change- Work Notes Make Comments Optional function onChange(control, oldValue, newValue, isLoading, isTemplate) {var requireOtherField = (newValue == ”) ;g_form.setMandatory(‘comments’, requireOtherField);} 9. Problem Statement: If Caller is a VIP User then priority should be always P1. On Change Client Script on Caller Field function onChange(control, oldValue, newValue, isLoading, isTemplate) {if (isLoading || newValue === ”) {return;}g_form.getReference(‘caller_id’, priorityCallback); } function priorityCallback(caller){ if (caller.vip == ‘true’) {g_form.setValue(“impact”,1);g_form.setValue(“urgency”,1); }} ……………………………………………………………………………………………………….. 10. Problem Statement: Start date should be less than End Date,if not show alert Start date validation –function onChange(control, oldValue, newValue,

Incident Process in Service-now We have incident where we have following process. We have following state for incident. New In Progress Pending Customer Pending Information Customer Update Resolved Closed Incident Process till Close New created incident in New State Fulfiller should ACK the ticket by clicking on ACK ui action and incident should go in “In Progress” state. Fullfiller can change the state to Pending customer to get information from user i.e. caller. When user i.e. caller send the information then incident state should changed to “Customer update” Fullfiller then change the state to In Progress. After resolving ticket fullfiller can change the state to Resolved. Fullfiller can cancelled the ticket when it is in In Progess. Fullfiller can Reject the incident before Acknowledgment. Fullfiller will not close the incident, to close the incident we have schedule job which will run daily. Incident Auto Close schedule job will close the incient which are in state=resolved the update date is less than 5 days of current date. Note: User can Cancelled the ticket by changing the state=Closed and closed code=Cancelled User can Reject the ticket by changing the state=Closed and closed code=Reject Close Code and Close Notes: When Incident changed the state to Resolved or Closed , Close Code and Closed Notes are mandatory fields. Close Code is choice field Close notes is String field. Close Code and Close Notes fields having more specific details about “Why we are closing the Incident.” SLA: Responce SLA start when incident is created and stops when Incident Acknowledged (If ACK_Time and ACK_By field has value then incident is acknowledged)Resolution SLA start when the incident is in “In Progress” and stops when incident is Closed and pause when incident is in one of the state i.e.Pending Customer, pending information, customer update and resolved.  Incident Priority: Priority field is always readonly and it is depends on urgency and sevirity fields using datalooup We have one client script i.e. if the caller is VIP, then the priority should be P1 using client script. Incident Assignment Rule We have assignment rules for setting assignment group as per Incident Category and Incident Subcategory  

ServiceNow Basics Questions & Answers What is ServiceNow? ServiceNow is a cloud-based digital platform that used by organizations to automate, manage, and improve businesses processes, especially in IT Service Management (ITSM). What is User and its types? A User in servicenow is anyone who can log into the platform or who can access servicenow platform.1 Admin – Admin is a developer who is responsible for development.2 End User – A user who only uses application without any role assigned. He can raise the ticket/issue/request.3 ITIL user – fulfil the requst of end user.4 Maint user – Maint user is like a super admin.This user has access to acivate paid plugins.   What is Elevated Role? Elevate role is a role in which users will not get access after logging in. If the user needs that access, then the user needs to get that access manually. Why use Elevated Roles? To improve security and to follow best practice. To limit the amount of time someone has all admin privileges. What are the types of Table in ServiceNow? There are mainly four types of table in ServiceNow. sys_ table: This type of table is created by default. Only admin can access this table. This shown sys_user_role. Out of the Box Table : Name table is the table who starts with names like Incident, Practice. This tables are the existing tables. Sometimes they called out of the box tables. Custom Tables : The table we created by us called as customised table. After creating this it shown in “u_” table. It also called as user defined table. v_ table : this is the virtual table. allows you to display and interact with data from external systems as if it were a native table, without actually storing it in the ServiceNow database What is Dictionary overriding? Dictionary Override will come into a picture when we have a parent-child relationship between tables. By default, all fields and their attributes are inherited from parent table to child tables. Suppose you want to make a difference in one of the child tables for inherited fields then we will go for Dictionary override.  [Dictionary Override to allow a field in a child table to have a different behavior than the same field in a parent table]. We can override following properties: –  Override Reference Qualifiers Override Dependant Override Default Value Override Read Only Override Calculations Override Mandatory Override Attributes Override Display Values   What is Application Menu Application menu is the menu that organize and display modules. It is a group of related modules. Which means Incident is an application menu which has modules like, All -> Create new -> Open -> Assigned to me  They are located in left side of the interface which has in alphabetical order. Access based on roles, Which mean what you see depends upon what role you have. What is Update set? Update set is a component which is used to capture configurational changes and can be moved from one instance to another instance. We have update_sync property at table level. If it’s true, then the system will consider this table as a “configuration table”. So, whatever we are creating or updating records in that table will get captured into update sets.    What is Client script? Client script is a script that runs on client side (that is in users’ browser). Using Client script, we can change the look and feel of the form. Client Script is used to perform validations on forms.  There are four types of Client script: –  Onload – onLoad client script runs when the form is loaded.     onChange– onChangeclient script runs when the specific field value changes. OnChange client script will also run onLoad.   There are some parameters in onChange Script: control, oldValue, newValue, isLoading, isTemplate  onSubmit– onSubmit client script runs when the form is submitted.    onCellEdit-In a list view when we edit a particular cell value that time onCellEdit client script    There are some parameters in onCellEdit Script: sysIDs, table, oldValues, newValue, callback  How onChange client script run on onload client script? Normally when we are loading a form or new incident first the html structure will get loaded without values it means we don’t have any values on the form it is empty after that we will get the values from the database, and it will populate on the form. So, in this scenario values are getting change from empty values to database values. So, in this way, changing client script will run.  How to stop running the onchange Client script onload? function onChange(control, oldValue, newValue, isLoading, isTemplate)   {    if (isLoading || newValue === ”)   {      return false;  //when isLoading is false, the onChange script will not run on form load.   }  }  So, if isLoading is false that time onChange Client script will not load onLoad  . Difference between UI policy and Client script? UI policy UI policy is used in client side. Based on Condition we can make field mandatory, read only or visible. UI policy executes after Client Script Client script Client script executes before UI Policy  Client script can’t access the field which is not present on form  What is List Layout? A List Layout is the default configuration of columns and their order that users see when they open a list view for a specific table (like Incident, Change Request, etc.) in ServiceNow.  It’s essentially a global setting controlled by admins that defines:  Which fields (columns) appear in a list view  The order of those columns  Difference between list layout and Personalized list? Feature  List Layout  Personalized List  Affects  All users  Individual user  Requires admin role  ✅ Yes  ❌ No  Used for  Setting default list columns and order  User-specific adjustments  Changes saved  In the system list configuration  In user preferences  What is Business Rule? A Business rule is a server-side component that runs on the server side. It runs when a record is Displayed, Inserted, Updated, Deleted, or Quired.   There are four types:  Before: It runs before a database operation; it allows modifications before the record is saved. We cannot use the current Update method. For example, if you apply for leave, it will first go to the database and see if you have any leave left. After: It Execute after a database operation, it is suitable for actions that depend on the saved records. For example, if you submit a leave application for one day and then your leave is still available in the database, one of them is submitted as a leave application.  Async: Asynchronous business rules will run after the after-business rule. Asynchronous business rules will run asynchronously; it will not hold system to execute asynchronous script. It cannot access the previous object. For example, if you have made the payment, even if you receive a message late after your money has been transferred, it

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.

UI Policy UI Policy is a client-side configuration rule that dynamically controls the behavior of form elements (such as fields, sections, or related lists) based on specified conditions. It allows administrators to make fields mandatory, read-only, or visible/hidden without writing code, ensuring a better user experience and data integrity directly in the user interface. UI Policies apply to forms and execute them in the browser. They are stored in the ‘sys_ui_policy’ table, with associated actions in sys_ui_policy_action. A UI policy is a client-side rule that dynamically controls form behavior based on specific conditions. It allows administrators to easily make fields mandatory, read-only, or visible/hidden without writing code, improving user experience and data integrity by adapting the interface in real-time as users interact with the form. For more complex logic, UI policies can include optional scripts, but they are preferred over client scripts for simple UI changes due to faster performance and easier maintenance. Steps to create UI Policy: Go to Application menu and search UI policies under system UI find the UI Policies After searching and navigating it, and then creating a new entry, you will see a form like this. Here is a Simple explanation of the checkboxes present on this form: Active – Enables or disables the UI Policy. The policy works only when this is checked. Reverse if false – Reverses the UI Policy actions when the condition evaluates to false. On load – Executes the UI Policy when the form is loaded. On change – Executes the UI Policy when the specified field value changes. Global – Makes the UI Policy applicable across all views of the form. Inherit – Allows child tables to inherit this UI Policy from the parent table. Then, select the table on which the UI Policy needs to be applied. For example, as shown in the screenshot below, the Incident table is selected. Also, make sure to mention Short Description, as it is a mandatory field. After entering the details, do not submit the form directly. Instead, right-click on the top grey strip and select Save to save the form. After saving the form, you will see the Sections. Within these sections, you need to create UI Policy Actions for the field on which you want to apply the policy. Example: Since Incident is selected, choose the specific field on which you want to apply the UI Policy. Then, define how the policy should behave for that field—for example, set Mandatory = True, as shown here, to make the field mandatory. Here is the output shown below. UI Policies in ServiceNow are a powerful, no-code tool for dynamically controlling form behavior, such as setting fields to mandatory, read-only, or visible/hidden based on conditions. They enhance data quality, streamline user experience, and are the recommended approach for simple client-side UI modifications due to their superior performance and ease of maintenance compared to client scripts. For more advanced needs, UI policies can incorporate scripts, but for straightforward changes, they remain the efficient and preferred choice.

Retroactive Start SLA Introduction: In ServiceNow, a retroactive SLA (more precisely, an SLA with Retroactive start enabled) is a configuration option in SLA Definitions that allows a newly attached SLA to “backdate” its start time to an earlier point on the task record (typically the task’s creation time or another specified date/time field), rather than starting the clock from the moment the SLA attaches. Definition: Retroactive Start allows an SLA to begin counting from an earlier time in the past, instead of starting only when the SLA conditions are met. Retroactive Start is a simple but powerful setting for SLAs in tools like ServiceNow. Normally, when an SLA gets attached to a ticket (for example, when the priority changes), the timer starts right at that moment, giving the team the full allowed time from then on. When you turn on Retroactive Start, the SLA timer goes back in time and starts from when the ticket was originally created. This means all the time that already passed before the SLA was attached counts against the deadline. So, if a lot of time has already gone by, the team has less time left — or the SLA might even breach immediately. It makes the measurement fairer because it treats the issue as if the stricter SLA was always there, reflecting how long the customer has really been waiting. Example: Ticket created on Monday at 10 AM (low priority, 48-hour SLA). On Wednesday at 10 AM (48 hours later), priority upgraded to critical (new 8-hour SLA attaches). Without Retroactive Start: New SLA starts Wednesday 10 AM. Team has full 8 hours until Wednesday 6 PM. With Retroactive Start (set to “Created” date): The new SLA pretends it started Monday at 10 AM. 48 hours have already passed, so it’s overdue immediately! (Or whatever time is left based on the new duration.) This pushes the team to act faster on escalated issues. Steps to create retroactive SLA In Application menu Search Service Level Management, in that find SLA Definitions After this we will go to form of the SLA: This checkbox is located in the Start Condition section. By default, this is unchecked; we have to click this to perform further operations. After Clicking on this checkbox, we will find the ‘Set Start to’ filed which have choices where this Retroactive SLA will start on which field. Here is the real time example how Retroactive start SLA works: In this, the only normal SLA triggered but when changing condition or where to start the retroactive SLA then only our SLA works. When change in condition here is the retroactive SLA will start and counts the whole time of that incident when it created. In short, Retroactive SLA makes time tracking fairer by backdating the SLA clock to the ticket’s creation and giving credit for past waiting times. It ensures accurate, realistic deadlines — especially when priorities change — reflecting how long the customer has truly been waiting, without unfair breaches.

HRSD (Human Resource Service Delivery) 1.What is HRSD    It is a Service Now platform module that helps organizations digitalize, streamline and automate HR process. 1.1 What HRSD does Onboarding new employees Offboarding (resignations, exits) Leave and attendance requests Payroll and benefits queries Employee documents and policies Workplace issues or grievances 1.2 Key features of HRSD Employee Service Portal: – Employees can raise HR request using a self-service portal. Case Management: -HR Cases are tracked from start to closure. Knowledge Base: – Employees can search HR Articles (policies, FAQ’s) Workflows & Automation: – Automates approvals and HR processes. Confidentiality: – Sensitive HR data is secured with role-based access. Lifecycle Events: – Manages hire, transfer, promotion, and exit processes. 2. Plugins required to install HRSD Human Resources Scoped App:Core- com.sn_hr_core- Case and Knowledge Management HR Service Portal – com.sn_hr_service_portal- Employee Service Center for employee to raise case. Human Resources Scoped App: Lifecycle Events- com.sn_hr_lifecycle_events- Multiple activity in multiple departments in sequence e.g. onboarding Integrations-com.sn_hr_integrations. 3.Roles Required Sn_hr_core.basic : – Given to employees which will allow them to access HR Service portal. Also, they can raise HR case and view their own HR request. Sn_hr_core.case_writer: – Allows creation of HR cases on behalf of employees. This role usually given to HR assistant and HR coordinators. Sn_hr_core.case_worker: – This role is given to the HR agents so that they can work on HR cases, update case status and communicate with employees. Sn_hr_core.case_reader: – This role gives the read only access to HR cases. It is used for audit or managers who only need visibility. Sn_hr_core.manager:- This role is given to managers so that they can view team performance, reassign cases and access HR reports and dashboards. Sn_hr_core.admin:- The person who is having this role has full control of HRSD. he/she can configure the HR service. Also, he/she can create hr case template and manage HR workflows and lifecycle events. 4.COE (Center of Excellence) Center of excellence (COE) in HRSD refers to a structured approach that allows HR teams to manage and deliver services effectively. It helps in organizing various HR functions such as payroll, benefits, talent acquisition, and employee relations into distinct categories, making it easier for users to navigate and request services. · It is used to group and organize HR services, cases and tasks into logical categories. It is an extension of HR case table (sn_hr_core_case) e.g. HR Employee Relations, HR Payroll, Talent Management, Lifecycle Events, HRIT Operations. Each COE is further organized by HR topic category and detail, which defines the first-and second-level of categorization for HR services under that COE. Each COE can have one or more topic categories. Each topic category can have one or more topic details. And each topic detail can have one more HR services. The structure enables you to categorize HR services by functional area, and you configure the categorization structure and the individual HR services to meet the needs of your organization. 4.1 Topic Category  Topic categories represent the first level of grouping for HR services, like “Benefits” or “Leave Management,”     4.2 Topic Details  Topic details are the second level of categorization under a topic category, providing further specificity to the service.   4.3 HR Service  HR services are various functions and support provided by HR department to the employees e.g. onboarding, payroll processing.  HR service is the most important part of the HRSD application where we bind all the features, we described above to create an HR service.  Basically, HR services are the starting point for HR case creation and define the process for that case type form request to fulfilment.  Fields Present on the HR Service Table  Field Name  Description  Name  The display name of the HR service (e.g., “Direct Deposit Setup”).  Active  Boolean to indicate if the service is available.  Description  Detailed description of the service  Topic Category  Reference to the first-level categorization (similar to category in incident)  Topic Detail  Reference to the second-level categorization (similar to subcategory)  COE  Reference to the COE table determining the case table (e.g. sn_hr_core_case_payroll)  HR Template  Reference to an HR case template for auto-populating fields on case creation.   Record Producer  Links to employee-facing portal options.  Case Option  Additional case options for the HR service. ​  1. Add Manager to Watchlist  2. Skip Automatic User Acceptance State  3. Automatically Create draft document  4. Automatically Initiates Document tasks  5. Do Not Default Subject Person:   6. Skip Auto Assign  7. Skip Automatic User Acceptance State  8. User Cannot Cancel  Opened For/Approver view  The person who opened/made the request (the requester).  Subject Person/Task assignee view  The employee whom the HR case is about (the beneficiary or affected person).  Case creation service config  Specify a case creation view for this service.  Checklist  Who is working on a service that is checklist. In this related list, you can provide steps to help HR agents to fulfill HR cases for the associated HR service.​  4.4.1 How It works in HRSD  HR Services tie into the hierarchical structure:  COE → Topic Category → Topic Detail → HR Service  When an employee requests an HR service (via portal or case), it creates an HR case on the appropriate COE-extended table (extending sn_hr_core_case), and the “Service table fields” help control visibility of custom/COE-specific fields on the case form via OOB UI policies (e.g., “Show HR service fields on load” and “Hide HR service fields and related lists”).  5. HR Case  An HR Case in ServiceNow Human Resources Service Delivery (HRSD) is a centralized record used to manage, track, resolve, and report on employee HR-related inquiries, requests, issues, or services. It acts as the core mechanism for HR case management, similar to how an Incident or Case works in ITSM, but tailored for HR processes.  Table Structure: – Parent Table: – sn_case (Case Table)  Core HR case table: – sn_hr_core_case(extends sn_case. Used for general or core HR cases.)  5.1 Life Cycle of HR Case  Daft - Initial state when a case is created (e.g., via portal submission or manual creation). Allows editing before routing. Limited state options visible here.  Ready – Case is ready for assignment and work. All full state options become visible in the dro pdown.  Awaiting approval – Require approval before it can move to next state​. 

Reference Qualifier in Service-now 1. Reference Qualifier   :- It is used for filtering. They help refine the choices available in a reference field by defining conditions that the referenced records must meet. A reference qualifier is a filter applied to a reference field to restrict or refine the list of records that users can select from.  If you want to set default value of reference field as current user javascript:gs.getUserID(); Types of reference qualifier:- 1. Simple Reference Qualifier: –  A simple reference qualifier in Service Now is often written as an encoded query string or a Glide Record query. It’s used to filter the choices available in a reference field based on specific criteria.Uses simple AND/OR conditions to filter records. For example, you can show only users where “Active” is “true”.  How to Reach Reference Qualifier in OOB Table or Custom Table:  Open any Table of Your Choice: – Incident/Problem/Change. Step 1:-Application Navigator>Table>Open Existing Record or Create New. Step 2:- Right Click on Any Reference Field i.e. assigned to and Configure Dictionary Step 3:- We are showing Reference Specification and applying Condition. 2. Dynamic Reference Qualifier: – Dynamic reference qualifiers enable you to use a dynamic filter option to run a query against a reference field to filter the returned data set. Dynamic filter options are stored filters that can contain encoded query strings, JavaScript, or script includes, and can be used in multiple dynamic reference qualifiers. Changes made to a dynamic filter option automatically apply to all reference qualifiers that use the same dynamic filter option. Use this type of reference qualifier when you want to use the same filter on multiple forms or to provide filter functionality to “non-code savvy” implementers. The base instance provides several OOB dynamic filter options. If a dynamic filter option that meets your needs does not exist, you can create a new dynamic filter option that is specific to your requirements.All the available dynamic filters are stored in system definition>dynamic filter options.For creating the dynamic reference qualifier we must have a record in this dynamic filter options.After creating the dynamic reference qualifier you can add that filter from the Dynamic  Ref qual field. 3.Advanced Reference Qualifier: – Advanced reference qualifiers enable you to define an inline encrypted query string or JavaScript (actual code or the name of an existing script include or business rule) filter directly in the Reference qualified field of the reference qualifier. Similar to the other reference qualifier types, when the form loads, the filter is executed, and only the records that match the filter appear in the reference field. Use this type of reference qualifier for implementations that only require a simple, unique filter that cannot be handled by a simple reference qualifier, and is not used across multiple reference fields. Here Is Explanation of the code javascript: “sys_id IN” + new getgroupusers().getUser(current.u_assignment_group) 1.new getgroupusers().getUser(current.u_assignment_group) Calls the Script Include you created (getgroupusers). Passes the value of u_assignment_group (a group sys_id) to the function. The Script Include returns a comma-separated list of user sys_ids. 2. “sys_id IN” + This constructs a valid encoded query. Another way for doing Advanced reference qualifier is script include Step 1:-Application Navigator>Script Include> Create New. Step 2:- New<Name (getgroupusers)<Glide AJAX enabledScript Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. Here Is The Code :- var getgroupusers = Class.create(); getgroupusers.prototype = Object.extendsObject(AbstractAjaxProcessor, {     getUser: function(id) {         var gr = new GlideRecord(“sys_user_grmember”);         gr.addQuery(“group”, id);         gr.query();         var arr = [];         while (gr.next()) {             arr.push(gr.getValue(“user”).toString())         }         return arr.join(‘,’);     },     type: ‘getgroupusers’ });   Here Is the code Explanation in Detail :-  Script Include named getgroupusers that extends AbstractAjaxProcessor, meaning it can be called from a client script (AJAX call). Function: getUser(id) This function returns a comma-separated list of user sys_ids belonging to a given group sys_id.  Step-by-step breakdown var getgroupusers = Class.create();getgroupusers.prototype = Object.extendsObject(AbstractAjaxProcessor, { Defines a Script Include. Inherits from AbstractAjaxProcessor → allows server-side methods to be called from client-side. 1. Query the sys_user_grmember table var gr = new GlideRecord(“sys_user_grmember”);gr.addQuery(“group”, id);gr.query(); Looks at the User Group Member Filters where group equals the passed id. Runs the query. 2. Build array of user sys_ids var arr = []; while (gr.next()) {    arr.push(gr.getValue(“user”).toString());} Loops over each record. Pushes the user field value (sys_id) into an array. 3. Return a comma-separated string return arr.join(‘,’);   Here is the Output  :- Here, we get the group members in the Assigned To field from the group that we selected in the Assignment Group. This dynamic behavior ensures that the Assigned To field is populated only with valid group members, reducing manual errors and ensuring that work items are always assigned to users who actually belong to the selected group.

Dictionary Override Dictionary Override will come into a picture when we have a parent-child relationship between tables. By default, all fields and their attributes are inherited from parent table to child tables. Suppose you want to make a difference in one of the child tables for inherited fields then we will go for Dictionary override.   We can override following properties     Override Reference Qualifiers: A Reference Qualifier in Dictionary Override allows you to change or customize the filtering condition of a reference field only for a specific child table, without affecting the original parent table field.  Override Dependent:-Makes the field dependent on some other field, only in the child table.  Override Default Value: Changes the default value of the field for the child table.   Override Read Only: – Make the field read-only for this child table only.  Override Calculations: – Overrides the calculation formula used by calculated fields.  Override Mandatory: – Makes the field mandatory or not mandatory only for this child table.  Override Attributes: Allows you to override field attributes only for the child table.  Override Display Values: – Allows overriding how the field’s display value is shown for this table.  Making Dictionary Override  Search Tables in Navigation Bar to Make Tables & Click on New.  After Clicking New Page will appear in that Add Table Name à New Menu Name   for Making Child Table We Have Click on Extensible. à Controls à Extensible Click on Box & Submit it, Your Table will be made which is Parent Table.  Now go to table for Making Child Tables in that Add Table Name, In Extends Table Give Name of parent Table to Make this table a child table & submit it.  Search tables for Parent & Child Tables in Navigation Bar, Perform Dictionary Override.  Users must Make Field from Form Layout in Parent Table & That field will automatically Inherit to Child tables.  Child Table All Fields Inherit from Parent Table.  Now Add Records in Parent Tables  Note: If User adds Records to Parent Table, then that record will not be visible in Child Tables. But when we insert records in Child tables then child table records will visible Parent tables.  If we have to do Perform operation on Parent table field   Go to Parent table fields à Configure Dictionary à In Right side, their option for doing Read only, Mandatory, Display.  If we have to Perform operation on child table field   Go to child table fields à Configure Dictionary à Dictionary override-> New-> There will be all operations.  Base Table: – is the parent table  Table: – The table where we can change override property.  These are the above properties by using, we can perform dictionary override.  Ex: – If User wants to do Override the name field by Read-only then user can do with the below steps.  Go to child Table->Right click on Name->Configure Dictionary->  Click On Dictionary Override-> Click on New.  Click on -> Override Read Only-> Sumit the Record.   After submitting the record check in the child table. If filed get read-only or not.  And here the field is read only.  Note: When we Apply Override in Child table, it does not Apply to Parent table. Summary:   Dictionary Override in ServiceNow is used when you have a parent–child table relationship and want a child table to behave differently from the parent. Normally, all fields and their properties are inherited from the parent table, but with a dictionary override you can change things like default values, read‑only settings, mandatory status, reference qualifiers, calculations, attributes, and display values only for the child table. To use it, you first create a parent table (by making it extensible) and then create a child table that extends it. Any field added to the parent automatically appears in the child, but records added in the parent do not show in the child, while child records appear in the parent. To override a field, open the child table, right‑click the inherited field, go to Configure Dictionary, and create a new Dictionary Override where you select the property you want to change. The override affects only the child’s table and never the parent. 

Third Party Risk Management (TPRM)  1. What is Third Party Risk Management (TPRM)?  Third-Party Risk Management (TPRM) is the process of identifying, assessing, and managing risks from vendors, suppliers, contractors, or service providers.  The TPRM application helps you organize and standardize these processes, track third-party issues, and reduce risks to your organization’s operations, reputation, and assets. It also automates risk assessments, saving time, and reducing manual work. 1.1. Overview of TPRM   The TPRM application helps ensure that external vendors and suppliers do not disrupt business or affect performance. It allows organizations to assess third-party risks, automate processes to save time and costs, and manage risks effectively. A strong TPRM framework covers governance, roles and responsibilities, processes, and technology.   1.2. Third-Party Risks and How They Impact Your Business  Risk Type  Impact on Business  Real-World Example  Data Privacy Risk  Exposure of customer or employee personal data, leading to loss of trust and legal issues.  A marketing vendor accidentally exposes customer email addresses due to improper data handling.  Compliance Risk  Failure to meet regulatory standards, resulting in audit failures, fines, or penalties.  A payroll vendor cannot provide SOC 2 reports, putting your company at risk during compliance audits.  Security Risk  Cyberattacks on the vendor can compromise your systems or sensitive information.  A cloud storage vendor gets hacked, allowing attackers to access stored files.  Operational Risk  Vendor outages or performance issues disrupt your business operations and customer experience.  Your payment gateway provider goes down for 3 hours, stopping all customer transactions.  Financial Risk  A vendor’s financial instability affects service continuation, support, or obligations.  A small SaaS vendor suddenly shuts down due to bankruptcy, leaving your operations unsupported.  1.3. Before Starting the TPRM Flow – Required Plugins  To use TPRM and Vendor Risk Management features, ensure the following plugins are activated:  Plugin Name  Purpose  TPRM – Vendor Risk Management (sn_vdr_risk_asmt)  Core TPRM functionality including assessments, due diligence, and risk workflows  GRC Common (sn_grc)  Base tables, engine, and workflows required for risk operations  ServiceNow Workspace Experience (sn_workspace)  Allows access to Vendor Management Workspace, Due Diligence Workspace, etc.  TPRM Portal / SVDP Portal Plugin (if applicable)  Required for external vendor survey submission through SVDP portal  Note: Without sn_workspace, users cannot see Vendor Management Workspace in the workspace.  2. TPRM Workflow   3. TPRM Roles  3.1. TPRM Internal Roles  Role  Technical Role Name  Description  Contains Roles  Third-party Reader  vendor_reader  Read only access to third-party and contact records.  —  Third-party Editor  vendor_editor  Create, update, and delete third-party contact records.  vendor_reader  Third-party Assessment Reviewer  sn_vdr_risk_asmt.vendor_assessment_reviewer  View assessment & questionnaire data and comment on tiering, internal assessments, risk assessments, issues, tasks, and due diligence requests.  compliance_reader, risk_reader, task_editor, vendor_reader  Third-party Risk (TPR) Assessor  sn_vdr_risk_asmt.vendor_assessor  All reviewer permissions + manage third parties, contacts, engagements, external risk assessments, and issues.  compliance_reader, vendor_assessment_reviewer, vendor_editor, vendor_reader  Due Diligence Approver  sn_vdr_risk_asmt.approver  All reviewer permissions + approve Internal Risk Questionnaires (IRQs).  vendor_assessment_reviewer  Third-party Contract Negotiator  sn_vdr_risk_asmt.contract_negotiator  All assessor permissions + modify contract status, start date, and end date.  sn_vdr_risk_asmt.vendor_assessor  Third-party Risk (TPR) Manager  sn_vdr_risk_asmt.vendor_risk_manager  All assessor permissions + manage assessment templates, scheduled assessments, property settings, and scoring rules.  vendor_assessment_reviewer, vendor_assessor  Third-party Risk Admin  sn_vdr_risk_asmt.vendor_risk_admin  Full admin access. Manage questionnaire templates and document request templates.  assessment_admin, sn_vdr_risk_asmt.vendor_risk_manager  Third-party Reader  vendor_reader  Read only access to third-party and contact records.  —  Third-party Editor  vendor_editor  Create, update, and delete third-party contact records.  vendor_reader  Third-party Assessment Reviewer  sn_vdr_risk_asmt.vendor_assessment_reviewer  View assessment & questionnaire data and comment on tiering, internal assessments, risk assessments, issues, tasks, and due diligence requests.  compliance_reader, risk_reader, task_editor, vendor_reader  Third-party Risk (TPR) Assessor  sn_vdr_risk_asmt.vendor_assessor  All reviewer permissions + manage third parties, contacts, engagements, external risk assessments, and issues.  compliance_reader, vendor_assessment_reviewer, vendor_editor, vendor_reader  Due Diligence Approver  sn_vdr_risk_asmt.approver  All reviewer permissions + approve Internal Risk Questionnaires (IRQs).  vendor_assessment_reviewer  Third-party Contract Negotiator  sn_vdr_risk_asmt.contract_negotiator  All assessor permissions + modify contract status, start date, and end date.  sn_vdr_risk_asmt.vendor_assessor  Third-party Risk (TPR) Manager  sn_vdr_risk_asmt.vendor_risk_manager  All assessor permissions + manage assessment templates, scheduled assessments, property settings, and scoring rules.  vendor_assessment_reviewer, vendor_assessor  Third-party Risk Admin  sn_vdr_risk_asmt.vendor_risk_admin  Full admin access. Manage questionnaire templates and document request templates.  assessment_admin, sn_vdr_risk_asmt.vendor_risk_manager   3.2. TPRM External Role  Role  Description   Contains Role  Vendor Contact (vendor_contact)  Access third-party assessment portal- Answer assessment questions- Assign/manage other contacts- Communicate with TPR managers  snc_external  4. Fields in Due Diligence Field  Description / Key Points  Number  Auto-assigned unique ID starting with DDR.  State  Current stage: IRQ, external due diligence, approval, contract risk, or closed.  Request Type  Onboard: New engagement with third party. – Reassess existing engagement: Due to changes/adverse news. – Reassess for contract renewal. – Offboard with due diligence. – Offboard without due diligence: Normal IRQ still applies.  Priority  1-Critical, 2-High, 3-Moderate, 4-Low, 5-Planning  Third Party  Associated third-party organization.  Annual Spend  Money spent with the third party per year.  Engagement  Associated engagement; can be updated post-submission to link existing engagement.  Skip Contract Risk Process  Checkbox to bypass contract negotiation; replaces contract dates with engagement dates. Request closes after TPR manager approval.  Requestor  Creator of the request.  Opened  Date request was created.  Contract Start/Expiration Date  Preferred start/end dates for contract interactions.  Engagement Start/Expiration Date  Preferred start/end dates for engagement interactions.  IRQ Assessor  User responding to the Inherent Risk Questionnaire (IRQ).  Contract Negotiator  User preparing, negotiating, and approving the contract.  Assignment Group  Group responsible for the request; notifications sent automatically. Members can assign to self or others; TPR managers/assessors can modify.  Assigned To  Individual responsible for completing, reviewing, and resolving assessment tasks. Must have TPR manager/assessor role.  Short Description / Description  Summary of request purpose and requirements.  5. Process of TPRM 5.1. Request Submission    The lifecycle begins when an employee submits a Due Diligence Request through the Employee Center.  Open the Employee Service Center (ESC) portal. This is where employees submit requests related to vendors and third-party assessments.  Use the search bar at the top of the portal. Type “Due Request” in the search field.  View the search results. The portal displays all matching catalog items.  Select: “Request Third-Party Risk Due Diligence” This is the official catalog item used to start the TPRM lifecycle.  After selecting “Request Third-Party Risk Due Diligence”, the form opens.  The employee must choose the type of request they want to initiate. The available options are:  Onboard a New Vendor For introducing a new third-party vendor to the organization.  Reassess an Existing Vendor Engagement For periodic evaluations or when vendor risk/operations change.  Prepare for Contract Renewal For reviewing risk before renewing an existing contract.  Off board a Vendor For terminating the relationship with a vendor, ensuring proper closure, data return/deletion, and risk documentation.  The requester fills in key details, including:  Third Party Information   Name*, Type*, Website, Phone,