Logging and Debugging Server-Side Logging (gs)  These methods belong to the GlideSystem (gs) object and are used in server side scripting such as Business Rules, Script Includes.  1. gs.info(), gs.warn(), gs.error()  These are the modern standards. They write to the System Log [sys_log] table. They are “level-aware,” meaning you can filter your logs by severity.  Example: gs.info(“User {0} has logged in.”, gs.getUserName());  Best for: Production-ready code and general auditing.  Use gs.info() if you are building a Scoped Application or want to follow the latest ServiceNow best practices.  2. gs.log()  The “old reliable.” It also writes to the System Log but allows you to specify a Source column, which makes filtering much easier in the list view.  Example: gs.log(“Processing record”, “MyCustomApp”);  Use gs.log() only if you are working in the Global Scope and specifically want to use a custom string in the Source column for easy filtering.  Note: This is not available in Scoped Applications (you must use gs.info there).  3. gs.print()  It writes to the localhost log file on the server but does not always appear in the sys_log table UI.  Example: gs.print(“Hello from the background script”);  Best for: Running scripts in the “Background Scripts” module where you want an immediate output on the screen.  4. gs.debug()  This only logs if the system property glide.debug.log (or a specific session debug) is enabled.  Example: gs.debug(“Variable X is: ” + x);  Best for: Troubleshooting complex logic without cluttering the logs for every user.  Client-Side Logging (console)  These run in the user’s browser (Chrome, Firefox, etc.) and are used in Client Scripts and UI Scripts.  console.log() / console.debug()  These don’t write to the ServiceNow database at all. They write to the Browser Console .  console.log()   This is the standard way to output general information to the browser console. It is the most commonly used tool for “sanity checking” values while building a UI feature.  For example, print the new value while running OnChange Client script,  console.log(“The new value of the field is: ” + newValue);   console.debug()   Functionally, this is almost identical to console.log(). However, it is intended for “verbose” or “debug” level messages that you might not want to see all the time.  Example: console.debug(“Current Field Value: ” + g_form.getValue(‘short_description’));  Best for: Real-time debugging of UI behavior.  Note: Always remove these before moving code to Production, as they are visible to any tech-savvy user.  log.print()  In standard ServiceNow JavaScript, log.print is not a native global function. You might see this in specific integrations (like IntegrationHub ETL) or if a developer has created a custom log object. Usually, if you try to run this in a standard Business Rule, it will throw an error.      Method  Environment  Log Destination  Scoped App Compatible?  gs.info()  Server  System Log (sys_log)  Yes  gs.log()  Server  System Log (sys_log)  No (Global only)  gs.print()  Server  Localhost File / Script Output  Yes  gs.debug()  Server  System Log (if debug enabled)  Yes  console.debug()  Client  Browser Console  Yes    Server-Side Debugging  This applies to Business Rules, Script Includes, Scheduled Jobs, and UI Actions (server-side).  The Script Debugger   The Script Debugger is a built-in interface that allows you to set breakpoints. When the code hits that line, the system pauses execution, allowing you to inspect variable values in real-time.  How to use: Open “Script Debugger” in the Filter Navigator, set a breakpoint (click the line number in your script), and trigger the action.  Best for: Complex logic where you need to see how variables change step-by-step.  Script Tracer   The Script Tracer records every server-side script that executes during a transaction. It captures:  Business Rules  Script Includes  Script Actions  UI Actions (Server-side) It shows you the order of execution and the state of the record before and after each script ran.  Open the Tracer: Navigate to System Diagnostics > Script Tracer.  Start Tracing: Click the Start Tracer button in the top right.  Perform the Action: Go to your form (e.g., an Incident) and perform the action you want to debug (e.g., click “Update” or change the “State”).  Stop and Analyze: Go back to the Script Tracer tab and click Stop Tracer.  Review the Trace: You will see a list of every script that ran.  Session Debugging   ServiceNow allows you to toggle specific debug logs that appear at the bottom of your UI page.  How to use: Navigate to System Diagnostics > Session Debug. You can choose “Debug Business Rule,” “Debug Security (ACL),” or “Debug SQL.”  Best for: Seeing which Business Rules are firing and in what order.  Background Scripts   The Scripts – Background module is the “scratchpad” of ServiceNow. You can paste a snippet of code and run it immediately to see the output.  Best for: Testing a specific function or a GlideRecord query without having to trigger a record update.  Client-Side Debugging  This applies to Client Scripts, UI Policies, and Catalog Client Scripts.  Since client scripts run in the browser,   Console: Use console.log() to print values or debugger; in your code to force the browser to pause execution.  Sources Tab: You can find your client script in the “Sources” tab and add breakpoints directly in the browser.  The JavaScript Log & Field Watcher  ServiceNow provides a built-in “JavaScript Log” window that sits inside the platform UI.  Field Watcher: Right-click any field label and select Watch field. A pane opens at the bottom showing every script, policy, or ACL that touches that specific field.  Best for: Figuring out “What script just hid this field?” or “Why did this value change to 10?”    Tool  Environment  Use Case  Script Debugger  Server  Pausing execution and inspecting variables.  Background Scripts  Server  Testing standalone code snippets quickly.  Session Debug  Server  Watching Business Rules and ACLs in real-time.  Field Watcher  Client  Tracking why a specific field’s value/visibility changed.  Browser Console  Client  Inspecting UI errors and logging manual triggers.   

SetWorkflow and autoSysFields Methods SetWorkflow   In the ServiceNow, setWorkflow() is generally used to prevent the running of business rules (or other scripts) that would be triggered by any server side updates you’re making.   setWorfklow can be used in any server-side script, including Business Rules, Script Includes, Scheduled Jobs, and (server-side) UI Actions.   The setWorkflow() method utilizes a single boolean argument of either true or false. The arguments are written as follows:   setWorkflow(false): All business rules on the table for the current scripted action (insert, update, delete, query) will be ignored.   setWorkflow(true): All business rules on the table for the current scripted action (insert, update, delete, query) will be executed.  For example, Update the Urgency to High for all active Incidents where the Assignment Group is Network, without triggering any Business Rules that would normally execute during the update.  Autosysfields  autoSysFields is used to to control whether the system automatically updates “system” fields when a record is inserted or updated.  By default, ServiceNow manages five specific fields for every record, Created by [sys_created_by],Created [sys_created_on], Updated [sys_updated_on], Updated by [sys_updated_by], Updates [sys_mod_count],  The autoSysFields () method utilizes a single boolean argument of either true or false. The arguments are written as follows:  autoSysFields(false): When autoSysFields is set to false, system field values will not be updated.  autoSysFields(true): When autoSysFields is set to true, system field values will be updated.  For example, if we use the same script that includes the setWorkflow(false) method and additionally add autoSysFields(false), the urgency field will be updated to Medium. However, the system fields (such as Updated by, Updated on, etc.) will not be modified and will remain unchanged.  Here, we can observe that the system fields Updated and Updated by are not refreshed with the latest timestamp or user name. 

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​.