ServiceNow JSON Parsing: Processing REST API Responses  Use Case: When an Incident is created in Instance A, the caller information is sent to Instance B. Instance B fetches all incidents related to that caller and sends the incident details back to Instance A. Instance A parses the response and stores the incident data in a custom table.    Step 1: Create REST Message  Create a REST Message named AddCallerDetailsToCustomTable  Purpose: To communicate from Instance A to Instance B  Endpoint is the target ServiceNow instance (Instance B) where the request will be sent  Selected Authentication type: Basic  Chose an existing Basic Auth Profile (dev224187)  This profile contains:  Username  Password  Used to authenticate REST calls to Instance B  Step 2: Create HTTP Method  Selected HTTP Method = POST  Reason: Sending data (caller) to the target instance  Provided the Scripted REST API endpoint of Instance B  This endpoint points to the Scripted REST API created in Instance B  Added required headers to handle JSON data:  Accept: application/json  Content-Type: application/json  Ensures request and response are in JSON format  Step 3: Create Scripted REST Service (Instance B) Created a Scripted REST Service named AddCallerToCustomTable  Purpose: To receive caller-related incident data from another ServiceNow instance  Step 4: Create Scripted REST Resource  Created a Scripted REST Resource under the API AddCallerToCustomTable  Resource name: AddCallerToCustomTable  Selected HTTP Method: POST  This allows the source instance to send POST requests to this endpoint  1. Accept Incoming Request Payload  The resource is designed to accept JSON request body  Request body contains caller information sent from Instance A    (function process( /*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) {      var requestBody = request.body.data;      var user = requestBody.caller;      var incidents = [];    2. Query Incident Table  Initialized a GlideRecord on the incident table  Filtered incidents based on the received caller_id:      var gr = new GlideRecord(‘incident’);      gr.addQuery(‘caller_id’, user);      gr.query();    3. Build Response Payload  Loop through all matching incident records  Collected required incident details:  Incident number  Short description  Stored them in an array:        while (gr.next()) {          incidents.push({              number: gr.getValue(‘number’),              short_description: gr.getValue(‘short_description’)          });      }    4. Send JSON Response  Returned the incident data as a JSON response  This response is sent back to Instance A        response.setBody({‘incidents’:incidents});  })(request, response);  Step 5: Create Business Rule (Instance A)  Navigate to System Definition > Business Rules and click New.  Table: Incident  When: after  Insert: Checked  Get Caller ID  Fetches the caller_id sys_id from the incident  This value is sent to another instance/API  (function executeRule(current, previous /*null when async*/ ) {      var user = current.caller_id.getValue();    Create Payload JSON payload containing the caller  Will be sent in REST request body      var payload = {          caller: user      };    Prepare REST Message Calls a Named REST Message  AddCallerDetailsToCustomTable → REST Message  AddCallerToCustomTable → HTTP Method        var restMessage = new sn_ws.RESTMessageV2(‘AddCallerDetailsToCustomTable’, ‘AddCallerToCustomTable’);      Attach Payload Converts payload to JSON  Sets it as the request body        restMessage.setRequestBody(JSON.stringify(payload));      Execute REST API Call Sends the request to the external/other ServiceNow instance        try {          var response = restMessage.execute();  6.Convert JSON String → JavaScript Object  The REST API response body is always a string  JSON.parse() Converts JSON string into a JavaScript object  Allows field-level access using dot notation           var responseBody = JSON.parse(response.getBody());          gs.log(“API Response: ” + JSON.stringify(responseBody));      Read Incident Data from Response Extracts incident list from API response  responseBody → full parsed object  result → main response wrapper  incidents → array of incident objects  Structure:  responseBody  └── result       └── incidents [ array ]            var incidents= responseBody.result.incidents;              Insert Data into Custom Table Loops through each incident returned          for(var i=0; i<incidents.length;i++){              var gr = new GlideRecord(‘u_add_caller_details’);    Creates new record in custom table              gr.initialize();    Accessing Fields Using Dot Notation incidents[i]. number → Fetches incident number from API response  gr.u_number → Custom table field  incidents[i].short_description → Fetches short description  gr.u_short_description → Custom table field  incidents[i] gives one incident  .number and .short_description fetch values              gr.u_number=incidents[i].number;              gr.u_short_description=incidents[i].short_description;    Inserts record into custom table              gr.insert();            }    Catches REST API errors  Logs error message to system logs        } catch (ex) {          gs.error(“REST API call failed: ” + ex.message);      }    })(current, previous);  Instance A:  This incident creation is the trigger point for:  REST API call  JSON parsing  Custom table insertion  Instance B:   ALL incidents available for the caller “Abel Tuter” in Instance B  These are the incidents that:  The Scripted REST API in Instance B queries  And returns back to Instance A in the API response  Instance A:  REST API Test Result:   REST Message executed successfully  API returned data in JSON format  Response contains:  result object  incidents array  Each incident has:  number  short_description      API Response: {“result”:{“incidents”:[{“number”:”INC0010488″,”short_description”:”0.0″},{“number”:”INC0010560″,”short_description”:”0.0″},{“number”:”INC0010232″,”short_description”:”0.0″},{“number”:”INC0010487″,”short_description”:”0.0″},{“number”:”INC0010233″,”short_description”:”0.0″},{“number”:”INC0010355″,”short_description”:”0.0″},{“number”:”INC0010356″,”short_description”:”0.0″},{“number”:”INC0010204″,”short_description”:”0.0″},{“number”:”INC0010359″,”short_description”:”0.0″},{“number”:”INC0010195″,”short_description”:”0.0″},{“number”:”INC0010292″,”short_description”:”0.0″},{“number”:”INC0010187″,”short_description”:”0.0″},{“number”:”INC0010357″,”short_description”:”0.0″},{“number”:”INC0010180″,”short_description”:”0.0″},{“number”:”INC0010181″,”short_description”:”0.0″},{“number”:”INC0010357″,”short_description”:”0.0″}]}}    Instance A:   Custom Table(u_add_caller_details)  The data shown here is not manually created  It is automatically inserted by the Business Rule in Instance A  End-to-End Flow  Incident created in Instance A  Business Rule runs after insert  Caller ID sent to Instance B via REST API  Scripted REST API in Instance B:  Queries all incidents for Abel Tuter  Instance B returns incident data as JSON  Instance A:  Parses JSON response  Loops through incidents  Each incident is inserted into:        u_add_caller_details 

Incident Synchronization Between ServiceNow Instances Using Flow Designer and Custom action Use Case:  When an incident is created in the source ServiceNow instance, a Flow Designer custom action triggers an outbound REST API call to create the same incident in a target instance. The target instance returns a JSON response, which is parsed and stored back in the source incident for confirmation and traceability.    Step 1: Created a REST Message  Navigated to System Web Services → Outbound → REST Message  Created a REST Message named Sample  Set the target instance URL as the endpoint  Configured Basic Authentication using a REST credential profile  Step 2: Configured HTTP Method  Added an HTTP Method named Test  Selected POST method  Set endpoint to https://myinstance.service-now.com/api/now/table/incident  Added HTTP headers:  Accept: application/json  Content-Type: application/json  Defined JSON request body using variables:  short description  caller  Id           Content:   {      “sys_id”:”${id}”,     “caller_id” : “${cd}”,      “short_description” : “${sd}”  }  Step 3 :Created a Flow  Created a Flow named Create Incident Through Integration  Configured trigger as Incident Created or Updated  Selected Incident table as trigger source  Step 4 : Created a Custom Action  Added a custom Action to the flow  Defined input variables:  sd → Short Description  cd → Caller (Sys ID)  id → Incident ID  Step 5 : Mapped Flow Data to Action Inputs  Mapped Incident Short Description to sd  Mapped Incident Caller to cd  Mapped Incident Sys ID to id  Step 6 : Added Script Step in Custom Action  Used RESTMessageV2 in the script  Called the configured REST Message and HTTP Method  Passed input variables to REST message parameters  Executed the REST call and logged the response  (function execute(inputs, outputs) {    This is a Flow Designer / Action script  inputs → values passed from Flow (incident sys_id, short description, caller)  outputs → values returned back to Flow     try {    Prevents the integration from failing silently  Any runtime error goes to the catch block          var r = new sn_ws.RESTMessageV2(‘Sample’, ‘Test’);    Calls an outbound REST Message  Sample → REST Message record name  Test → HTTP method  This REST Message points to the Target Instance       r.setStringParameterNoEscape(‘id’, inputs.id);   r.setStringParameterNoEscape(‘sd’, inputs.shortDescription);   r.setStringParameterNoEscape(‘cd’, inputs.callerId);      These parameters are sent to the target instance  Used to create the incident there  NoEscape ensures special characters are not altered    var response = r.execute();    Sends the request to the target instance  Waits for the response     var responseBody = response.getBody();   var httpStatus = response.getStatusCode();  responseBody → JSON returned by target instance  httpStatus → HTTP code (200, 201 = success)       gs.info(‘Response Body: ‘ + responseBody);   gs.info(‘HTTP Status: ‘ + httpStatus);    Logs response for debugging               var parsedResponse = JSON.parse(responseBody);   var result = parsedResponse.result;    Converts JSON string → JavaScript object  All incident details are inside result             var targetIncidentNumber = result.number;    var shortDescription     = result.short_description;    var priority             = result.priority;    var category             = result.category;    var subcategory           = result.subcategory;    var state                = result.state;    var callerSysId           = result.caller_id.value;  Reads individual values from target instance  These fields confirm incident creation success                 var grIncident = new GlideRecord(‘incident’);    if (grIncident.get(inputs.id)) {    Opens the Source Instance Incident  Uses inputs.id (source incident sys_id)         grIncident.description =             “Incident successfully created in Target Instancenn” +             “Target Incident Number: ” + targetIncidentNumber + “n” +             “Caller Sys ID: ” + callerSysId + “n” +             “Short Description: ” + shortDescription + “n” +             “Priority: ” + priority + “n” +             “Category: ” + category + “n” +             “Subcategory: ” + subcategory + “n” +             “State: ” + state;                grIncident.update();          }       Stores target incident details  Helps with traceability and auditing          } catch (ex) {          gs.error(‘Integration Error: ‘ + ex.message);      }    })(inputs, outputs);     Logs errors if REST call or parsing fails  Step 7: Executed Integration via Flow  When an Incident is created in the source instance  Flow triggers automatically  Custom action runs and sends data to target instance  REST API creates a new Incident in the target instance      Source Instance:  Before Integration Trigger:  This is the source instance incident  At this point:  Incident exists only in source  REST integration has not yet written back any data  This incident is the trigger for your Flow Designer + Custom Action  Target Instance:  This incident was not manually created  It was created by:  Inbound REST API on target instance  Triggered from source instance  Field values match what was sent in REST request  Source Instance:  After Integration Execution  The Description field is now populated automatically  REST call executed successfully  Target incident was created  JSON response was parsed correctly  Source incident was updated programmatically

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.

Import data from MySQL into Service-now Mid Server To import data from My SQL server into service now we can use MID Server and Data source. MID Server is required when we need to access on premises data(i.e when machine/any server is in Virtual Private Network) Mid Server is a Java application, through which Service-now can communicate with external applications which are running in Clients VPN i.e. Virtual Private Network. Mid Server need to install in Clients Network to get or send data to Clients tool which are in their VPN. We used MID server here because client MySQL server is in VPN, so installed the mid server in client VPN and same mid server we are using in data source. ECC Queue – Mid Server talks with service now using ECC (External Communication Channel). Mid Server Script Include: Mid Server Script Include, are the script, which we will execute on Mid Server For example 1. If we need to connect with jira tool which is in VPN to create a ticket in JIRA and update the response which we are getting from jira into service-now ticket. 2. We need to create a Mid Server script include(Java code) , which will run on the Mid server, which will call the jira web service to create a ticket and take the response and the same response will send to service now table as an update by calling service now web service. 3. After creating mid server script include, we need to create a record into ecc queue against the specific mid server so that script will execute on that specific mid server. Mid Server Installation Steps – Download mid server from service now instance from left navigation menu. Create one folder(“MeghanaMidServer “) in C drive and extract the downloaded ZIP (MID Server setup) in this folder. Open “config.xml” file and configure ServiceNow instance details along with newly created user with “mid_server” role and mentioned MID server name as “MeghanaMidServer”(This name will appear in ServiceNow once we done with setting and mid server started). Once done with all configurations start midserver by running start.bat file Once the above configurations and observations are fine, and then check in whether our mid server is appearing and with status “UP” or not. Go to service now instance->MID Server->Server = MeghanaMidServer check its status and validate it(Validation means service now instance version and mid server instance is same).   Datasource Create New Data Source:     Name – Name of data source Import set table label – Provide any label for import set Import set table name – New import set will be created with this name   Type – Select type of data source (JDBC,FILE,LDAP etc) File JDBC LDAP OIDC Use MID Server  – Specify name of the mid server to which we need to connect from service-now MeghanaMidServer     Install XAMPP server on your machine. Start MySQL server – it will list port number.   Format – Specify data source format(MySQL,Oracle, SQL Server) — None — MySQL Oracle SQLServer Database name – Create database in any db server(Created in MySQL server) and specify that db name here Database port – Use db port number shown on XAMPP control panel against MySQL Discover moreSQL servermy sqlComputerClientSQLServerclientMicrosoft SQL ServerapplicationMySQLdatabase   Username  – Specify MySQL server user name and password Password   Open link –  http://localhost/phpmyadmin/ It will show you local host server address, use that address here.   Server   Query – It will query on table in such a way that it will return all rows from table, or we can write specific SQL (Select required fields or add filter conditions) All Rows from Table Specific SQL Table name – This table should be present in database. Import Set Click on Load All Records – It will load all the records from specified table(book) into import set(u_myimportset).   Verify data in import set from left navigation. Transform Map – To dump/ transform import set data into table, we need to create target table first. Create new table(book) from left navigation. add required fields (id,title,author) those are in MySQL db table. From left navigation go to transform map Name – Specify name for new transform map Source table – Select import set — None — Computer [imp_computer] Import Incident [u_import_incident] Location [imp_location] MyDataSource [u_myimportset] Notification [imp_notification] User [imp_user] Target table – Select table book in which we need to insert data Discover moredatabaseApplication softwarecomputerDatabaseSQLServerclientdbSQLmy sqlComputer Filed Mapping – Perform mapping of import set filed with actual table Click on transform – check the data is loaded in book table. here we are manually transforming import set data into table. but to automate this task we can use schedule job. Schedule Job : Go to your data source from left navigation -> configure-> Related list-> add  Scheduled Data imports   By selecting Run = Daily, This will transform data daily from data source into import set table.   Source Script – Open filed map – > select any filed Click on Use source script checkbox -> it will allow you to run any script on this filed, before inserting data into target table. In following example script, we are adding PR as prefix  to the title. Execute schedule job to load newly added data from my sql table to target table Check Prefix PR is added in title  

Service Level Aggrement (SLA) SLA Priority Increase and Decrease Service Level Agreement (SLA): Service Level Management (SLM) enables you to monitor and manage the services offered by your organization. It is a contract between the service provider and the customer that ensures response and resolution of tasks within a specified timeframe.  It will include details about resolution time, breach levels and their corresponding penalties. If the organization not able to fulfil the goal of the services in the time specified in the agreement. Then, it is considered as a breach of the Agreement. The breach can cost the penalty or impact the image of the organization. Thus, SLA helps organization to measure the quality and efficiency of the task assigned to the employees by determining the progress of the task. Response –  It is the time taken to acknowledge the ticket.  Eg – Time required to give response for an incident such as assignment of incident to the user.   Resolution –  Actual time taken to resolve a ticket.  Eg- Time required for resolve the incident.               1.Retroactive start: It starts the SLA from the time start time of the previous SLA.              2.Retroactive pause: This would consider the pause time of previous SLA. Requirement: Create an SLA’s for priorities P1, P2, P3, P4 such that when you increase the priority the retroactive start should be on updated field and when you decrease the priority the retroactive start should be created field.  Solution: Let’s create a temp field of type date/time for incident form layout. This temp field will store the created or updated date/time based on the requirement of increase and decrease of priority. Let’s create SLA definition for the priorities 1-4 of the incident table i.e. P1, P2, P3, P4 of duration 3 min, Keep Schedule as No schedule for all SLA’s for now. And other fields as default. Here start condition should be based on priority. And cancel condition should be when start condition not met. Retroactive start and Retroactive pause should be true for all. And select your ‘temp’ field for ‘set start to’ field. Pause condition should be when state is put on hold. At the end, stop condition should be when State is resolved. Similarly create other SLA’s for other priorities P2,P3,P4. Now it’s time to write the Business rule which would set the temp field according to the priority change.

Email Notification in Service-now Email Notification : Email notifications are a type of triggered email—email that’s sent in response to specific user action or an event. Creating an email notification involves specifying when to send it, who receives it, whatit contains, and if it can be delivered in an email digest. Types of Email Notifications: Outbound Email Notifications: Sending mail to users from ServiceNow instance. ServiceNow used SMTP to send the mail from the server. Inbound Email Notifications: Receiving mails from user in ServiceNow instance POP is used. For email notifications, we have to set some settings. Navigate to System Properties => Email Properties, the following list of properties will be displayed, In Outbound Email Configuration, Select Email sending enabled and enter any random email address as shown in above snapshot. In Inbound Email Configuration, Select Email receiving enabled and at the bottom write the trusted domain from which ServiceNow should receive mails. If we enter star (*) then from all domains the email will be received. Check “Automatically create users……..”  to create users automatically when any email is received from the user. See below snapshot. Outbound Notifications : Create Outbound notifications for the incident table when the record is inserted.. Navigate to Configure => All => Notifications and click on New button as below, The following form will be displayed. Enter condition in “When to send” section, 1.Send when : Record inserted or updated Now select the user or group to whom the email to be sent as follows, User/Groups in field is form selected table.  Configure the email as follows,  Save the above form. Now, Create a new record in incident table Save the above record. Since, short description contains “ashwini”, so as per the outbound notification we set, the email will be automatically sent to the mentioned user. The email engine process this mail. First, this email will go in “Outbox” under System Mailboxes. In Outbox the mail is in Ready state. Email will be sent to the user, and it will be saved in Sent under System mailbox as follows Since this email details are in Sent mailbox and its state is “Processed” that means the mail has been sent to the user which is mentioned as a recipient while creating Notification. For recipient check notification as follows, The mail will be like below, To check the sender navigate to  Email Properties =>Email Accounts as follows, If the user reply to this mail, it will be displayed in All=>Inbound =>Received To check the received mails, navigate to System Mailboxes =>Inbound =>Received as below,   The email engine of ServiceNow will identify the “Reply” by the Ref no of the email which is send by the ServiceNow to the user as below, 2.Send when: user defined event is fired: For that there should be a user defined event. To create Event, navigate to Event Registry as follows, (Fired by :to trigger this event we should write some code ,we can write it in business rule.write here the name of the business rule Queue : whenever u r triggering any event it shd be the part of the system queue) Click on Submit. To trigger this event we need to write a script.(business rule or script include) So create business rule to run after updating the incident record if short description contains “ashwini” To trigger the event we have eventQueue(). Use the function eventQueue(“Your event name”,”the current object”, “parameter1”, “parameter2”) Refer follow screenshots for business rule , Now change “Send when” option to “Event is fired” and keep all as it is in outbound notification as below, Now update any incident and check the mail ,  Now the mail should be sent to user as below, To send the notification containing param values(passed in business rule while triggering the event) ,access param values in outbound notification as below, Now again update any incident record and check the mail. Mail Script : Email scripts allow for business rule-like scripting within an outbound email message. With mail scripts, you can dynamically change the email output of your system based ondifferent criteria. Mail scripts allow you to perform simple tasks, such as displaying incidentdata, and complex ones, such as making advanced database queries. You can add a ${mail_script:script_name}embedded script tag to the body of the email notificationor template, replacing script name with the name of the script you created. This makes it easyto use the same scripts in multiple email notifications or templates. Now to add email scripts in the body of our mail, first we will have to createmail scripts. To create a mail script open the Notification Email Script module and click on new. We can write our code using template.print(); (Check below code in “message HTML” of Notification ) To see the code for mail script, navigate to System Notification => Notification Email Scripts You will get the list of all mail scripts, search for the required one as below, Now update incident record and check the mail, Inbound Actions: When the system receives the mail, it can be seen in inbox / received mail. Inbound actions in ServiceNow are used to process incoming emails by creating or updating records within the platform. These actions are similar to business rules and use conditions and scripts to take action on a target table. When an email is received, the system checks for a watermark that associates it with a task and other conditions. If the conditions are met, the system takes the inbound email action configured. The system can take two types of actions: Record action, which sets a value for a field in the target table, and Email reply, which sends an email back to the source that triggered the action. Navigate to System Policy => Inbound Actions and click on New button The following form will be displayed. Set the type as “New” and Action type is “Record Action”. Available Types are: New: An email that is not recognized as a reply or forward. Reply: An email with a watermark, with an In-Reply-To email header, or whose

Application Menu and Module in Service-now Tables in ServiceNow, Create Users : sys_user (Table ) Create Roles : sys_user_role (Table ) Assign a role to user : sys_user_has_role (Mapping Table (User – Role) ) Create Group : sys_user_group (Table ) Add user in a Group : sys_user_grmember ( Mapping Table) Assign a Role to Group : sys_group_has_role (Mapping Table) Add one Role into another Role : sys_user_role_contains (Mapping Table) In ServiceNow, Survey – User Groups User Administration – User Roles Table having mapping of user and role You can find Group Role by writing Group Role in Navigation Panel as below, Get a list of group members by writing sys_user_grmember.list in navigation panel as below, If you write sys_user.list in Navigation filter , and Enter, You will find a list of all users. List Of Users : We can find a table name by 2 ways Configure table 2. Table name can find in URL , What is context menu? Application Menu : To Create Application Menu , Go To Application Menu in Navigation panel as shown in the picture below. To Create new application, Click on New Button ,as shown in below picture      While creating an Application,if Role is not assigned it means everyone can access this application. (Refer above figure) Application can be said as a container of modules. Every application contains Modules. Module : Modules are used to access the functionality of ServiceNow,these functionalities are dependent on tables. To create Modules ,search Module in Navigation Panel. Click on New Button to create new Module, as shown in above picture Write Module Name and Application Name under which we want to add Module, as shown in below picture,. E.g Module Name as Contains Role Module,       Application Name : LTI Training Instead of writing Application Name directly,You can select it from the list by clicking on the search button in Application Menu option. Visibility Tab : Override application menu roles : Allows users to access this module even if they do not have permission to view the containing application menu. Users must still meet the role requirements for this module. Link Type : Link type field specifies what type of link the module opens. We can find a lot of link types,as shown in the picture below. Table : Number of table can be seen under Table, For now, Take table name as sys_user_role_contains  and click on Submit,as shown in the picture below. So now,if you search LTI Training in a navigator filter, you can see it with the module which we have added previously. (See Below Picture ) If you click on that module you will see all the contained role list. We can Edit Application by clicking on Pencil near Application name as shown in below picture. we can find related modules at the bottom of the form. (See the picture below) In above Picture, If you click on New Button near Modules,a new form will be generated for new module and Application Name will be automatically displayed. Write Module Name,Link Type and Table name and Click on Submit button,as shown in above picture. Link Type URL example : See below picture for URL link type example.(_blank is used to open that link in new window) Note : If you assign any role to user then that user need to logout and login again to get that access. You can give an order to a module ,Double click below Order for the required module.( as shown in above picture,) Link Types Explanation : Link type field on the Module form specifies what type of link the module opens. Assessment Links to the assessment-based survey you select in the Assessment reference field. Content Page Displays the content page you select in the Content page reference field. Documentation Link Links to a documentation page and opens in a new tab or window. This link type is used with embedded metadata in documentation topics. To open an internal document from a module, use the URL (from Arguments) module link type. Homepage Displays the homepage you select in the Homepage reference field. HTML (from Arguments) Places HTML in the application navigator. This link type is used for more complicated links, where a flat URL is not customizable enough. Note: The HTML (from Arguments) link type is supported in UI15 and UI11 only. In UI16, use the URL (from Arguments) link type instead. Enter a value for the Arguments field. List Filter Displays an unpopulated list view for the table you select in the Table field. Allows users to specify a filter without loading the list first. Use the Filter field to define the default filter for the list. Use the View name field to specify a  List of Records Displays the list view for the table you select in the Table field. Use the Filter field to define the default filter for the list. Use the View name field to specify a view. Map Page Displays the map page you select in the Map page reference field. New Record Displays a form for creating a record in the table you select in the Table field. Use the View name field to specify a view. Use the Arguments field to apply a template. Run a Report Runs the saved report you select in the Report field. Script (from Arguments) Runs a script, as defined in the Arguments field. Note: Enter a value for the Arguments field. Search Screen Link that displays a blank form for searching records in the table. Use the View name field to specify a view. Note: Use the parameter &sysparm_result_view=view_name to define the view the results are rendered in. Note: All searches use a [starts with] query to search for matching text. Other query types are not supported in search screens. Separator Creates a division between modules. Enter a name in the Title field to add a section name that users can collapse or expand. Single Record Displays a form for a single record on the table. Use the

Concept of Inheritance in Service-now Assignment 1- Concept of Inheritance in tables Parent_table Child_table 1 Child_table 2 While creating Parent_table, check the box : Enable extension under control section in the create table window.              Create fields in Parent_table as: P_first_name P_last_name P_phone_no  Create Child_table 1 by extending Parent_table as shown in the screenshot below.              In Child_table 1, create fields as: C1_first_name C1_last_name C1_phone_no Similarly create table Child_table2 extending Parent_table.  While creating fields in both Child_table 1 and Child_Table 2, it is seen that fields present in Parent_table is present in the 2 child tables. So the fields created in parent table reflects across all it’s child tables.  In Child_table2,create fields as: C2_first_name C2_last_name C2_phone_no Now , the relationship is created in such a way that Parent_table is the parent of both Child_table 1 and Child_table 2. This can be verified by searching for the parent table in the navigation bar Then click on Show Schema Map. The Schema for Parent_table is shown below: Create new records in all 3 tables and observe the records that are reflected between parent/child table.  Step1: In the above2 screenshots, we can see that  records added in Parent table are not seen in the Child_table 1 .The same is true with Child_table 2 also. Step 2:  A new record in Child_table 1 is created in the above screenshot.  When the Parent_table is checked, it is seen that the record created in Child_Table 1 is visible. So the data/ records in child table is reflected in parent table as well.  Step 3:  A new Record is created in Child_table2  It is observed that the new record from Child_table 2 is visible in Parent_table also.   It is finally seen that the fields are reflected from parent to child table, but the data/records are not. Also the data/records created in child table reflect in parent table but not the fields alone In summary, Fields/customization flows downwards and data/records flow upwards in Parent-Child Relationship. Concept of Inheritance in tables  When inheritance is established between two tables, the customization flows from parent table to the child table but the records/data flows from the child table to the parent table. Example: If two tables A and B are created such that B is a child of table A, then the fields created in table A are reflected in table B but records created in table A are not reflected in B.On the other hand, the records created in table B are reflected in it’s parent Table (A) but not the fields. While creating a UI Policy for a particular table, the same UI policy can be applied to it’s child table as well. This can be done by checking the ‘inherit’ checkbox while creating the UI Policy for that table.

Custom Scoped Application Application scoping protects applications by identifying and restricting access to application files and data. Another way click on CREATE NEW TABLE We can create new table which is extended from task If we select from list we can create the table from here Another way click on CREATE NEW TABLE Table Goto scope=list view Goto Data model ⇒ table  Configure related list Since table extended from task so it is always we need to edit in GLOBAL scope Open field  See field  Goto file⇒ create file  See my table and other table  create=from which table you want this form  After create ⇒ see form design We know 2 config a.form design and b.form layout  Do changes Cross check  See form we designed  ********************************************************************************** We can create module Create new See able to create module in global scope able to create module in global scope because of application access =All application scope Now GOTO è module  work_assignment è Configureè Table see Now change to this application scope Changed scope to global Open application Create module See no matches found Create script include in Global application Check in Background script o/p Script include with same scope Check in Background script-same scope o/p Check in global scope o/p Open application See From here we can publish in update set   Scoped application caller tracking and restricted   caller tracking –After calling script then get access, it will track data caller restricted- After calling script then restricted Application -work_assignment ,caller restricted Associable from=all application scope SCRIPT INCLUDE created in work_assignment and now we are write background script on Advanced work_assignment Function is caller restricted o/p To remove restricted access Goto =application  Application administration = true Related sec Now check in advanced work_assignment scope o/p 2nd script include Application -work_assignment ,caller tracking   Associable from=all application scope Scope is advanced work_assignment in background script o/p See the sys_scope_privilege.LIST Custom Application Form fields Custom Application Form fields Field name Type Description Name String The display field for the package Version String Identifies the latest version of the package in dot decimal notation Scope String Read only Identifies unique application scope [x_companyCode_shortAppID] See properties Glide.appcreator.company.code Application administration Boolean When checked system administration will be preventing from accessing the application Can Edit Application in Studio Boolean Allow user to edit application file in studio Run time access tracking Choice a. Tracking log-access the system and allows script to execute b.Enforcing log – access the request but required administration authorization before script executation proceed Script interaction with other application is controlled by the system runtime access system Use Runtime Access Tracking to manage script access to resources from other applications Restrict Table Choices Boolean Restrict design time access to table outside application scope Licensable Boolean Licensable or not Subscription requirement Choice a.Monitor b.Required Subscription requirement for usage of this package Subscription model Choices a.NA b.fulfiller /requestor c.procedure d.capacity e.mixed f.Application in use  Subscription model is defined here Subscription Reference Refer to license_details Menu Reference Refer to sys_app_application This application primary menu where default table module will reside User role Reference Refer to  sys_user_role Role required for end user to access this application and its table Short description string Short description for application logo User_image Logo for application Guided Setup Reference Refer to   gsw_content Guided Setup to start when to application is installed/upgraded                                                                                             Related links Manage Collaborators Collaboration descriptors let you assign, manage, and monitor permissions for each application or across multiple applications consistently Collaborators -a person who works together with others for a special purpose O/P Related link -click on manage collaborator See See user can do following thing Move restricted to tracking It will simply just move Whatever configuration we have done on custom scoped application restricted to tracking  Move tracking to restricted It will simply just move Whatever configuration we have done on custom scoped application tracking to restricted View License Definitions It will redirect to sys_app_license_defn_list Publish to Update Set Publishes all the code from an app to a newly created updated set that can be used to transfer the  app between instance Grant app administration to all admins Grand a role that are required for the admins to be able to grand any of the applications role Enable Session Debug 8.Scan Application 9.Convert to Application Repository Mode   When your applications are placed in the Custom Applications table [sys_app], you can’t upgrade them directly through the Application Repository. This procedure helps you do a one-time conversion when you want to migrate deploying your applications using the Application Repository. After you convert the application, it is no longer enabled for development on the instance where the conversion is performed. For a scoped custom application, all associated records in the Customer Updates table are deleted for this application. After this see application Resync Collaboration Permissions Refresh delegated development permission for collaborators

How to remove the comment or work note from activity in Servicenow How to remove the comment or work notes from activity in Servicenow. Lets go from basic i.e. comment and work notes are Journal Input type of field in servicenow. Journal field type in Service-now 1.journal         – Stored the data and can show all the data at once in form and list view. 2.journal_input   – Stored the data and can not show all the data at once in form and list view. 3.journal_list    – Used to display the data Delimiter in Journal entires  “nn” Properties regarding Journal Entries 1.glide.history.max_entries  –  Max number of journal entries included in activity. 2.glide.email.journal.lines  – Max number of journal entries included in email notification.  Important tables regarding Journal Fields: 1.sys_journal_field – stored all the journal field type field values 2.sys_history_line –  Stores the all audited field changes How to remove the comment or work notes from activity. 1. For example we need to remove the below hightligheted additional comment from incident. 2. So this entry was stored in 2 tables.     2.1 sys_journal_field – stored all the journal field type field values     2.2 sys_history_line –  Stores the all audited field changes 3. First one is sys_journal_field – where all the jeneral fields value get stored  and we need to find the record with filter condition like      3.1 value contains the value in additional comment     3.2 Element id will be a sys_id or record     3.3 table will be a table name Please refer the below screen shot for reference.     Delete the selected record from sys_journal_field. 4. but still you can see the additional comment on the incident form because we still need to remove the comment entry from table “sys_history_line” 5.”sys_history_line” table stored the history of audited fields.    5.1 set = “sys_id of incident record” –     5.2 field contains “comments”    5.3 Here you can search using Username column name as well. Please refer the below screen shot for reference.    Delete the selected record from sys_history_line.   6.After deleting the above two entries,the additional comment will get removed from the system or activity.