Custom Scoped Application   Overview    Application scoping protects applications by identifying and restricting access to application files and data. This document walks through the key operations for creating and managing custom scoped applications in ServiceNow.    Navigate and search for in ServiceNow Studio  Click on Create Application UI action.  Provide Name and in the advanced setting select scoped.  Provide required roles.  Give the table name.  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   Navigate to studio and click on create new.  Select table from the data model.  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 assigned to field.   You will see the field which is extended from the task table.  Goto file and click on create file .  See my table and other table     create=form which table you want this form   After creating ⇒ see form design    We know there are two ways to configure a form .   a.form design   b.form layout   Do changes as per your requirement  Also verify after you apply those changes.  You will see the form which we have designed.   We can create module for that purpose search for application menu on the navigation pane.  On the related list click on New ui action.  Make sure your module is in the global scope.  You are able to create module in global scope because of application access =All application scope     Now GOTO è module  work_assignment è Configureè Table  You will see it is accessible from All application scope only.  Now change to this application scope.  Changed scope to global.  Open application.  And Create module.  You will see there are no matched found.  Next, create script include in Global application.  Check in Background script  Output  You will see your script include with same scope.  Check in Background script-same scope.  Output  Also, Check in global scope.  Output  Open the application.  See From here we can publish in update set  Scoped application caller tracking and caller 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 application and now we will write background script on Advanced work_assignment.  Function is caller restricted.  Output  To remove restricted access.  Goto =application  Application administration = true.    In the Related section you will see restricted caller access privileges    Now check in advanced work_assignment scope   Output  Create 2nd script include  Application scope should be –work_assignment.  Caller Access -caller tracking.     And accessible from=all application scope.  You will see the scope is advanced work_assignment in background script.  Output  Navigate and type sys_scope_privilege.LIST  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  Navigate and search for collaborators.  Related link -click on manage collaborator.  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  Scan Application  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 

Import Set & Transform Map (Category & Subcategory) Problem Statement: – While importing a data from excel into ServiceNow if you have choice fields, like (category) & (subcategory) then it should get imported.      Steps:  First step is we need to load data in our case its incident data I have exported and download it.  Then navigate to Load Data. Under system import set you will see the Load Data Module.  Then, we need to create import set table which is nothing but our staging table which will store the data temporary.  You can select staging table if it has already created by click on ‘Existing Table’ or you can create new staging table by selecting the ‘Create Table’.  Also, you need to select the source of the import, which is nothing, but you excel file e.g. Incident1.xlsx.  Create Table-> Provide Label Name->Source of the import-> choose your excel file-> Click on Submit  Now you will see the status as complete. Next, we need create a transform map. Click on ‘Create Transform Map’.  Provide name, your target table. If you want to auto map the fields, select ‘Auto Map matching fields’ by using mapping assist you can manually map the fields. Click on save.  We will select the auto map matching fields related link. Our fields are maps successfully.  Now we need to set the coalesce field to avoid the duplicate record. Here we will provide the coalesce field to our number field.  Also, we need to create the choice action for our category file. Based on the requirement.  Choice Action: – This field specify what to do if the import set contains reference field or choice value.  Create: – Create a new choice or record in the reference table.  Ignore: – Ignore the new value from the source table  Reject: – The entire row(record) containing the new value and continue to the next row.    Click on transform related link to transform the data from excel to servicenow.  You will see the status and the message of your transform map.  Creation of new choices in the category table you need to select the choice action as create.  Next step we need to add the new choice in our excel sheet.As, you can see in the excel file we have added the new choice field called ‘Manufacture’   Now we need to select ‘Choice Action’ as ‘Create’ To create a new choice.  Click on transform related link to create ‘transform’. Your date will be loaded into service now and new choice will be added successfully.  Whenever we select category as ‘Manufacture’ then automatically subcategory should get populated.  For this navigate to ‘incident’ table. Right click on the subcategory and select ‘Show choice list’.  We need to add the dependant value for the subcategory as you know subcategory is dependent on the category.  After that we need to load data in our ‘sys_choice’ table’ Follow the previous steps to perform import set and transform map. Load the data and create transform map.  Click on auto map matching field to map the fields. Click on transform.  After transforming open the incident record select category as Manufacture you will see the ‘DNS, Operating System and VPN. 

Script Action What is Script Action: Script Actions in ServiceNow are server-side scripts that execute asynchronously when a specific event is triggered. They are part of ServiceNow’s event-driven architecture and are stored in the sysevent_script_action table.     2.Key Characteristics   Asynchronous execution: They run in the background via the Event Queue, so they don’t block the current transaction or impact user performance. Event-triggered: They are linked to events defined in the Event Registry (sysevent_definition). Server-side only: Full access to Glide APIs, Script Includes, and other server-side resources (just like Business Rules or Script Includes).     3.How Script Actions Work:  An event is triggered (usually using gs.eventQueue() from a Business Rule, UI Action, Flow, Script Include, etc.). The Event Processor picks up the event from the queue. The matching Script Action (if active) executes.     In the Script Action, you have access to two main objects:   current — The GlideRecord of the record associated with the event (if provided). event — A GlideRecord containing event details, especially event.parm1, event.parm2, event.parm3, etc., for passing custom data.    4.Usecase:  There is a date field on incident form so whenever user select date after saving the form automatically it should create a Problem Record.  Execution:  Navigation: Event–>Registry Navigation: Script Action  Navigate:Business Rule  For Execution Test Create new Incident with date and time  Go to navigation and check the Problem record  

Script Action What is Script Action: Script Actions in ServiceNow are server-side scripts that execute asynchronously when a specific event is triggered. They are part of ServiceNow’s event-driven architecture and are stored in the sysevent_script_action table.  Key Characteristics  Asynchronous execution: They run in the background via the Event Queue, so they don’t block the current transaction or impact user performance. Event-triggered: They are linked to events defined in the Event Registry (sysevent_definition). Server-side only: Full access to Glide APIs, Script Includes, and other server-side resources (just like Business Rules or Script Includes).  How Script Actions Work: An event is triggered (usually using gs.eventQueue() from a Business Rule, UI Action, Flow, Script Include, etc.). The Event Processor picks up the event from the queue. The matching Script Action (if active) executes.     In the Script Action, you have access to two main objects:   current — The GlideRecord of the record associated with the event (if provided). event — A GlideRecord containing event details, especially event.parm1, event.parm2, event.parm3, etc., for passing custom data.  Usecase: There is a date field on incident form so whenever user select date after saving the form automatically it should create a Problem Record.  Execution:  Navigation: Event–>Registry 

Advanced Work Assignment AWA (Advance Work Assignment) helps distribute work automatically to available agents instead of assigning tasks manually  This document explains the complete setup of Advanced Work Assignment (AWA) in ServiceNow. The use case is to automatically assign incidents to agents based on incident priority and queue configuration.  Step 1: Create Service Channel  Go to the navigation pane and search for Advanced Work Assignment, then open Service Channel. The service channel defines which table of records will be routed to agents using AWA. It acts as the main connection between incidents and assignment queues.    Step 2: Click on New  Click on the New button to create a new service channel configuration. This allows you to define how incidents should be routed and assigned automatically. Ensure you provide all mandatory details correctly before saving.    Step 3: Configure Service Channel  Provide the name as Incident and select the Incident table. Set the Assigned To field so the system can automatically assign incidents to users. Configure default work team size, capacity, and utilization conditions according to business requirements.    Step 4: Create Queue  After creating the service channel, the next step is to create queues. Queues help categorize work items based on conditions such as incident priority. Navigate to Queue from the navigation pane and create a new queue.    Step 5: Configure High Priority Queue  Create a queue named Incident – High Priority and link it to the Incident service channel. Set the routing condition to include Critical and High priority incidents only. This ensures urgent incidents are routed quickly to available agents.    Step 6: Create Remaining Priority Queue  Create another queue for Medium, Low, and Planning priorities. This helps separate high-priority work from regular incidents. Using multiple queues improves workload management and assignment efficiency. 

                                   Glide Aggregate It is a server-side ServiceNow API, used to perform aggregate operations like COUNT, SUM, AVG, MIN, and MAX on table records without retrieving full record data  Methods of Glide Aggregate -:  addAggregate(aggregate, fieldname)-> Adds an aggregate function like COUNT, SUM, AVG, MIN, MAX on a given field.  GroupBy-> Groups the records based on the supplied field.  Order By-> Sorts the result in ascending order.  OrderByDesc-> Sorts the result in descending order by the given field.  query()-> Executes the database query.  next ().-> Moves to the next aggregated record.  GetAggregate.-> Gives you the final calculated answer (like total count or total sum).   GetValue.-> Gives you the value stored in a field for that record.   addEncodedQuery(query String)- -> Adds a ready-made filter to get only the records you want.   setGroup(Boolean)-> Tells the system to group similar records together.   SetHavingCondition-> Filters the grouped results based on total/count/sum values.   SetLimit.-> Tells the system to return only a limited number of records.  Example -:    1). Using GlideAggregate in ServiceNow, how many incidents are grouped by category?  Output -:  2. To find number of incidents active true  Output -: 

                                 UI Action  A UI Action is a feature used to provide buttons, links or context menu items on forms and lists. The actions enable users to update records, call workflows, run scripts, or navigate to another page.  Some Examples of UI Actions:  Submit   Approve / Reject   Close Incident   Assign to Me   Create Change Request  Example-:  Add a “Mark as VIP” button on the User form to set up a custom VIP flag.  Step 1: Navigate on Sys_User table and right click on Navigation Bar –> Configure–> UI Action  Step 2: Click on New then Add Name for New Action (Mark as VIP) –>Add table on Which we have to add UI Action (Sys_users) –> Action Name (mark_vip)  Step 3: Click on Checkbox where you have to add a Button on form or List. Step 4: Add Script for Button, add Condition and Write a Script. Step 5: Go on Users Form, open one User in Navigation bar there “Mark as VIP” Step 6: Click on “Mark as VIP” Then That user will be mark as VIP, Automatic VIP Checkbox will fill.  Context Menu in UI Action The Context Menu in a UI Action is the menu that appears when you right-click on a record in ServiceNow. Instead of showing a button on the screen, the action stays hidden until the user right-clicks.  Why use the Context Menu?  Keeps the screen clean  Hides less-used actions  Provides quick access when needed  Creating Context Menu in Form & List -:   Add Name & Click on Form & List Context Menu Check box. 

Email Script Definition: Email Script is a server-side script used within ServiceNow notifications to dynamically generate and format email content before the email is sent. It helps retrieve record data and display it in a customized format inside notification emails. Implementation Steps: Navigate to System Notification → Email → Notification Email Scripts. Create a new Email Script and select the appropriate table (e.g., Incident). Write the script using template.print() to display required field values. Create a Notification on the same table. Configure the notification trigger condition (e.g., when Assigned To changes). Add recipients such as the Assigned User. Call the Email Script in the notification body using ${mail_script:Script Name}. Save and test the notification. Scenario: Send Incident Details to Assigned User Requirement Whenever an Incident is assigned to a user, send an email containing Incident details such as Number, Short Description, Priority, State, and Assignment Group. Implementation Steps Step 1: Create an Email Script Navigate to System Notification → Email → Notification Email Scripts Click New Name: Incident Details Script Table: Incident Step 2: Write the Email Script Step 3: Create a Notification Navigate to System Notification → Email → Notifications Click New Name: Incident Assigned Notification Table: Incident Step 4: Configure When to Send Send When: Record Updated Condition: Assigned To changes Assigned To is not empty Step 5: Configure Recipients Users/Groups in fields: Assigned To   Step 6: Add Email Script to Notification Body Step 7: Test the Functionality Open an Incident record. Change the Assigned To field. Save the record. Verify that the assigned user receives the email with all Incident details. Result: Whenever an Incident is assigned to a user, an email notification is automatically sent containing the latest Incident information generated dynamically using the Email Script.

Email Inbound/Outbound Action In ServiceNow, inbound and outbound is used to exchange the data between ServiceNow and external systems.For example: If an email subject contains “Network Issue”, ServiceNow automatically creates an Incident and assigns it to the Network team.  Now let’s see one example, if anyone reply from an email how it works in ServiceNow. Example Setup: In this example, we will first explain how to enable 2-Step Verification for the Gmail account that will be used. Go to Manage Your Google Account, navigate to the Security section, and activate 2-Step Verification by following the on-screen instructions. This ensures secure authentication before integrating the email.  After completing the above step, then go to create the passkey for the Gmail account.  Copy the generated passkey and temporarily save it in the clipboard or Notepad for future use.  After that, log in to the PDI and search for an Email Account. In the Application Navigator, navigate to System Mailboxes → Administration → Email Accounts and go to module.  Click on the Email Accounts module, select New, and fill the data into fields.  Aslo,  create a user account and give the user some Email address.  In the above snapshot, enter the 16-digit passkey you generated earlier into the highlighted Password field. Set the Type as SMTP, as shown in the snapshot.  What is SMTP? SMTP (Simple Mail Transfer Protocol) is the core protocol used to send emails out from the platform, handling notifications, alerts, and inbound email processing by connecting to mail servers, allowing instances to communicate with users and external systems for automated communication.  After completing the configuration, click on Test Connection to verify that the email setup is working successfully.  Now repeat the same procedure for the POP3 connection, ensuring all required details are configured correctly.  Now create an Email Inbound Action. In the When to Run section, set the Type = Reply and configure the condition as shown in the snapshot below.  Next, navigate to the Action section and configure the required conditions. You may also write a script if needed; however, if the conditions are working correctly, writing a script is not necessary.  Now, create an incident using the configured user and resolve the incident, a notification will automatically be sent and delivered to your registered email address.  Like below, you can see the Gmail you configured, the confirmation email sent through ServiceNow.  When you reply to the incident email, the message is automatically populated in the incident activity, and the incident is reopened or moved to the In Progress state. 

Logging and Debugging Server-Side Logging (gs)  These methods belong to the GlideSystem (gs) object and are used in server side scripting such as Business Rules, Script Includes.  1. gs.info(), gs.warn(), gs.error()  These are the modern standards. They write to the System Log [sys_log] table. They are “level-aware,” meaning you can filter your logs by severity.  Example: gs.info(“User {0} has logged in.”, gs.getUserName());  Best for: Production-ready code and general auditing.  Use gs.info() if you are building a Scoped Application or want to follow the latest ServiceNow best practices.  2. gs.log()  The “old reliable.” It also writes to the System Log but allows you to specify a Source column, which makes filtering much easier in the list view.  Example: gs.log(“Processing record”, “MyCustomApp”);  Use gs.log() only if you are working in the Global Scope and specifically want to use a custom string in the Source column for easy filtering.  Note: This is not available in Scoped Applications (you must use gs.info there).  3. gs.print()  It writes to the localhost log file on the server but does not always appear in the sys_log table UI.  Example: gs.print(“Hello from the background script”);  Best for: Running scripts in the “Background Scripts” module where you want an immediate output on the screen.  4. gs.debug()  This only logs if the system property glide.debug.log (or a specific session debug) is enabled.  Example: gs.debug(“Variable X is: ” + x);  Best for: Troubleshooting complex logic without cluttering the logs for every user.  Client-Side Logging (console)  These run in the user’s browser (Chrome, Firefox, etc.) and are used in Client Scripts and UI Scripts.  console.log() / console.debug()  These don’t write to the ServiceNow database at all. They write to the Browser Console .  console.log()   This is the standard way to output general information to the browser console. It is the most commonly used tool for “sanity checking” values while building a UI feature.  For example, print the new value while running OnChange Client script,  console.log(“The new value of the field is: ” + newValue);   console.debug()   Functionally, this is almost identical to console.log(). However, it is intended for “verbose” or “debug” level messages that you might not want to see all the time.  Example: console.debug(“Current Field Value: ” + g_form.getValue(‘short_description’));  Best for: Real-time debugging of UI behavior.  Note: Always remove these before moving code to Production, as they are visible to any tech-savvy user.  log.print()  In standard ServiceNow JavaScript, log.print is not a native global function. You might see this in specific integrations (like IntegrationHub ETL) or if a developer has created a custom log object. Usually, if you try to run this in a standard Business Rule, it will throw an error.      Method  Environment  Log Destination  Scoped App Compatible?  gs.info()  Server  System Log (sys_log)  Yes  gs.log()  Server  System Log (sys_log)  No (Global only)  gs.print()  Server  Localhost File / Script Output  Yes  gs.debug()  Server  System Log (if debug enabled)  Yes  console.debug()  Client  Browser Console  Yes    Server-Side Debugging  This applies to Business Rules, Script Includes, Scheduled Jobs, and UI Actions (server-side).  The Script Debugger   The Script Debugger is a built-in interface that allows you to set breakpoints. When the code hits that line, the system pauses execution, allowing you to inspect variable values in real-time.  How to use: Open “Script Debugger” in the Filter Navigator, set a breakpoint (click the line number in your script), and trigger the action.  Best for: Complex logic where you need to see how variables change step-by-step.  Script Tracer   The Script Tracer records every server-side script that executes during a transaction. It captures:  Business Rules  Script Includes  Script Actions  UI Actions (Server-side) It shows you the order of execution and the state of the record before and after each script ran.  Open the Tracer: Navigate to System Diagnostics > Script Tracer.  Start Tracing: Click the Start Tracer button in the top right.  Perform the Action: Go to your form (e.g., an Incident) and perform the action you want to debug (e.g., click “Update” or change the “State”).  Stop and Analyze: Go back to the Script Tracer tab and click Stop Tracer.  Review the Trace: You will see a list of every script that ran.  Session Debugging   ServiceNow allows you to toggle specific debug logs that appear at the bottom of your UI page.  How to use: Navigate to System Diagnostics > Session Debug. You can choose “Debug Business Rule,” “Debug Security (ACL),” or “Debug SQL.”  Best for: Seeing which Business Rules are firing and in what order.  Background Scripts   The Scripts – Background module is the “scratchpad” of ServiceNow. You can paste a snippet of code and run it immediately to see the output.  Best for: Testing a specific function or a GlideRecord query without having to trigger a record update.  Client-Side Debugging  This applies to Client Scripts, UI Policies, and Catalog Client Scripts.  Since client scripts run in the browser,   Console: Use console.log() to print values or debugger; in your code to force the browser to pause execution.  Sources Tab: You can find your client script in the “Sources” tab and add breakpoints directly in the browser.  The JavaScript Log & Field Watcher  ServiceNow provides a built-in “JavaScript Log” window that sits inside the platform UI.  Field Watcher: Right-click any field label and select Watch field. A pane opens at the bottom showing every script, policy, or ACL that touches that specific field.  Best for: Figuring out “What script just hid this field?” or “Why did this value change to 10?”    Tool  Environment  Use Case  Script Debugger  Server  Pausing execution and inspecting variables.  Background Scripts  Server  Testing standalone code snippets quickly.  Session Debug  Server  Watching Business Rules and ACLs in real-time.  Field Watcher  Client  Tracking why a specific field’s value/visibility changed.  Browser Console  Client  Inspecting UI errors and logging manual triggers.