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. 

Schedule Job A Scheduled Job is a script that runs automatically at a defined time or interval to perform a specific task in ServiceNow. Why Do We Need Scheduled Jobs? Scheduled Jobs are used when: No user action is required A task must run daily, weekly, monthly, or at a specific time Data needs to be processed in the background Key Components of a Scheduled Job When you create a Scheduled Job, you configure: – Name Meaningful name describing the job – Run When the job should run: Daily Weekly Monthly Once Periodically (every X minutes/hours) – Script The logic that will execute automatically Scheduled Job Example Scenario:Automatically close incidents that are in Resolved state for more than 7 days. var gr = new GlideRecord(‘incident’);gr.addQuery(‘state’, ‘6’); // Resolvedgr.addEncodedQuery(‘sys_updated_on<=javascript:gs.daysAgoStart(7)’);gr.query(); while (gr.next()) {gr.state = ‘7’; // Closedgr.update();} Steps to Create Scheduled Job : Step 1: Navigate to Scheduled Jobs System Definition → Scheduled Jobs → New Step 2: Fill Basic Details Name: Daily Open Incident Reminder Run: Daily Time: 07:00:00 Active: true Step 3: Script (Example Code) Step 4: Email Notification Create an Email Notification: Table: Incident Event name:daily.open.incident.alert To: IT Manager Subject: Daily Open Incidents Older Than 3 Days Body: Hello Team, Below are the incidents open for more than 3 days: ${parm1} Regards,ServiceNow    Output Every morning at 7:00 AM: Scheduled Job runs Checks for old open incidents Sends one consolidated email to the IT Manager

gsftsubmit In ServiceNow, forms often contain buttons like Update, Resolve, or Close.Behind many of these buttons, ServiceNow uses a function called gsftSubmit. gsftSubmit is a client-side JavaScript function used to submit a form and trigger a UI Action’s server-side logic. Why gsftSubmit? In ServiceNow, UI Actions can contain : – Client-side code – Server-side code But the server-side code will NOT run automatically when a button is clicked. To move execution from client → server, the form must be submitted.This is exactly what gsftSubmit does. Syntax of gsftSubmit  gsftSubmit(null, g_form.getFormElement(), ‘action_name’); Explanation of each parameter : 1. First Parameter – sysId null -Usually kept as null 2. Second Parameter – formElement g_form.getFormElement() -Represents the current form 3.Third Parameter – action_name ‘action_name’ – Must exactly match the Action name of the UI Action.  Example : Create UI Action Table: Incident Name: Resolve Incident Action name: resolve_incident Client: True  

Assignment Rule Assignment Rule is used to automatically assign tasks (like incidents, problems, or change requests) to specific user or group based on certain conditions.  It Only Applies to Assigned to & Assignment Group      How to Create Assignment Rule on Incident table.    Step 1-: Go to Navbar and Search Assignment rule.    

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