ACL in Service-now Access Control List (ACL)  What is ACL? ACL is a list which allows the users to have different access like create, write, read, delete and etc to particulartable of the fields of table. Users with specified roles can only access the given operations like create, write, delete, read, execute. Scripts are used on the bases of condition for true and false. Only those users can give access to another users who have security administrator privilege. These are some operations used in ACL Create: – This operation enables user to create a new record in the table. Write:- This operation enables user to edit the existing record in the table Read: – This operation enables user to read the records in the table but not to edit. Delete: -This operation enables user to remove the existing records from the table. Execute:- This operation enables user to run the scripts on record or UI policies.  Types of ACL Record ACL              In Record ACL we need to satisfy the Field ACL and Table ACL. In this if ACL is applied to parent table then the ACL will             be automatically applied on the child table. Field ACL              In Field ACL we apply ACL to particular Fields so that the only those fields will be visible to the user. To make all fields visible             we need to select (*). Table ACL              In Table ACL we apply ACL on table so that the whole table will be visible to the user. Only the table will be visible but not the             records. Records will be visible if field ACL is also applied. To make whole table visible we need to select (*).   How to Create an ACL?  Example : – Create an ACL where following Conditions should meet. If state=In Progress then only ITIL role users can edit the state field. If state=Resolved then only Admin role users can edit the state fields. If state=closed and “current user” and the “User Name” are same then only user can edit the state field. If state=new, anyone can edit the field. If state=closed, all the fields for all the user should see as read-only.  Procedure to create ACL   I have created the table called User ACL now I am going to apply the ACL to this table. The first thing which you need to do is elevate the system_admin role. Then go to Navigation Bar and click ACL and select Access Control Once you reach to the above show page you will find that each table will be having inbuilt ACLs. If you want to makechanges on any particular table you can edit in the existing ACL itself by adding a role and writing the script for thatparticular operation. I have created a new ACL for this condition and written a code also and the condition is if stateis closed then all fields should be read-only to the users. The condition is if state is closed and the current user and username are same then only user can edit. For this conditionI have applied ACL to the state field and written code and in condition field I have given if state is closed so that it willwork when state is in closed. The condition is if the state is new anyone can edit this so I have written a ACL for only state field and given conditionas the state is new. The Condition is if the state is resolved only admin can edit it so I have created an ACL for edit the state field only withthe condition state is resolved. The condition is if the state is in progress then only ITIL user should edit it. So I have created an ACL with edit to thestate field only and given role as ITIL and condition as State is in progress. Created one additional ACL for read and write for the whole table without any user.   Output If state=In Progress then only ITIL role users can edit the state field. If state=Resolved then only Admin role users can edit the state fields. If state=closed and “current user” and the “User Name” are same then only user can edit the state field. If state=new, anyone can edit the field. If state=closed, all the fields for all the user should see as read-only. ACL Assignment Create a Table with one Auto number field.Create 2 sting field i.e. first name and last nameCreate State field with following values      1.New     2.In Progress     3.Resolved     4.Closed Create one reference field if user as User Name Requirements:      1. if state=In Progress then only ITIL role user’s can edit the state field.      2. if state=Resolved then only Admin role user’s can edit the state fields.      3. if state=closed and “current user” and the “User Name” are same then only user can edit the state field.      4. if state=new, any one can edit the field.      5. if state=closed, all the fields for all the user should see as readonly. (except the req 3)

Practice Examples in Service-now Practice Examples from Shala Master Scenario1:-Cancel the incident form submission if user has typed “Credit Card” in short description.(User OnSubmit Client Script) function onSubmit() {    //Type appropriate comment here, and begin script below     var desc = g_form.getValue(‘short_description’).indexOf(“Credit Card”) > -1;     if ((desc == true)) {                         alert(“Please remove the word ‘Credit Card’ from your short description to Submit the form”);                         return false; }      } Scenario2:-User should not insert or update the incident record if user has entered “password” inwork notes or comments. (function executeRule(current, previous /*null when async*/) {             // Add your code here             var worknote = current.work_notes.getJournalEntry(1);     var worknoteContent = worknote.split(“(Work notes)n”);     var lastWorknote = worknoteContent[1];     var comment = current.comments.getJournalEntry(1);     var commentContent = comment.split(“(Additional comments)n”);     var lastComment = commentContent[1];             if(lastWorknote.indexOf(“password”)>-1){                         current.setAbortAction(true);             }             if(lastComment.indexOf(“password”)>-1){                         current.setAbortAction(true);             } })(current, previous); Scenario3:-Show AddINFO message “Caller and Assigned to are same” if caller and assinged tousers are same. (function executeRule(current, previous /*null when async*/ ) {     // Add your code here     if (current.assigned_to.name == current.caller_id.name) {         gs.addInfoMessage(“The caller and assigned to should not be same”);     } })(current, previous); Scenario4:-Show alert “Manager are same for Caller and Assinged to User” if the caller’s managerand assigned to user’s manager are same for incident. function onSubmit() {     //Type appropriate comment here, and begin script below     var cman = g_form.getReference(“caller_id”).manager;     var aman = g_form.getReference(“assigned_to”).manager;     if (cman == aman) {         alert(“Manager are same for caller and assigned to user”);     } } Scenario 5:-User should not select a user for assinged to field for incident record if user does nothave email id. function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     var email = g_form.getReference(“assigned_to”).email;     if (email == “”) {         alert(“You cannot select user that does not have an email id”);                                 g_form.clearValue(“assigned_to”);     }     //Type appropriate comment here, and begin script below } Scenario6:-Make state readonly if loggedin user and caller are same on incident form. function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     var user = g_user.firstName + ” ” + g_user.lastName;     var caller = g_form.getReference(“caller_id”).name;     if (user == caller) {         g_form.setReadOnly(“state”, true);     }     //Type appropriate comment here, and begin script below } Scenario7:-Make state readonly if state=New on incident form. Using UI Policy Scenario8:-Set Assinged to= Pavan if category=Network. function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     if (newValue==”network”) {        g_form.setValue(“assigned_to”,”Pavan”);     }     //Type appropriate comment here, and begin script below } Scenario 9:-Show alert if the state changed from Resolved to In Progress. function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     if (oldValue == 6 && newValue == 2) {         alert(“The state has now changed from Resolved to In Progress.”);     }     //Type appropriate comment here, and begin script below } Scenario10:-Whenever caller changed the comment field for incident set state=In Porogress. function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     var user = (g_user.firstName);     var caller = g_form.getReference(“caller_id”).first_name;     if (user == caller) {         g_form.setValue(“state”,2);     }     //Type appropriate comment here, and begin script below } Scenario 11:User should not change the state from Resolved to In Progress without putting commenton incident form. function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     if (oldValue != 6 ;& newValue != 2)         return;     g_form.setMandatory(‘comments’, true); } Scenario 12:-  Show Comment and worknote value in AddINFO message after insert or update ofincident record. (function executeRule(current, previous /*null when async*/ ) {     // Add your code here     var worknote = current.work_notes.getJournalEntry(1);     var worknoteContent = worknote.split(“(Work notes)n”);     var lastWorknote = worknoteContent[1];     var comment = current.comments.getJournalEntry(1);     var commentContent = comment.split(“(Additional comments)n”);     var lastComment = commentContent[1];     gs.addInfoMessage(“The additional comments are: ” + lastComment + ” <br/><br/>The Work Notes are: ” + lastWorknote); })(current, previous); Scenario13:-Caller user should not have access to Assignment group and Assigned to field onincident form. If user is caller is logged in user he will have assignment group and assigned to as read only function onChange(control, oldValue, newValue, isLoading, isTemplate) {     if (isLoading || newValue === ”) {         return;     }     var user = (g_user.firstName);     var caller = g_form.getReference(“caller_id”).first_name;     if (user == caller) {         g_form.setReadOnly(“assigned_to”, true);         g_form.setReadOnly(“assignment_group”, true);     } } Scenario 14:- User should see “xxx-xxx-xxxx” in short description on form whenever short descriptioncontains mobile number. function onSubmit() {     //Type appropriate comment here, and begin script below     var value = g_form.getValue(“short_description”);     var re = /^[0-9]{10}$/;     if (!re.test(value)) {         g_form.setValue(‘short_description’, ‘ xxx-xxx-xxxx’);         //         var res = value.replace(re, “xxx-xxx-xxxx”);         //         g_form.setValue(“short_description”, res);     } Scenario 15:- User should not submit the incident form without setting short description anddescription field values. Set the short description and description as mandatory fields. Scenario16:-Show alert if current loggedin user is member of particular group (Database). Display Business Rule (function executeRule(current, previous /*null when async*/ ) {     // Add your code here     // var groupID = current.assignment_group;     var groupName = “Database”;     var userID = gs.getUserID();     var gr = new GlideRecord(“sys_user_grmember”);     gr.addQuery(“group.name”, groupName);     gr.addQuery(“user”, userID);     gr.query();     if (gr.next()) {         g_scratchpad.grp = true} })(current, previous); On load Client Script function onLoad() {     //Type appropriate comment here, and begin script below     if (g_scratchpad.grp == true) {         alert(“The user is part of the Database group”);     } else {         alert(“The user is not part of the Database group”);     } } And since the System administrator

Scripted REST API INDEX What is Scripted Rest API?……………………………………………………………… 1 Advantages of Scripted Rest API………………………………………………………. 2 Roles Required……………………………………………………………………………. 2 Fields of Scripted Rest API……………………………………………………………… 3 Difference between Rest API and Scripted Rest API………………………………. 3 Error Codes in Scripted REST API……………………………………………………… 4 Example……………………………………………………………………………………. 4 ​​  1. What is Scripted Rest API? Scripted REST APIs allow developers to create custom web service APIs in ServiceNow. These APIs enable external systems to interact with ServiceNow by defining endpoints, handling requests, and customizing responses beyond standard table APIs. Using Scripted REST APIs, developers can: Define custom endpoints (resources) Configure HTTP methods such as GET, POST, PUT, DELETE Accept and process query parameters, path parameters, headers, and request bodies Write scripts to control request handling, business logic, and response formatting Scripted REST APIs are created and managed using the Scripted REST Service form, available under: Scripted Web Services → Scripted REST APIs This is commonly used for: Integrating ServiceNow with external systems Exposing custom data and business logic Building reusable APIs for scoped applications 2. Advantages of Scripted Rest API It gives full control over how requests and responses work You can add custom business logic using scripts It can work with multiple tables at the same time You can return custom JSON responses It supports secure access using roles and authentication You can handle errors properly with clear messages It supports API versioning for future changes It is best for integrating ServiceNow with external systems 3. Roles Required The role required to create and manage a Scripted REST API in ServiceNow is web_service_admin. 4. Fields of Scripted Rest API Field Name Description Name Friendly name of the Scripted REST API API ID Unique identifier used in the API URI Namespace Application scope where the API is created Active Enables or disables the API Default ACLs Security rules applied to all resources Base Path Base URL path for the API Version API version for managing changes Short Description / Description Explains the purpose of the API Security Configure authentication and access control Content Negotiation Define supported request and response formats (JSON, XML, etc.) Resources Define API endpoints (URI paths) Request Headers Define expected HTTP request headers Query Parameters Define supported query parameters   5. Difference between Rest API and Scripted Rest API REST API Scripted REST API Pre-built APIs provided by ServiceNow Custom APIs created by developers Mainly used for standard CRUD operations Used for custom logic and complex processing Limited customization Fully customizable using server-side scripts Follows strict ServiceNow table structure Can return custom response formats Faster to use for simple integrations Best for complex and non-standard integrations Less control over request/response Full control over headers, parameters, and payload Example: Table API, Attachment API Custom endpoints under Scripted REST APIs No scripting required Requires JavaScript scripting 6. Error Codes in Scripted REST API Error Code Meaning When It Occurs 200 OK Request successful API executed successfully 201 Created Resource created Record created via POST 400 Bad Request Invalid request Missing/invalid parameters or payload 401 Unauthorized Authentication failed Invalid or missing credentials 403 Forbidden Access denied User lacks required role/ACL 404 Not Found Resource not found Invalid endpoint or record 405 Method Not Allowed Invalid HTTP method Method not supported for resource 409 Conflict Duplicate/conflict Record already exists 415 Unsupported Media Type Invalid content type Wrong Content-Type header 500 Internal Server Error Server error Script error or exception 503 Service Unavailable Service down API temporarily unavailable 7. Example A catalog item named User Task Status exists in Instance A, which allows a manager to select a user to view the user’s task details. However, the actual task data (Incidents, Problems, and Change Requests) assigned to the selected user is maintained in Instance B. When the manager selects the User in catalog item in Instance A, the selected user information is sent to Instance B via integration. Instance B processes the request, fetches the count of Incidents, Problems, and Change Requests assigned to the user, and sends the response back to Instance A. The received response is then populated into the User Task Details variable of the catalog item. Steps of Implementation: Step 1: Create a catalog item in instance A 1.1. Create Variables Select User – reference – sys_user User Task Details – Multi Line Text 1.2. Final Catalog Item will Look Like this on Portal Step 2:  Create Scripted REST API in Instance B Create a New Scripted REST API. Navigate to ALL > System Web Services > Scripted REST API’s > New Give a name to new Scripted REST API and fill the mandatory fields as below: 2.1. Create Resource from related list Give name to a New Resource and fill mandatory fields as below: Script – This script retrieves the user from the request body, fetches the assigned user details from the User table, and returns the data in the response body to Instance A. Step 3: Create REST Message in Instance A Navigate to ALL > System Web Services > Outbound > REST Message > New 3.1. Provide Endpoint and Basic authentication details of Instance B. Give name to REST message and Endpoint of instance B 3.2. Basic Authentication Details Fill username and password details of the instance B 3.3. Create HTTP Method from related list Select HTTP method, Endpoint, HTTP Headers and Query Parameters Step 4: Create Script include to call REST Message in instance A Navigate to ALL > System Definition > Script Include > New Give a name to Script Include as below: Script- This script will fetch the user that is selected on the catalog item, calls the REST message we have created in instance A, and whatever response we get from instance B, script will fetch assignment details for the user. Step 5: Create catalog client script for your catalog item which is created in step 1 Fill the required details like Type, Catalog item, Variable Name and UI Type as below: Script – This script will get the value of the user from the

Service-now Integration Guidelines Service-now Webservice By default, in Service-now for every table there will be SOPA WSDL and Rest endpoints for following operations For Soap if your table name is “u_customer_table”, the WSDL will be https://instancename.service-now.com/u_customer_table.do?wsdl For Rest if your table name is “u_customer_table”, the WSDL will be https://instancename.service-now.com/api/now/table/u_customer_table Soap WSDL functions Insert update deleteMultuple getKeys deleteRecords get getRecords Rest Endpoints Methods Post Get Put Delete Soap Web Service Integration with Third Party Tool (Here we are considering as another service instance is a third party tool) Whenever we need to integrate with third party tool, we need to request the SOAP WSDL from them. Once we will get the WSDL from third party tool, we will create SOAP Message in ServiceNow. How to Create Soap Message System Navigator–>Search Soap Message as below Click on “SOAP Message” Module, you will get all the list of Soap Messages. Click on “New” UI Action. Here I am using WSDL of incident table as fallows And Save it. After Save you will get the related link at bottom of the form Click on that After Clicking on the UI Action : Generate Sample SOAP messages, it will create a WSDL xml and functions and will get one add info message at top as fallows. Click on the “insert” function in another tab. Select Authentication type as Basic one and select the same profile from reference field in Basic auth Profile and save the record. Click on the Auto Generated Variables After clicking on that, you will get all the variable in “Variable Substitution” related list Select insert.shortdescription variable and put some test value as fallows After that click on Test from related link After clicking on Test, you will get the request and response xml on the screen. If you get 200, it means, you have created an incident and in response you will get incident number as well as sys_id. Now go back to your insert function again. Click on Preview Script Usages as fallows You will get a code, which you can use in your server-side scripting.   Rest Web Service Integration with Third Party Tool (Here we are considering as another service instance is a third-party tool) Go through Navigation Search and search Rest Click on New Add the authentication type as a Basic And put values for HTPP Request And save it. Now create HTTP Method for this Message as below – to create it click on New which is on “HTTP Method” related list You will get new form, then please fill the values like below Fill the HTTP Request tab Then create HTTP query parameter and content with variable for description ${des} And save it. Then click on “Auto generate Variables” Then it will create a entry in related list of variable substitution. Put some test value for des variable and then click on TEST After clicking on Test, you will get request and response details.   Http Status Codes 2xx – Success: IT represents Request was accept successfully. 200 – Success 201- Success and record created 202 – Accepted 4xx – Error -IT represents the Request was incorrect at client only means requester. 400 – Bad Request 401– Authentication Failed 403 – Forbidden 404 -Not Found 405 -Method not Allowed 5xx -Error -It represents the request was correct but error at Server side. 500 – Internal Server Error 502 – Not Implemented 502 – Bad Gateway 503 – Service Unavailable 504- Gateway timeout

Overview of ATF Automated Test Framework (ATF) in ServiceNow The Automated Test Framework (ATF) is a built-in ServiceNow tool designed to automate testing of your instance configurations, customizations, and applications. It allows you to create and execute automated tests that verify your ServiceNow instance continues to function correctly after changes, such as upgrades, new developments, or update sets. Why Do We Need ATF? In real-world ServiceNow projects, teams often customize core processes, including: Incidents Problems Catalog Items Flows Business Rules After platform upgrades or configuration changes, these customizations can sometimes break unexpectedly. ATF addresses these challenges by: Reducing the need for repetitive manual testing Detecting issues early in the development cycle Saving significant time and resources Ensuring consistent quality and stability, especially during upgrades By automating regression testing, ATF provides confidence that your custom business processes remain intact.   ATF helps to: Reduce manual testing Catch issues early Save time Ensure quality after upgrades What Can ATF Test? ATF is versatile and can validate a wide range of elements, including: Incident creation and lifecycle Service Catalog item submissions UI Policies Client Scripts Business Rules Flow Designer logic Form field behaviors (mandatory, visible, read-only) Approval processes Server-side logic (e.g., Script Includes, SLA calculations) REST APIs and integrations (via inbound/outbound messages or MID Server) ATF supports client-side (UI) tests, server-side tests, and integration tests. Main Components of ATF ATF is built around several key components: Test A complete end-to-end scenario that verifies specific functionality. Example: Create an Incident → Set field values → Submit → Validate outcomes. Test Step Individual actions or assertions within a test. Examples: Open a form; Set field values, Click Submit, Assert field value. A single test consists of multiple ordered test steps. Test Suite A collection of related tests (or even nested suites) for organized execution. Examples: Incident Management Suite, Catalog Suite, SLA Validation Suite. Additional supporting elements include: Test Runner Executes tests and displays real-time results (Passed, Failed, and Skipped), execution time, and error details. Test Results Detailed logs with step-by-step status, runtime screenshots (for UI steps), and error messages for debugging. Scheduled Test Runs Enables automated execution on a recurring basis (daily, weekly) or tied to events like deployments or pre-upgrade validations. Types of ATF Tests ATF supports different testing approaches: UI (Client-Side) Tests Simulate real user interactions on forms, lists, and Service Portal. Example: Opening the Incident form, entering a Caller, and submitting. Server-Side Tests Validate backend logic without involving the UI. Example: Testing Business Rules, Script Includes, or SLA calculations directly. Integration Tests Verify connectivity with external systems. Example: Inbound/outbound REST APIs or MID Server interactions. Scenario Verify that an Incident record is created with specified field values. Steps to Create the Test Navigate to ATF. Go to Automated Test Framework > Tests and click New. Configure the Test Name: Create Incident – Demo Test Table: Incident Step 1: Open New Incident Form for testing (Temporary) Test Step: Open a New Form Table: Incident Purpose:  Opens the incident form Add Test Steps Step 1: Open a New Form Test Step Type: Open a New Form Table: Incident Purpose: This opens the new Incident form, simulating user navigation. Table – (Select) Incident table in the Table field (Mandatory) Submit it. Step 2: Set Field Values Test Step Type: Set Field Values Examples of fields: Short Description: Email issue Category: Software Purpose: Simulates user input on the form. Step 3: Submit the Form Test Step Type: Submit a Form Purpose: Clicks the Submit button to create the record. Click on Submit. You can see three steps on the test page in red rectangle. On the Runner page, we can see the Incident form displayed with the specified field values populated.The Caller field shows the user selected during the test execution, confirming that the correct caller information is captured.The Short Description field is filled with the provided text, validating that the input data has been passed correctly.This view helps confirm that the test is creating or opening the Incident record with the expected field values. On the Test Case record, the Test Result is shown as Success, which indicates that all the configured test steps were executed without any errors.Each step met the expected conditions and produced the correct outcome as defined in the test case.No failures, warnings, or exceptions were encountered during the execution of the test.This confirms that the related functionality is working as expected under the tested scenario. On the Incident list view, we can see that a new Incident record has been successfully created in the system.The record appears as a new row in the list with key details such as Incident Number, Short Description, Priority, State, and Assigned To.This listview allows users to quickly verify that the Incident is logged and track its current status.From here, users can also open the record to view, update, or work on the Incident in detail. The Incident record may temporarily vanish from the listview for a few minutes while the debug process is running.During this time, the system is executing background logic such as flows, business rules, or scripts, which can delay the record’s visibility.Once the debug execution is completed successfully, the Incident record will reappear in the listview.This behavior is temporary and does not indicate that the Incident has been deleted or lost. The Automated Test Framework is a powerful, native tool that streamlines testing in ServiceNow, promotes faster releases, and minimizes risks. By investing in ATF early, teams can achieve higher quality, reduced testing overhead, and greater confidence in their customizations. Start small with critical processes, build reusable steps, and gradually expand your test suites for maximum impact. Parameterized Testing Parameterized testing in ServiceNow Automated Test Framework (ATF) allows you to run the same test multiple times with different sets of input data, without duplicating the entire test. This is particularly useful for data-driven testing scenarios, such as validating a process (e.g., incident creation or user access) across various inputs like roles, values, or records. Why Use Parameterized Testing It reduces

Dictionary Entry in Service-now Dictionary Entry : Types Of Fields : String Reference Choice field (Dependent field)         True/false field List Journal     To find the table name of a field ,Right click on that field,Click on Configure Dictionary as shown in below picture,     Details of that field will be displayed as shown in below picture,     To add new column to a Table ,Right click on the required form, click on Configure -> Dictionary as below,     Click on New to create new field on the following form,   Clicking on New Button ,Following form will be displayed where we can create fields of different types.     e.g  create a State field of Type String as shown in below picture,   The new field can be seen in the table as below,       Choice Type Example : Lets convert the State field to Choice Type. Right click on that field, Click on Configure Dictionary, as below       State field in Dictionary Entry will be displayed. In below Section, Choice List Specification, Select Dropdown with None as a Choice ,as shown below,     Save the changes as below,     To add values in that dropdown , Click on Choices Tab in below Section, Click on New Button, as shown in below picture,     The following form will be displayed after clicking on New Button.   The List can be seen in the Dropdown as below,     Dependent Field : This field is dependent on another field in a table. e.g  City depends on State     In Dictionary Entry for City , assign Dependent field as below,     We need to set Dependent Value also, as shown below,       Now, If we select Maharashtra state, Cities from Maharashtra only displayed in City dropdown., as shown below   Similarly for other state,another cities are displayed.   You can use existing Choice table also to display the List.     Reference Field : Field refers to another field.     The Reference field User will be added to the form as below,     You can select any user from a list of users from sys_user table by clicking on magnifying glass next to User as below,     After selecting a record, Display Value of that table (Reference table) will be displayed as below,         Display Value : This Value is a representation of that record in a reference field that is for whole table.Therefore there will be only one Display Value for a table. If there are more than one display value for a table then the updated value will be set as Display value.       Clicking on Open Record button , the entire record can be seen as below,  

Automated Test Framework (ATF)     With the Automated Test Framework (ATF), we can create and run automated tests on our Service Now instance.              Whenever we upgrade to any instance, we can run these tests to confirm that the instance still works as designed.              To enable test execution –>select Properties of ATF application–>select the yes option to enable test/test suite execution.                createnew test case, search for test module in left navigation -> Click on  New                New form will be open as follows-                To add test step – >Click on Add Test step                Step 1 – Select create a user option                Specify user details like first name, last name, roleetc and impersonate this user, so test case will be run as newly created user.                  Step 2- To check the mandatory fields, need to open an existing record first-                Select table name and record                Step 3 – Select field state validation option                Select table name, Visible, Read only, mandatory etc options-àSave                Now run the test case                Test result-                If every step works as per expectation then you can see following successful test status.                Test case evidence are also collected, we can see them from test result, open latest record                See the attachments; at every step one test evidence is getting captured.

Incident Process in Service-now What is Incident? Incident is an event of interruption or disruption or degradation in service operation. An open incident implies that the customer is impacted. Goal of incident management The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact onbusiness operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’is defined here as service peration within Service Level Agreement (SLA). Different ways to raise Incident: User can open Incident Ticket via User Interface (Self Service) or Email. IT ServiceDesk will open an Incident for all incidents reported via phone, walk-in or Email. Incident Tickets can be opened automatically by monitoring tool. The monitoring team will also create incident for qualified alert. 1.Creating Incident via User Interface (Self Service): In Service Now personal development instance in left navigator search for Incident. Go to Self Service> Incident> New Click New it will open Incident Form here in short description end user should write issue faced and define Urgency and Submit form. 2.Creating Incident via Email: If user don’t have access to the service now or user unable to login to the system in that case incident can be raised by sending mail to ServiceNow,only if the user is specific or having specific mail id. As per the mail, record get inserted in incident table, for this customization is needed that willbe done in Service Now, System Policy> Email> Inbound Actions. 3.Creating Incident using Service Catalog: In ServiceNow personal development instance in left navigation search for catalog Self Service> Service Catalog> Can We Help You?> Create Incident Enter the issue in Please describe your issue and define Urgency. Click on submit and see incident created as below 4.Creating Incident using Service Portal: In Service Portal Home click on Get Help> Create Incident> Submit Fill urgency and issue click Submit Incident created as below All incidents are shown in service portals homepage in My Open Incidents 5.User can create incident by contacting to IT Service Desk via Phone or walk-in and as per information given by user/customer/caller/requesterIT Service Desk will create incident in ServiceNow, Incident> Create New. Once the incident is logged in into the system now IT service desk agent will work on it. For that in left navigation search for incidents go to Incidents>open-unassigned It will check the incidents are not assigned, now open the incident from list as per the short description categorization of incident is takes place thenas per urgency defined by caller incidents priority is set. Then as per the category and priority of incident, incidents are assigned to Assignment groupor to a particular member in that group I.e. Assigned to Now the assignee will work on that incident to fix the issue/interruption. Example: Incident is raised by end user via self- service contact type now see incident life cycle to fix issue as follows Saanvi is end user she faced an issue that she unable to open email so she has created incident via self-service as follows (for this I impersonateuser as Saanvi ) What is impersonation? Administrators can impersonate other authenticated users for testing purposes and view impersonation logs. The impersonation option is not visiblein the mobile view of the platform. When impersonating another user, the administrator has access to exactly what that user can access in the system, including the same menusand modules. The instance records anything the administrator does while impersonating another user as having been done by that user. Procedure to Impersonate user: In the banner frame, click your user name to open the user menu. Select Impersonate User. The Impersonate User dialog box appears. Select a user from the Recent Impersonationslist or enter a different user’s name in the user selection field. To return to your original login, follow these same steps then select End Impersonation. Here I impersonate user as Saanvi Saanvi has created incident via self-service as follows Now I Priyanka system administrator checked un assigned incidents for that go to Incidents> open-unassigned To check the incident raised by Saanvi, I will add filter condition in list view as follows Click on filter icon add condition caller is Saanvi then click Run Or in search field find caller Saanvi Then press Enter it will shows incidents where caller is Saanvi/ incidents raised by Saanvi Open the incident now I will work on that incident to resolve it. As per short description I set category and subcategory of incident. According to urgency and impact incidents Priority is set. In contact type I entered self servicecause incident is raised via Self service. I entered Assignment group and Assigned to values as below. Once incident is assigned State of incident changes to In Progress. Now assignee will work on that incident and if needs more information from caller or any other reason he can keep this On Hold. For this click On Hold now on hold reason is mandatory save the form it shows Resume UI Action, once information is taken from caller assigneewill resume work by clicking on Resume. Click on Resume state of incident changes from On Hold to In Progress Now after solving issue assignee will click on Resolve and state changes to resolved. After this assignee click on Close Incident to close the incident and state changes to closed In this way incident get resolved and then closed. The process flow will be like In this example On Hold, Resume, Resolve and Close Incident UI Actions/buttons are custom UI Actions. UI Actions: Here following are the custom UI Actions that I have created and as per UI Action incident state changes as follows Incident Process in Service-Now We have incident where we have following process. We have following state for incident.1.New2.In Progress3.Pending Customer4.Pending Information5.Customer Update5.Resolved6.Closed Incident Process till Close1.New created incident in New State2.Fulfiller should ACK the ticket by clicking on ACK ui action and incident should go in “In Progress” state.3.Fullfiller can change the state to Pending

Datalookup in Service-now Data LookUp : This is the rule table that defines the rules that automatically set one or more field values when certain conditions are met. (At client side) For example , in the Incident table we can set the value of “Assigned to” field depending on the combination of “Category” and “SubCategory” fields. Say , if “Category” is “Hardware” and “Subcategory” is “Keyboard” then Set “Assigned to” as “John”   Problem Statement : Set the values for Address and User according to Name . Create Data Lookup Table : Create a new table as a data lookup table.   To create data lookup table,it must extend the Data Lookup Matcher Rules [dl_matcher]        table, as shown in below snapshot,  Save the above table. Create the same fields as in the Source table (table for which this data lookup table is created) for which we want to set the rule.  As per the problem statement,  Create fields: Name,Address and User in “Demo Rule Table”.      Save above changes. Now Open the Demo Rule table (Data lookup table) and set the values for the fields as below, Set all the values that we required,(see the list below), Create Data Lookup Rules:   Now map the data lookup table and Source table. For that follow the following steps, Navigate to Data Lookup Definitions and Click on New Button.  Click on Data Lookup Rule. The following form will be displayed, Write Source table On which we want to apply the rule and Matcher Table in which we have created fields on which we have to set the Rule, Check checkboxes, Active : (run on client side) Select this check box to run this data lookup rule. Clear the check box to ignore this data lookup rule.   Run on Form change : (run on client side) Select this check box to automatically look up values whenever a user or onChange client script changes a field value on a source table form.   Run on insert : (run on server side) Select this check box to automatically look up values whenever a user creates a new record.   Run on update : (run on server side) Select this check box to automatically look up values whenever a user saves or updates a record.   Save this Form. Open the saved  Data Lookup Definitions , At the bottom, Click on “Matcher Field Definitions ” tab and Click on New button, following form will be displayed. Map the Source table and Matcher table(Data lookup table) fields as shown in above snapshot, Check the “Exact  lookup match “ checkbox if you want to make it case sensitive. Save the above changes. Now Click on “Setter Field Definitions” and Click on New Button as shown in below snapshot, Map the fields that we want to set the values depending on the Matcher Field Definitions as below, Set all the fields, Now Open the new form for the source table. Type Name as “Ashwini” . The fields “Address” and “User” will be automatically populated as “Pune” and “Ashwini More” respectively. See below snapshot, But if we change Name to another name , Say Sonia the Address and User values does not change. (see below snapshot) Because in Data Lookup Definitions, In Setter field Definitions , we have set the Always Replace value to false. Set the value of “Always Replace“ as “true” for all fields.(See below snapshot) Save above changes and check again in the source table.

Inbound Email Action in Servicenow INBOUND EMAIL ACTION SCRIPTING   Requirement: Creating incidents for every single email attachment through inbound action.    Components Used: Inbound Action on Incident Table ‘sys_email_attachment’ Table ‘sys_attachment’ Table    Script for Inbound Email Action: (function runAction(/*GlideRecord*/ current, /*GlideRecord*/ event, /*EmailWrapper*/ email, /*ScopedEmailLogger*/ logger, /*EmailClassifier*/ classifier) {                 // Implement email action here               var emailSysId = sys_email.getUniqueValue(); // sys_id of email log record var qq=”email=”+emailSysId; //query to fire on sys_email_attachment table       var i=0;   gs.log(“Email sys_id is: ” + emailSysId, “EMAILSCRIPT”);                   var   gr = new GlideRecord(‘sys_email_attachment’);           gr.addEncodedQuery(qq);           gr.orderByDesc(‘sys_created_on’);           gr.query();           while(gr.next()){                                                          var gr1=new GlideRecord(“incident”);                                             gr1.short_description=”Attachment number”+i;  //Hardcoded short description                                             var t=gr1.insert();                                              i++;                                    var attachment = new GlideRecord(‘sys_attachment’);                              attachment.get(gr.attachment);                              attachment.table_name =”incident”;                              attachment.table_sys_id = t;                              attachment.update();          }   })(current, event, email, logger, classifier);