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,

ServiceNow GRC Entity 1.  Introduction: An Entity is a “person, place, object, or thing” that is tracked for risk, compliance, and audit purposes. Entities act as the fundamental building blocks for GRC activities, and they represent the specific components within an organization that are subject to controls and policies.  Examples: Examples of entities include business applications, departments, locations, or even specific IT assets like a server or a database. 2.  Roles Required: To create and manage entities, the following ServiceNow GRC Roles are required: User role Description sn_grc_ent_access.admin Role that is part of the Entity Based Access application. Assign this role to users who need to enable or disable the Entity based access on record types related to entity property and configure Entity Based Access. sn_grc_ent_access.reader Role that is part of the Entity Based Access application. Assign this role to users who require read access to the Entity Based Access configuration. sn_grc_ent_access.bulk_access_config_admin Role that is part of the Entity Based Access application. Assign this role to users who need write and update access to the bulk access update configuration. sn_grc_ent_access.bulk_access_config_reader Role that is part of the Entity Based Access application. Assign this role to users who require read access to the bulk access update configuration. sn_grc.eba_restriction_field_editor Role that is part of the Entity Based Access application. Assign this role to users who require write and update access to the Entity based access restriction field on issue records.     3.  Entity Framework Architecture This diagram shows how the GRC Entity Framework organizes business components in a clear structure. Entity Classes set the blueprint, rules, and structure for entities. Each entity has a level in the Entity Tier or Dependency Model, which shows where it fits in the organization. Entities are the real examples created from these classes, like a business unit or department. Entity Type defines the role of each entity, and the Entity Filter helps group or select entities based on their attributes. Together, these parts make it easy to manage and organize all entities in the system. 4.     Entity Types and Filters Entities that belong to more than one Entity Type are linked to all relevant types automatically without creating duplicates. Entity Types: These are the top-level categories used to organize entities in ServiceNow. Examples include: Regions Departments Applications Business Units ServiceNow TablesEach Entity Type is linked to a ServiceNow table that stores its records: Regions → Regions table Departments → Department table Applications → Business Applications table Business Units → Business Unit table EntitiesEntities are the actual records created from these tables. Examples: Regions: EMEA, APAC, AMERICAS Departments: Finance, Sales, Marketing Applications: ServiceNow, SAP Finance, MS Office Business Units: Finance BU, Sales BU, Marketing BU, HR BU In above diagram the Content is: Entity Type: Finance DepartmentsTable: DepartmentFilter Condition: Parent is Finance This selects only departments under Finance and creates entities such as Tax, Payroll, Accounts, and Revenue. These entities help manage business activities focused on Finance departments. 5.  Example: We want to create a Business Unit Entity for the Finance – Accounts Payable Department in ServiceNow GRC. Step 1: Go to Entity Type- Navigate to Entity type Entity:  A distinct, unique object or concept in the real world about which information is stored and managed. Examples include a specific person, a particular product, or a unique organization. In a database context, an entity often corresponds to a row in a table. Step 2: Select Entity Type- Entity Type:  A classification or category that defines the common characteristics, attributes, and behavior of a group of entities. It acts as a blueprint or template for individual entities. For instance, “Person,” “Product,” or “Organization” would be entity types, and specific individuals, products, or organizations would be instances (entities) of those types. Field Description Name Name of the entity type. Active Option to set the entity type as active. Compliance score (%) Compliance score of the entity type. The value is a percentage. This field is automatically set. Description Description of the entity type.         Save. Step 3: Apply Entity Filter- Entity Filter:  The Entity filters tab displays the following information: Entity filter type: Entity filter type such as Build your own conditions or select from predefined queries. Table: Table that contains the records to be queried, such as sn_audit_advanced_auditable_unit. Filter condition: Filter conditions for the source table to generate entities. Use owner field: Use the default owner to assign risks to a single user when the owner field is empty. Owner field: Person who owns any new entities generated from the entity type. Identify the user reference field on the source table to automatically identify risk and control owners. Click on New: Put filter conditions here After that click on Assignments and give fill all Mandatory Information: Assignments:  This refers to the process of associating entities with their respective entity types and entity classes, often facilitated by entity filters and rules. This assignment ensures that entities are correctly categorized and linked to relevant GRC policies, controls, and risk assessments. Step 4: Assign Entity Class- Entity Class:  Similar to an entity type, an entity class represents a collection of entities that share the same attributes and confirm to a defined structure. It can also refer to a programming construct (like a class in object-oriented programming) that models the structure and behavior of an entity within a system, often mapping to a database table. Step 5: Fill Mandatory Fields- Mandatory Field Empty Owner: Default Owner: The person or team who automatically owns the record when it is created. Do Not Create: Stops the record from being made if something is missing or not correct. Save. Click on Update Entities from Filters to automatically create entities based on the filter conditions. Step 6: Auto-Create Entities (If Using Filter)- 6.  Conclusion: Auto-creating entities with filter conditions make the process faster and reduces manual work. The filter selects all matching records, and the system creates the entities automatically, ensuring accuracy and consistency. This helps keep your GRC entity structure clean, organized, and up to date.

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

Problem Management 1.1 Problem Multiple users face the same issue, then the problem is created. 1.2 Problem Management Problem Management is an ITSM process focused onidentifying, analysing, and eliminating the root causes behind incidents.Instead of repeatedly fixing surface-level symptoms, it goes deeper tounderstand why an issue occurred in the first place. By performing detailedinvestigations and root cause analysis, Problem Management helps preventincidents from happening again, ensures long-term stability of services, andreduces the number of recurring disruptions. It also supports the business byimproving service quality and helping IT teams work more efficiently. Even when a permanent fix is not immediatelypossible, Problem Management works to reduce the impact of unavoidable problemsby implementing reliable temporary solutions, improving monitoring, andoptimizing processes. In simple terms, Incident Management restores servicequickly by treating the symptoms, while Problem Management ensures thosesymptoms never return by curing the actual disease.   1.3 A Problem can be created in two ways: When several users start reporting the same issue—for example, manyemployees cannot access email or multiple systems are slowing down—thetechnician understands that this is not just a one-time incident but arepeating or widespread problem. Instead of treating each incident separately,the technician can link all similar incidents together in the Incident table.This helps identify a common pattern. From these linked incidents, thetechnician can then create a Problem record, which focuses on investigating theunderlying root cause. By doing this, the team ensures they are not justresolving the symptoms for each user but are working toward finding and fixingthe main reason behind the repeated issue.   How to create Problem using Incident: After Creating Incident right click on upper line and select option ‘Create Problem’ and then it goes to Problem window. Directly from the Problem Table we ca create Problem. A Problem can also be logged manually when a major issue or pattern is identified. 2. Problem Management Workflow Following is the Problem Management Workflow and the Description about all states. 2.1 New: When a Problem is created, it must be assigned to the right person and the right support group so that the investigation can begin. This is done using the Assigned to and Assignment group The Assignment group identifies which team is responsible for analyzing and resolving the Problem—for example, the Network Support team, Database team, or Application team. The Assigned field specifies the individual technician within that group who will work on the Problem. Assigning the Problem correctly ensures that the issue is handled by someone with the proper skills and that there are clear ownership and accountability during the entire investigation and resolution process. After clicking Assess, the Problem moves to the next state. 2.2 Assess: During the assessment stage, the Problem Coordinator reviews the Problem to fully understand its scope, impact, and validity. The coordinator checks whether the issue reported truly qualifies as a Problem or if it was logged by mistake. To do this, they gather any missing details, analyze the information provided, and verify whether similar Problems already exist in the system. If an identical Problem is found, the coordinator should not create another one—instead, they must mark the new entry as Duplicate and clearly write a reason, such as referencing the existing Problem record. This avoids confusion and prevents multiple teams from working on the same issue. However, if the coordinator confirms that the Problem is valid and unique, it moves forward to the Root Cause Analysis (RCA) stage, where the team begins investigating the underlying cause in depth. When the coordinator clicks on confirm, it will go to the next state. 2.3 Root cause analysis: This is the most critical stage. The team investigates deeply to identify: What caused the issue? Why did it occur? How can we prevent it in the future? Mandatory fields: Cause Notes Fix Notes After analysis, the Problem transitions to Fix in Progress. If the coordinator chooses “Risk Accepted,” the Problem directly moves to Closed, and the following become mandatory: Cause Notes Risk Accepted Reason 2.4 Fix in progress: In this stage, the team focuses on applying a permanent fix that will completely remove the root cause identified during the analysis phase.  Their goal is not just to temporarily patch the issue but to implement a long-term solution that ensures the problem does not occur again. Once the fix is ready, ServiceNow provides specific UI Actions to control the workflow. When the technician clicks Resolve, the Problem record moves to the Resolved state, indicating that the permanent solution has been applied and the issue is considered fixed. If, during implementation, the team realizes that the fix is not sufficient or the root cause needs to be re-evaluated, they can click Re-Analyse, which sends the Problem back to the Root Cause Analysis stage. This ensures that only fully verified and effective solutions move forward, maintaining accuracy and quality in the Problem Management process. 2.5 Resolved: After the permanent fix has been successfully applied, the system or service enters a monitoring or observation period. During this time, the support or monitoring team closely watches the affected service to ensure that the issue does not reappear and that the fix is functioning as expected in real conditions. This step is important because some problems may seem resolved immediately but could resurface if the solution is not fully effective. Once the monitoring team confirms that everything is stable and the fix is working smoothly without any recurrence, the technician can click Complete. This action officially moves the Problem into the Closed state, indicating that all work is finished, and the Problem is fully resolved. 2.6 Closed: In the final stage, the Problem has been completely validated, monitored, and confirmed to be resolved. When the Problem record is officially closed, it means the permanent fix has been successful, the service is stable, and no further investigation is required. At this point, the support team may also review all the related incidents that were linked to this Problem to ensure they are properly updated, resolved, and closed. This cross-check helps confirm that users are no

Control and Control Objective 1.Introduction In Governance, Risk, and Compliance (GRC), a control is a specific process, action, or technical measure implemented to reduce risk and ensure compliance with organizational policies and regulatory requirements. Controls provide evidence that business activities are being performed securely and effectively. A control objective, on the other hand, defines the high-level goal or desired outcome that these controls are designed to achieve. It sets the direction for what needs to be accomplished—for example, protecting sensitive data, ensuring accurate financial reporting, or maintaining proper access management. Together, control objectives outline the “what,” while controls define the “how,” enabling organizations to manage risks consistently and maintain strong governance. 2.What is Control objective A control objective is an objective, direction, or standard that acts as guidance for company interactions and operations. Control objectives can be categorized, classified, and related to policies. Control objectives are breakdown of policy A policy holds multiple control objectives, and control objectives hold multiple policies. It’s many to many relationships. From control objectives it will create control 3.What is Control? Control is specific implementation of a control objective Controls are automatically generated when you associate a policy with an entity type, or an entity type with a control objective. A control is created for each entity listed in the entity type for the control objective. Control can also be manually created 4.Role required for control and control objective Compliance User /Compliance analyst(User) Control Owner Compliance Manager(sn_compliance.manager) Attestation Creator(sn_compliance.attestation_creator) Compliance Reader(sn_compliance.reader) 5.Difference between control and control objective  Feature Control Objective Control Definition A high-level, desired outcome or goal that guides compliance efforts. A specific, actionable task or activity performed to meet a control objective. Hierarchy At a higher level; a policy can have multiple control objectives, and a control objective can be implemented across multiple entities. A lower-level, concrete instance of a control objective. Purpose To define what needs to be achieved, often based on a policy or regulation. To perform the actual action to achieve the objective for a specific entity. Example “Ensure all remote employees have the necessary equipment.” A specific control created for each remote employee, detailing what equipment they need. 6.Fields of Control Objective Field Name Type Explanation objective_id String Unique identifier for the control objective objective_name String Name of the control objective objective_description Text Detailed purpose and scope of the control objective related_entity Reference/ String Entity or business unit linked to this objective risk_statement Text Risk that this objective mitigates classification_score Number Score representing risk classification residual_risk Choice Remaining risk after control implementation (Low, Medium, High, Critical) regulatory_mapping Text Link to regulations, standards, or frameworks this objective supports control_dependency Text Other objectives or controls that depend on this objective owner Reference/ String Person responsible for the objective start_date Date Effective start date of the objective end_date Date End or retirement date of the objective attestation_required Boolean Indicates if periodic attestation is required attestation_frequency Choice Frequency of attestation (Quarterly, Annually, etc.) last_attestation_date Date Date of the most recent attestation 7.Fields of Control Field Name Type Explanation control_id String Unique identifier for the control control_name String Name of the control control_description Text Purpose and details of the control control_type Choice Preventive, Detective, Directive, Automated, Manual control_owner Reference/String Responsible person for execution and monitoring related_objective Reference/String Linked control objective(s) control_frequency Choice Execution frequency of control (Daily, Weekly, Monthly, Quarterly, Annual) section Choice Business area (IT, Finance, Legal, Operational) assessment_method Choice Self-assessment, Audit, Automated assessment_date Date Date control was assessed assessment_result Choice Effective, Needs Improvement, Ineffective remediation_plan Text Plan to address gaps remediation_due_date Date Due date for remediation activities remediation_status Choice Not Started, In Progress, Completed closure_date Date Date control issue is resolved closure_comments Text Notes at closure risk_rating Choice Risk level associated with control (Low, Medium, High, Critical) last_audit_date Date Last date the control was audited attestation_required Boolean Indicates if control attestation is required attestation_status Choice Not Started, In Progress, Completed 8.How controls created When policy and Entity are connected it automatically generates control, if “Create controls automatically ” checkbox is checked in control objective. The count of Controls are dependent on the count of Entities. Control owning group  Owner will same as entity. 9.Process to create Control Objective from policy  Here under policy, we can create control objective, In review state In the related list of Policy, we can add control objectives by clicking on new or Edit UI action Create control objective In control objective Attestation, Entity Types should be added After creating entity types 7 controls will be created. Control count will be depending on the entities. 10.States of control  Draft: In this state, all compliance users can modify the control. Only available when creating a one-off control. One off control is possible but not recommended. Attest: When the control is created from a control, objective controls are in this state. Note: When a control is set back to draft, the attestation is canceled. Review: Controls are automatically moved to review from the attestation phase. Monitor: In this state, all compliance managers can move the control from review to monitor. Retired: Compliance managers or administrators can move control from Monitor to Retired.  11.Process flow of control 11.1 Draft state When a control is first created, it starts in the Draft stage. In this stage, the control can be edited as many times as needed until all details are properly defined and documented. Control in Draft is only considered “identified” and is not yet implemented or active. Usually, the Control Owner (the person responsible for the control) adds the required information. If they do not have all the details, the control can be reassigned to someone else who can complete it. Once all information is filled in, the control becomes ready to move to the next stage. The required fields at this stage are: Name Entity Attestation Respondents(not needed to create the control initially, but required before moving to the next stage) 11.2 Attest state After clicking attest UI action move to attest state Once the control is fully defined, the first attestation (also called a

Incident Management Incident ManagementAny interruption in service is raised as an IncidentPurpose is to restore normal service operationsPurpose is to minimise the effect by workaround if restore is not possibleImpact and Urgency are defining the PriorityChallengesDetect an incident as soon as possibleIncident workaround or resolution should get documentedIncident assignment for L1, L2 and L3 supportCorrect assignment of priority in automated generated incidents Examples Not able to login in systemNot able to swipe the swipe cardNot able to send an emails  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 appIntegration (API)Auto-created via Monitoring/Event ManagementManually by agents in ServiceNow  5. Fields in the incident management   5.1 Caller  Caller field identifies the person who is reporting the issue.  Incident is in “In Progress” state This incident is already being worked on, so the State is In Progress.The Channel field shows Email, meaning the incident was logged via email.Other fields like assignment group and priority indicate who is handling it. 5.2 Impact & Urgency  Three levels of impact and urgency are given in the list box: High, Medium, and Low, based on the incident priority. New record of incident This shows a newly created incident.The State is New, meaning no one has started working on it yet. 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  Incident moved to “In Progress” Here, the same incident is now saved and assigned.The State changes from New to In Progress once work begins.This indicates the support team has started investigating the issue. 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  When a user reports an issue, a new Incident is created in the system. In Progress  This confirms that the support team has started working on the issue and the Incident state changes from New to In Progress. On Hold  If additional information is required from the user (caller), the Fulfiller changes the Incident state to On Hold Resolved  Once the issue is fixed and the service is restored, the Fulfiller updates the Incident state to Resolved. Closed  In this process, the Fulfiller does not manually close the Incident.Instead, Incident closure is handled automatically using a scheduled job to maintain consistency and standardization. Canceled  when an Incident is no longer valid and does not require any further action or resolution.  New: When incident is new and still not Assigned.  New Incident Record This shows a newly created incident.The State is New, meaning no one has started working on it yet until the incident is assigned to “Assigned to Person”.   In Progress: When the incident is assigned to someone who can solve the incident.  Incident Lifecycle Flow This flow shows the Incident Management lifecycle in ServiceNow.An incident flows from New → In Progress → Resolved → Closed.Optional states like On Hold and Canceled exist based on situations. 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)   Mandatory Caller Field The Caller field is mandatory (marked with an asterisk *).It identifies the user who reported the incident.An incident cannot be saved without selecting a caller. 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.  Impact and Urgency This screenshot highlights the Urgency field.Urgency indicates how quickly the issue needs to be resolved.Along with Impact, it automatically calculates the Priority of the incident. 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

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