Email Notification using Flow Design Notification: A Notification in ServiceNow is used to automatically send messages (Email, SMS, Push) to users when a specific event or condition occurs.  Create Catalog & In Catalog Create Catalog item, For Requesting anything. Example [Work from Home.]  Add Variables in Catalog Items & Save it.               Employee Name               Address               Manager. This is Where we can Request anything like (Work from Home, etc.)  Creating Flow Design for Requesting Work from Home Application to the Manager & getting Response from Manager.  In Flow create Add actions, Create Emails for Request & Approval  Search Get Catalog variable from Action from Flow design.  In this Send Email action has been taken, and by this Request WFH email will go to Manager.    Ask For Approval – Approval must take from group of Manager.  If WFH is Approved from Manager, then Email will send to Employee or Requester.  If WFH will Rejected, then Email will go to employee or Requestor of Rejected Request.  Open Catalog Item Which was Created & Add Request for Work from Home  After Requested, there will be Request Number will be Generate. Click on that. It will Request Form  In Request Form there will be RITM click on that there will show Approves, in this there will Name of Approval Person   Results-:   The manager will receive an Email Notification that the WFH request is there.  When Manager will Approve or Reject that Request then the Mail will get to Employee that Request is Approve or Reject 

Transform Map Scripts Go to Transform Map – Click on New.  We can write script in the transform map by checking the run Script checkbox.  And another way to write a script is in the Field Map to Check the Use Source Script  Or another way is Click on Transform Script- new  These are the Three ways in Transform mapping where we can write the Script  n Load Data Transfer seven types of scripting is present they are as follows: 1.onStart:- Executes at the beginning of the transformation process. Or It Runs only once, before any row is processed.  It is used for File validation, initialize variables, Stop entire transform Use Case: – Abort transform if the wrong source table is used.  2.onAfter:-Executes after each record is inserted or updated. or it runs for every row  After mappings are complete.  It is Used for Update target record, add work notes, Create related records.  Use case: – Add work note after incident creation.  3.onBefore:-Executes before each record is inserted or updated.  or it will run for every row and Before field mappings.  It is Used for Modify source data, set default values, Skip individual rows.  Use Case: – Set default priority if empty.  onChoiceCreate:-Executes when a choice value needs to be created during the transformation. or it runs When a new choice value is created during transform.  It is used for Modify choice labels, Control Dynamic Choice Creation.  Use Case: – Convert imported priority value into proper label.  onComplete:- Executes at the end of the transformation process. Or it runs Once and After all rows are processed.  It is used for Logging, Notifications, Cleanup.  Use Case: – Log transform completion.  onForeignInsert:- Executes when a related record is inserted. Or it runs when a new reference (foreign) record is created.  It is used for Modify referenced records, Set default values for reference tables.  Use Case: – Create new caller in sys_user during Incident import 7.onReject: – Executes when a record is rejected during the transformation.  or It runs When a record is rejected and ignore = true or transform error occurs  It is used for Error handling, Logging rejected records.  Use Case: – Log skipped records. 

OnChange Client Script An onChange Client Script runs on the client side (browser) when the value of a field changes on a form.  It is mainly used to:  Show or hide fields  Make fields mandatory or read-only  Auto-populate fields  Call Script Includes using GlideAjax  Validate user input instantly  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo. 1.1 Running onChange Client Script As onLoad Client Script When a form loads:  ServiceNow sets default values for fields  Values are populated from the database  The platform internally fires change events for those fields  Because of this, the onChange script gets executed once during form load.  1.1.1 Scenario When User is not selected, all the fields should be Read Only, and when user is selected, all the fields can be editable. Create New Client Script   Give name-> Add User Restriction, Type -> onChange, Field Name -> STS User   Add Script, comment out first “if statement” or remove it, it will make the onChnage client script run as onLoad Client Script.   Script:   function onChange(control, oldValue, newValue, isLoading, isTemplate) {  //    if (isLoading || newValue === ”) {  //       return;  }     var getValue = g_form.getValue(“u_sts_user”);     if(!getValue){      g_form.setReadOnly(“u_sts_mode”, true)      g_form.setReadOnly(“u_requirements”, true)      g_form.setReadOnly(“u_sts_user_comment”, true)      g_form.showFieldMsg(“u_sts_user”, “Select User First”, “info”);     }     else{      g_form.setReadOnly(“u_sts_mode”, false)      g_form.setReadOnly(“u_requirements”, false)      g_form.setReadOnly(“u_sts_user_comment”, false)      g_form.hideFieldMsg(“u_sts_user”, true);     }  }  In this script, the “isLoading” check is commented out, allowing the onChange Client Script to run during form load. When the form initializes, ServiceNow sets the value of “u_sts_user”, which triggers the script and locks related fields until a user is selected. This ensures the form remains controlled both on load and during user interaction. 1.2 Summary: onChange Client Scripts make ServiceNow forms more interactive by responding immediately to field value changes. In some cases, these scripts also run during form load because field values are initialized in the background. Understanding the role of the isLoading parameter helps maintain predictable behavior and ensures a clean, well-controlled form experience. 

Dashboards 1.1 Definition A Dashboard in ServiceNow is a visual interface that displays real-time information using reports, charts, lists, and performance indicators. It helps users monitor data, track performance, and make quick decisions without navigating multiple records. 1.2 Scenario 1.2.1 Show state-wise incident Count. Heading to All -> Platform Analytics -> Library -> Dashboards Select -> In-line Editor, Give Name -> State Wise Incident Count, Create Dashboard  Add new Element -> Data Visualization  Select -> New Visualization  Select Visualization type-> Donut, Data Sources -> Incident (Table)  Select Group By -> State, Legend -> Show legend and show legend value  1.3 Real-Time Use Case Examples 1.3.1 Incident Management Dashboard Open incidents by priority  SLA breaches in real time  Incidents assigned to the current user  Helps support teams focus on critical issues first.  1.4 Summary Dashboards in ServiceNow provide a powerful way to visualize and monitor data in real time. By combining reports, widgets, and filters, dashboards help users at all levels quickly understand system performance and take informed actions. When designed effectively, dashboards improve efficiency, transparency, and overall service quality. 

Dependent Choice Field in ServiceNow What is choice field? A Choice field is a predefined dropdown list that restricts user input to specific allowed values. These choices are stored in the sys_choice table.  What is a Dependent Choice Field? Dependent Choice fields change their values based on another field.  Scenario: – A college management system wants to store student details. While creating a student record, the user should first select the State, and based on the selected state, only the relevant districts should appear in the district dropdown.  Steps For Dependent Choice Field? Open instance  System Definition > Tables  Create new table with fields: –  Name(String)  Rollno(String)  State(Choice)  District(Choice)  Right click on state > configure dictionary > choices related list > New > Add choices.                                                                                             Choice  Dependent Value  Maharashtra  MH  Rajasthan  RJ  Gujrat  GJ   Submit.  Right click on District > configure dictionary > choices related list > New > Add choices    Choice  Value  Sequence  Dependent value  Mumbai  Mumbai  1  MH  Latur  Latur  2  MH  Raipur  Raipur  1  RJ  Kota  Kota  2  RJ  Surat  Surat  1  GJ  Baroda  Baroda  2  GJ  Advance view > Dependent field > click on use Dependent field > from dropdown select Dependent field (state) > submit > check results.  Dependent Choice filled created successfully.  Conclusion: – Choice fields are essential in ServiceNow development because they help maintain structured and consistent data. They are widely used in Incident, Change, Problem, and custom applications. Understanding choice fields is important for both ServiceNow developers and administrators. 

Import set and Transform map Introduction  An import set helps us to pull in data from various data sources and import them into the ServiceNow table.  Ways to import data  Manual import of data from a file source (CSV, XLS, or XML)  Manual import of data from an online data source (HTTP, FTP, LDAP, or JDBC)  Import data periodically from a data source by defining scheduled imports  Import data from a web service  There are four key points that we should keep in mind while working with import set tool: External data source: The source from where the data needs to be imported. Below are the multiple sources:   a. JDBC   b. LDAP  c. HTTP   d. FTP    e. Excel  f. CSV   g. X   Import set table: An import set table is a temporary staging table used to store raw data imported from an external source. It consists of sets of columns and rows imported from external sources. The system also adds a few columns that are used to identify the status of the import process.  Transform map: A transform map helps to create a relationship between fields in the import set table and the target table.  Target table: A target table is the one into which the data being imported is either inserted or updated. Best Practice  Before import we need to Verify/clean our data.  Data should not be imported in extremely large chunks  Load Data  Navigate to System Import Sets >Load Data     2. Fill-up below fields: Import set table: There are two options.  Create Table  Existing table  Create Table      3. Once import set created it will redirect you to following screen   4.  5. Now we need to create transform map  6. 7. Field mapping –  Field mappings are rules that are used to map the fields of stagging or import set table with target table fields.  Field maps establish a relationship between a field in an import set table and a field in the target table.  8. Mapping assist –  To map the fields of import set table with target table manually, click the Mapping Assist Related Link.  9. 10. Auto Map:  Click the Auto Map Matching Fields Related Link for ServiceNow to attempt to match the staging table columns to the target table columns based on column name. The auto mapped fields appear in the Field Maps section (tab). 11. 12. 13. Transform map is ready to transform data from import set to target table14. 15. Check import set table 16. 17. Now check the main table – data is loaded 18. 2. Existing table:  If you select existing table then select Import set table which you have created before)  a. Create table: If you select create table fill the below details:        i. Label: Any Name        ii. Name: This field will be automatically populated         iii. Source of import: Select File/ Data Source       iv. If you select File then you will get below option       v. File : Choose the file that you want to import in ServiceNow     vi. Sheet number: 1     vii. Header row: 1    viii. If you select File then you will get below option    ix. Data Source: Select data source from the dropdown. b. Click on Submit 3. Once the process will complete, you will get below message 4. We have to check that the data we is inserted properly into the import set table. We will click on Import Sets links to open Import Sets module. 5. Every attempt to upload new data will create a new Import Sets entry and will be linked to at least one import set table and a source. Each Import Sets is given a unique number that begins with ISET and is followed by 7 digits. The state of the import set is used to determine the status of the import set and tell whether the data is currently loading, loaded, processed, or canceled. Transform Script  The transform scripts can be used to control the behavior of the transformation process. onStart: The onStart event script is processed at the start of an import run, before any data rows are read. onStart runs at the very beginning of the import before any of the records are processed. If you want to notify user that the import has started then you can create the onStart script to send out the message.  onBefore: The onBefore event script is processed at the start of a row transformation, before the source row is transformed into the target row. onBefore runs before every row is processed. This script runs for each individual record. If you want to set or alter values on the source table it can be done here. onBefore scripts can be used to verify that the value of a source field is valid. If the value is invalid, the script can take action.  onAfter: The onAfter runs after every row has been processed, after the source row has been transformed into the target row and saved. Fields on the target table can be accessed from this point. They contain the value that was just inserted. At the time that this script runs, the source and target field values should be the same.  onForeignInsert: The onForeignInsert runs before a new referenced record is created. Since this script only runs on an insert, the choice action “create” has to be selected for that field map. If “create” is not selected, the script will never run.  At this point, we can access values on the source table. We also have access to the fields on the target table that have already been filled in. The one being transformed, however, will not yet have a value. onForeignInsert scripts can manage what happens when a new record is added to a referenced table. When I was playing around with onForeignInserts, I couldn’t find a way to change values on the referenced table from my script. There might be a way to do this, but I haven’t figured it out yet. An onAfter script might be a better option if that’s what you’re going for.  onChoiceCreate: he onChoiceCreate event script is processed at the start of a choice value creation, before the new choice value is created.   onComplete: The onComplete event script is processed at the end of an import run, after all data rows are read and transformed. onReject:The onReject event script is processed during the occurrence of a foreign record or choice creation, and the foreign record or choice is rejected, the entire transformation row is not saved.  Choice Action :  Choice Action is for Reference field and choice field only. It has

Service level Agreements (SLA) Service Level Agreement   It is a contract between the service provider and the customer that ensures response and resolution of tasks within a specified timeframe.  SLA timer  The SLA timer component is to track the amount of time required to complete the task as defined by the matching SLA definition.  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.  OLA –   An Operational Level Agreement (OLA) is an agreement that defines service commitments between internal teams or supporting organizations to ensure SLAs are met. (e.g., Network Team & Service Desk)  SLA Conditions-  Start Condition –   The SLA starts when this condition evaluates true.  Example: Incident state is New or In Progress  Pause Condition –   Defines when the SLA timer is temporarily stopped. Time is not counted while the pause condition is true.  Example: Incident state is On Hold, Waiting for customer response  Stop Condition –  Defines when the SLA timer ends.  Example: Incident state is Resolved or Closed  Reset Condition –   Defines when SLA timing is recalculated as if it started again.  Eg – when incident is reopened   Scenario:  The organization tracks user-reported incidents with SLAs defined for Priority 1 cases. A Response SLA of 15 minutes starts when the incident is created and assigned to a group and ends when it is assigned to an individual. A Resolution SLA of 3 hours begins at incident creation and ends when the incident is resolved, pausing while the incident is in the On Hold state and resuming once work continues. Both SLAs operate 24/7 based on the caller’s time zone.    Navigate to → All → SLA → SLA Definitions → New   Solution –  1.Create an SLA record for Priority 1 with a 15-minute response time, as per the configuration below.  2.Response SLA will be completed when it is assigned to any user.  3.Create an incident record with Priority 1 and assign it to any assignment group. The Response SLA is attached to the incident in the related list.  4. The Response SLA timer is breached after 15 minutes.   5.The Response SLA is marked as completed once the incident is assigned to a user.  6.Create Priority 1 Resolution SLA as below   7.The SLA is paused when the incident is On Hold, and business time is not calculated.  8.The SLA timer stops when the incident is resolved or closed, and the SLA state is marked as completed.  9.Create an incident record with Priority 1 and assign it to the user as shown below. The Resolution SLA will be attached to the incident.  10.After the incident is resolved, the SLA state is marked as completed once the stop condition is met. 

Access control List Access Control List   Access control list or ACL is a part of Security in ServiceNow.   ACL can be applied on Tables, UI Pages, Script Include also.   It is Nothing But to give permission to Tables & Fields.  Where we can restrict user’s access for below:i. Createii. Readiii. Writeiv. Delete To access ACL admin needs to elevate the role to “security admin”.  Admin override allows admin users to bypass ACLs. Even if an ACL would normally deny access, an admin can still perform the action.   Evolution order of ACL-   Role – ServiceNow checks whether the user has at least one role listed in the ACL. if condition is false then access denied  Condition – ServiceNow evaluates the Condition field on the ACL, if condition is false then access denied  Script – Script must return true to allow access, returning false (or nothing) denies access.  ServiceNow checks ACLs in this order:  table. Field    table.  *   table. None  *          *   *   .   field  *   .   none  The first matching ACL found is enforced.  Use case-  Configure the ACL so that the Payroll Manager group has full access to payroll data with create, read, update, and delete permissions, while the Payroll User group has read-only access and is restricted from creating, updating, or deleting payroll records.  Solution-  Create two roles ‘payroll_manager’ and ‘payroll_user’ and two groups Payroll Manager, payroll User.  Assign payroll_user role to Payroll User group and assign payroll_manager role to payroll manager group and assign some users to both groups.  Click on profile and Elevate role to “Security admin” to access the ACL.  Create ACL with read access to payroll user table. None and give roles “payroll_user” and “payroll_manager”.  Or Navigate to Payroll table and scroll down to access control related list.  Impersonate to user with “payroll_user” role.  Open payroll record can read record but cannot update create and delete record.  Because we have given only read access for user group so user can only see records.   Create the ACL record with create, write, delete access with payroll manager role.  Manager can access record create, read and write on record.   Now Create * access to payroll table for read access.  Impersonate with user having payroll_user role Payroll.   open payroll record and you will see payroll table fields but not data.  Summary –  Implemented role-based access control for the payroll system. The Payroll Manager role was granted full CRUD (create, read, update, delete) access to payroll records, while the Payroll User role was restricted to read-only access. This configuration secures the access for valid user. 

Flow Designer Properties Flow Designer in ServiceNow is a low-code automation tool used to design and automate business processes without heavy scripting. It allows users to create flows by defining triggers, conditions, and actions to automate tasks such as approvals, notifications, record updates, and integrations.   To create new flow, navigate to All – Process engine — Flow designer — New  After you click on New button on page, it will open to create new flow.  Flow Name Enter a clear and meaningful name that describes the purpose of the flow. This helps users easily identify the flow later.  Application Select the application scope in which the flow will run. It controls which data and actions the flow can access.  Description Briefly explains what the flow does and when it is triggered. This helps others understand the flow logic quickly.  Now click on Show additional properties   4.Protection It defines whether the flow is editable or read-only after creation. Setting it to read-only helps prevent unauthorized changes to the flow.  5.Run as It specifies the user context under which the flow executes.  User who initiates session The flow runs using the roles and permissions of the user who triggered it. the system limits flow actions by user ACL restrictions. Ensure that security restrictions don’t prevent users who trigger the flow from performing flow actions.  System user The flow runs with system-level privileges, regardless of who triggered it.   Updates appear as done by System, Does not evaluate Users roles/access when running the Flow.  6.Flow Priority Flow priority determines the execution order when multiple flows are triggered at the same time. By default, flows can be set to Low, Medium, or High, with High priority flows running first. 

Decision table A Decision table in ServiceNow is a configuration option that can be used to evaluate multiple conditions and return a result based on predefined logic. It simplifies complex decision-making by organizing rules in a tabular format, where each row represents a unique set of conditions and their corresponding output. Decision Tables are used when: Business logic depends on multiple conditions Rules change frequently Non-developers (admins / process owners) should manage logic You want consistency, reusability, and auditability Inputs (Conditions)  Fields used for evaluation  Example: Category  Rules (Rows)  Each row represents one decision rule  Use case: If Category = hardware then assignment group is Hardware, Category =Software then assignment group = Software, Category = Network then assignment group = Network and Select assignment group based on category.  Navigate to Decision TablesAll → Decision Builder → Decision Tables Create new decision table like below Now create a flow in flow designer and attach this decision table to flow like below  Now use update record action to update the assignment group based on category using data pill of corresponding decision table.  Output – Open incident form and update the category to “Hardware” on incident and check assignment group in incident will be updated to Hardware.