Search Sources in Service Portal Search Sources (Service Portal): Search Sources define where the Service Portal looks for data during a search. They help fetch relevant records, knowledge articles, and catalog items. By configuring search sources, users get faster and more accurate search results. From an end-user perspective, whenever someone needs information, the first instinct is to use the search box and type a keyword, expecting accurate and matching results. The Service Portal Search Sources provide this exact functionality. They allow us to define where the data should come from (tables), apply conditions if needed, and control which fields are displayed in the search results, ensuring a smooth and relevant search experience. Create a new Service Portal Search Source, provide the required details, and save the record. After saving, the Source section will appear below the form, where you can configure tables, conditions, and fields for search results. Click New and add the required configuration such as Name, ID, and other necessary details, then save the record. Scroll down to the Data Source section and add the table Incident, then configure Short Description as shown in the snapshot below. To check the result, create a new page with one container and add an Instance of type Homepage Search. The results will appear as shown below.

Assignment Rule An Assignment Rule is a server-side rule that automatically assigns a task to the most appropriate user or user group based on predefined conditions. It runs after a record is inserted or updated, evaluates field values, and intelligently determines who should handle the task. Steps to Create an Assignment Rule To create an Assignment Rule, follow the steps below: Open the Navigation Panel in ServiceNow. Navigate to System Policy → Assignment. Click on Assignment to proceed. Once selected, the Assignment Rule form will be displayed, where you can define conditions and configure how tasks are automatically assigned to the appropriate user or user group. This structured approach helps streamline task distribution and ensures efficient workload management. Enter the Assignment Rule Name and specify the conditions that determine which user or user group for the task should be assigned to. Navigate to the Assign To tab and choose the appropriate User or User Group responsible for handling the task. Alternatively, you can define the assignment conditions in the Script tab instead of the Assign To tab, allowing for more flexible and advanced logic. Once the configuration is complete, click Submit to save the Assignment Rule. Create an Incident record and set the Short Description field to include the word “Demo” to trigger the Assignment Rule. Click Save, and once the record is created, open the newly saved record.   The incident is automatically assigned to Abrahim Lincon, confirming that the Assignment Rule is working correctly. Refer to the snapshot below. Difference between Data Lookup Rule and Assignment Rule: ·       Data Lookup Rule: ·       Assignment Rule: ·       Works on the client side ·       Works on the server side ·       Executes before insert/update ·       Executes after insert/update ·       Used to populate multiple fields based on a combination of field values ·       Used to assign a task to a User or User Group ·       Values are fetched from a separate lookup table ·       No separate table is required ·       Mainly used for auto-filling data (like category, priority, SLA, etc.) ·       Mainly used for auto assignment of records ·       Improves data consistency and accuracy ·       Improves workload distribution and efficiency ·       Cannot assign users/groups ·       Specifically designed for user/group assignment Problem Statement Scenario: Incident Assignment Based on Short DescriptionStep 1: Create Groups and Assign Roles• Create a group named LTI Group and assign the ITIL role.• Create another group named L&T Group and assign the ITIL role.Step 2: Create Users and Add Them to LTI GroupCreate the following users and add all of them to the LTI Group:• LTI1• LTI2• LTI3• LTI4 Step 3: Configure Incident Assignment LogicIncidents should be assigned based on the value entered in the Short Description field, as shown below:Short Description Assigned To (User)Finance LTI4Leave LTI3Training LTI1Training and ServiceNow LTI2 Default Assignment Condition• If the Short Description does not match any of the above values:o The incident should be assigned to the L&T Groupo The Assigned To field should remain blank Solution Create the LTI Group and assign it the ITIL role to enable incident management access. After creating the group, add existing users or create new users and associate them with the group. Similarly, create the L&T Group and assign it to the ITIL role for incident handling. Create an Assignment Rule with the following configuration: Condition: Short Description contains “Finance” Assignment: Automatically route the task to the LTI Group and LTI 4 user This ensures seamless task allocation and efficient handling of finance-related requests. Create an Assignment Rule with the following setup: Condition: Short Description contains “Leave” Assignment: Automatically assign the task to the LTI Group and LTI 3 user For a concise, professional one-liner: Assignment Rule: If Short Description contains “Leave,” assign to LTI Group and LTI 3 users. Create an Assignment Rule with the following setup: Condition: Short Description contains “Training” Assignment: Automatically assign the task to the LTI Group and LTI 1 user Concise one-liner version: Assignment Rule: If Short Description contains “Training,” assigns to LTI Group and LTI 1 user. Create an Assignment Rule with the following setup: Condition: Short Description contains both “Training” and “ServiceNow” Assignment: Automatically assign the task to the LTI Group and LTI 2 user Assignment Rule: If Short Description contains “Training” and “ServiceNow,” assigns to LTI Group and LTI 2 user. Create an Assignment Rule with the following setup: Condition: Short Description does not contain “Training,” “ServiceNow,” “Finance,” or “Leave” Assignment: Automatically assign the task to the L&T Group Concise one-liner version: Assignment Rule: If Short Description does not contain Training, ServiceNow, Finance, or Leave, assign to L&T Group. Create an incident with a Short Description containing “Finance”; it will automatically be assigned to the LTI Group and LTI 4 user. Once the incident is saved, it’s successfully logged and ready for action. Create an incident with a Short Description containing ‘Leave’. It will automatically be assigned to the LTI Group and LTI 3 user. Once the incident is saved, it’s officially recorded and queued for action by the assigned group and users. Once an incident with ‘Training’ in the Short Description is created, it’s automatically routed to the LTI Group and LTI 1 user for action After saving the incident, you get a confirmation that it has been successfully created and assigned Once an incident with ‘Training’ and ‘ServiceNow’ in the Short Description is created, it’s automatically routed to the LTI Group and LTI 2 user for action If an incident’s Short Description does not contain Finance, Leave, Training, or ServiceNow, it’s automatically routed to the L&T Group, and the ‘Assigned To’ field remains blank for manual assignment. For incidents whose Short Description does not contain Finance, Leave, Training, or ServiceNow, only the Assignment Group (L&T Group) will be populated, while the ‘Assigned To’ field will remain empty due to the assignment rule.

View Rule This rule determines how a record is presented to the user by dynamically selecting the appropriate view based on defined conditions. Instead of showing the same layout to everyone, it intelligently adapts the form view according to factors such as user role, record state, or field values.  By doing so, it ensures that:  Users see only the most relevant fields  The interface remains clean, focused, and role-specific  Data entry becomes faster and less error-prone  Overall user experience is more intuitive and efficient  In short, this rule acts as a smart filter for the UI, displaying the right view at the right time to the right user—enhancing clarity, productivity, and usability.  To create a view, go to Configure → All → View Rules and click New.  A form will open where you define conditions to control which view is shown. Based on these conditions, the system automatically displays the most relevant view, ensuring a clean and user-friendly interface.  Save the form to apply the configuration.  Once saved, the View Rule is created and stored as shown below, ready to dynamically control which view is displayed based on the defined conditions.  Now, based on the conditions defined in the View Rule, open any Incident record where the Caller is Mac Marksberry.  When you open this record, the system will automatically apply the rule and display the configured view for that condition.  As per the configured View Rule, the record will now be displayed in the ESS (Self-Service) View.  This means the Incident opens in the Self-Service View, showing only the relevant fields intended for end users, as illustrated below.  We can also create a View Rule using a script by enabling the Advanced checkbox.  This allows you to apply custom scripted logic to determine the view dynamically, offering greater flexibility for complex conditions beyond the standard configuration. 

Data Policy Definition: A Data Policy is a server-side rule that enforces data consistency and integrity by setting fields to mandatory or read-only based on specified conditions. It applies to all data entry methods, ensuring rules are followed regardless of how records are created or updated. Web services/APIs Import sets Email integrations Mobile UI Scripted updates Steps to create Data Policy: Navigate to the Application Menu, search for Data Policies, and select Data Policies under the System Policy After clicking this, we are redirected to the form shown below, where the next set of configurations can be performed. Here is short description about checkboxes that are present on the Data Policy form: Use as UI Policy on client – Applies the Data Policy on the client side like a UI Policy, without writing scripts. InheritWhen enabled, this UI Policy is inherited by child tables of the current table. If unchecked, the policy applies only to the current table. Reverse if falseAutomatically reverses the UI Policy actions when the condition becomes false. This ensures fields return to their original state without needing extra logic. Apply to import setsApplies the UI Policy during data imports via Import Sets. Useful when you want the same rules enforced on imported records. Apply to SOAPEnsures the UI Policy is applied when records are created or updated through SOAP web services. Example: When Data Policy is applied to a field, it is enforced even during data imports from external sources. While importing data, the system checks whether a Data Policy exists on the target table and field. If the imported value violates the policy (for example, a mandatory field is left empty), the record will not be inserted or updated.This ensures data consistency and validation, regardless of whether the data is entered manually or imported. To implement this requirement, we create a table called User Details. In this example, we apply Data Policy on a field to enforce validation, as shown in the screenshot above. In the next step, we import anonymous data from an external source like Excel to validate the applied Data Policy. Navigate to the Application Menu and search for Load Data to begin the import process. Select the Create Table option, then click Choose File to upload the source file. Once the data file upload is complete, this page appears to continue the import process This means your data has been uploaded and is ready for the next step. We attempted to upload 10 records from the Excel file; however, only 8 records were successfully uploaded due to validation rules. This happens because of the applied Data Policy. The Data Policy is enforced on the Mother Name field, and in the imported data, the last two rows don’t have values for this field. As a result, those records fail to the Data Policy validation and are not imported, while the remaining records are successfully accepted.

JavaScript Overview JavaScript Output: We have the following ways to display output in JavaScript: innerHTML – displays data inside an HTML element <p id=”demo”></p> <script> document.getElementById(“demo”).innerHTML = 1 + 0; </script>   document.write() – mostly used for testing document.write(“Pavan”);   Button with document.write() – removes all HTML and shows only output <button type=”button” onclick=”document.write(‘Pavan’)”>Click</button>   window.alert() – shows data in alert box window.alert(“Pavan”);   console.log() – used for debugging console.log(“Pavan”); Instructions: Programming means giving instructions to the machine. Instructions are written as statements. JavaScript executes statements from top to bottom. Statements may contain values, operators, expressions, comments, and keywords. Semicolon (;) ends a statement. Example var x = 10; var y = 20; var z = x + y; We can break a line after an operator: var total = x + y; Keywords: Some important JavaScript keywords:break, continue, debugger, do…while, for,function, if…else, return, switch, try…catch Syntax: var KeywordThe var keyword tells the browser to create a variable in JavaScript. ValuesThere are two types of values in JavaScript:1. Literals (Fixed Values)These are hardcoded or constant values.10“Pavan”true 2. Variables (Stored Values)These values are stored in variables.var name = “Pavan”; Case Sensitivity:JavaScript is case-sensitive, meaning variable names with different cases are treated as different variables. var lastname = “A”;var Lastname = “B”; // Both are different variables Variable Declarations:You can declare variables in different ways: var y; // Declared but undefinedvar f, g, h; // Multiple variable declaration String Concatenation ExampleUsing the + operator to combine strings:g = “P” + “a”; // Result: “Pa”f = g + “van”; // Result: “Pavan” Variables: Variables store data values. Variable names must be unique. Variables declared without var are global. Variable Rules: Can contain letters, digits, _, $Must start with a letterCase-sensitiveCannot use reserved keywordsvar x; // value is undefined Types of Variables: Types of Variables:1. Local Variable – accessible within a block function test() {var x = 10;} 2. Global Variable – accessible throughout the pagevar y = 20; Operators: = is the assignment operator and == is the equal operator  ++ increment  — decrement  null === undefined // false null == undefined //true  () operator invokes the function  Notes: myFunction; // returns function definitionmyFunction(); // returns function result Data Type: Primitive Data Type (normal data types which are without properties and methods):  String Number Bolean Undefined Null  Non-Primitive Data Types:  Object Array RegExp  typeof undefined // undefined typeof null // object  Function: for reusability of code  We invoke the function on  any event occurs (on click of user)  () from JavaScript code  Automatically (self-invoked)  Events: onChange  onClick  onMouseover  onMouseout  onKeydown  onLoad  Object: var training = {trainername: “Abel”,skill: “ServiceNow”,id: 111,trainerwithskill: function() {return this.trainername + ” ” + this.skill;}}; var t1 = training.trainerwithskill(); // function valuevar t2 = training.trainerwithskill; // function definitionvar t3 = training.skill;var t4 = training[“skill”]; JavaScript Looping examples: If-else:  if (a < 1) { skill = “Java”; } else if (a < 2) { skill = “PHP”; } else { skill = “Servicenow”; }  For loop:  Example 1  for (i = 1; i < 5; i++) { text += “Servicenow chapter ” + i + ” “; }  Example 2 j=1; for (; j < 5; j++) { text += “Servicenow chapter ” + i + ” “; }  Example 3  var trainer = {name:”Pavan”, skill:”Java”, age:28};  var text = “”; var x; for (x in trainer) { text += trainer[x]; }  Example 4 var txt = “”; var trainer = [{name:”Pavan”, skill:”Java”, age:28},{name:”Paavan”, skill:”Java”, age:28}];  var x; for (x in trainer) { txt += trainer[x][“name”]; }  document.getElementById(“demo”).innerHTML = txt;   Switch:  switch (new Date().getDay()) { case 0: day = “Today is Sunday”; break; case 1: day = “Today is Today is Monday”; break; case 2: day = “Today is Tuesday”; break; case 3: day = “Today is Wednesday”; break; case 4: day = “Today is Thursday”; break; case 5: day = “Today is Friday”; break; case 6: day = “Today is Saturday”; break; default: day = “No Default”; }  while loop:  while (i < 10) { text += “The number is ” + i; i++; }  do while loop:  do { text += “The number is ” + i; i++; } while (i < 10);  JavaScript Function: function is an Object in JavaScript  JavaScript function has properties as well as methods.  Normal Functionfunction myFunction(a, b) {return a * b;}var x = myFunction(4, 3); Anonymous Functionvar pp = function() {alert(“Hi this is anonymous function”);}; Constructor Functionfunction Member(a, b) {this.name = a;this.skill = b;}var t = new Member(“Pavan”, “ServiceNow”);var g = new Member(“Pankaj”, “Java”); Arrow Function// ES5var x = function(p, q) {return p * q;};// ES6const x = (p, q) => p * q; Callback FunctionA callback function is a function passed as an argument to another function. function p1(x) {return x;}function p2(b, callback) {callback(b);}p2(2, p1);p2(3, function() {alert(“Hi”);});

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,

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.

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