Client Script

Q: What is a Client Script, and what are its different types?

A: A Client Script is a JavaScript code that executes on the client-side, typically within a user’s web browser. It is triggered by specific client-side events such as form loading, submission, or field value changes. Client Scripts enhance user experience by applying custom logic and automating interactions within the ServiceNow platform.

There are four main types of Client Scripts:

1. OnLoad: Executes when a form loads in the browser. It is commonly used to set default values, modify the form layout, or show/hide fields.
2. OnSubmit: Runs when a form is submitted, allowing for data validation or additional actions before the form is saved.
3. OnCellEdit: Triggers when a cell in a list is edited, enabling actions based on data changes in the cell.
4. OnChange: Activates when a field’s value changes, making it useful for dynamically updating other fields, performing validations, or applying conditional logic.
   

---

Q: What are the different ways to access server-side data in a Client Script?

A: In ServiceNow, Client Scripts can access server-side data using several methods. The most commonly used approaches are:

1. getReference(): This method retrieves related record data from the server asynchronously. It is useful for fetching additional details from a reference field without making direct server calls.
2. GlideAjax: GlideAjax enables Client Scripts to call Script Includes on the server, allowing for complex logic execution and retrieval of data asynchronously. It is ideal for handling large datasets or performing operations that require server-side processing.
3. Display Business Rule (BR): A Display Business Rule runs when a form is loaded and sends server-side data to the client. This method is useful for preloading specific information into a form without requiring additional client-server interactions.

Note: While it is technically possible to use GlideRecord in Client Scripts to query server-side data, this practice is discouraged as it can negatively impact performance and violate ServiceNow’s best practices.

Best Practice: The recommended methods for accessing server-side data in Client Scripts are getReference(), GlideAjax, and Display Business Rules, as they provide efficient and optimized communication between the client and server.

---

Q: What are the different ways to make a field mandatory in ServiceNow?

A: In ServiceNow, there are multiple ways to enforce a field as mandatory, each serving different use cases:

1. Client Script: Using an onChange or onSubmit Client Script, you can dynamically set a field as mandatory based on specific conditions. This provides flexibility in determining when the field should be required.
2. UI Policy: UI Policies allow you to make fields mandatory based on form interactions or predefined conditions. They are easier to manage than Client Scripts and automatically update the form when conditions are met.
3. Data Policy: Data Policies enforce mandatory field rules at both the client and server levels. This ensures data consistency, even when records are created or updated via APIs, imports, or background scripts.
4. Field Dictionary Level: Setting a field as mandatory at the dictionary level enforces the requirement system-wide. This means the field is always required, regardless of how the record is being created or modified.

Each of these methods can be used individually or in combination, depending on your specific business requirements for field validation.

---

Q: When should we use a Client Script versus a UI Policy?

A:

• Use a UI Policy when you need to make fields mandatory, read-only, or visible/invisible based on conditions. UI Policies are easy to configure and do not require scripting, making them a preferred choice for simple form customizations.
• Use a Client Script when you need advanced logic beyond what UI Policies can achieve. Client Scripts are ideal for setting field values dynamically, interacting with server-side data, or implementing complex form behaviors that require scripting.

In general, UI Policies should be used whenever possible for maintainability and performance, while Client Scripts should be reserved for more complex requirements.

---

Q: What is the execution order between UI Policies and Client Scripts?

A: UI Policies execute after Client Scripts. If both are triggered by the same action, the Client Script runs first, followed by the UI Policy.

When there is conflicting logic between a Client Script and a UI Policy, the UI Policy takes precedence. If both modify the same field or form behavior, it’s important to plan the logic carefully to avoid conflicts and ensure the desired outcome.

---

Q: What is the purpose of the “Isolate Script” checkbox in Client Scripts?

A: The “Isolate Script” checkbox in Client Scripts ensures that the script runs in its own execution scope, preventing conflicts with global variables and functions from other scripts.

When enabled, it helps avoid unintended interactions between different scripts by encapsulating variables and functions within a separate scope. This improves script reliability and maintainability, especially in large or complex ServiceNow environments.

---

Q: What is the g_form object in ServiceNow, and can you list five commonly used methods along with their examples?

A: The g_form object in ServiceNow is used in Client Scripts and UI Policies to interact with form fields dynamically. It allows developers to manipulate field values, visibility, read-only states, and mandatory properties on a form.

Five Common g_form Methods and Their Usage:

1. g_form.getValue(fieldName) – Retrieves the value of a specified field.

var userName = g_form.getValue('user_name');
alert("User Name: " + userName);

2.g_form.setValue(fieldName, value) – Sets the value of a specified field.

g_form.setValue('priority', '1'); // Sets priority to '1 - Critical'

3. g_form.setVisible(fieldName, isVisible) – Shows or hides a field on the form.

g_form.setVisible('comments', false); // Hides the 'comments' field

4. g_form.setReadOnly(fieldName, isReadOnly) – Makes a field read-only or editable.

g_form.setReadOnly('short_description', true); // Makes the 'short description' field read-only

5. g_form.setMandatory(fieldName, isMandatory) – Marks a field as mandatory or optional.

g_form.setMandatory('impact', true); // Makes the 'impact' field mandatory

These methods help customize and control form behavior dynamically based on user input or business logic. 🚀

---

Q: What is the difference between g_form and g_scratchpad in Client Scripts?
A:

• g_form is used to manipulate form fields on the client side (e.g., setting values, making fields mandatory, hiding/showing fields).
• g_scratchpad is used to pass data from the server-side (via Script Include) to the client-side without making additional AJAX calls.

---

Q: How can you prevent a form from being submitted using a Client Script?
A:
Use an onSubmit Client Script and return false to stop form submission. Example:

function onSubmit() {  
    if (g_form.getValue('short_description') == '') {  
        alert('Short description is required!');  
        return false; // Prevents form submission  
    }  
    return true;  
}  

---

Q: What is the difference between getXML() and getXMLAnswer() when using GlideAjax in Client Scripts?
A:

• getXML() returns the full XML response and requires a callback function to process it.
• getXMLAnswer() directly retrieves the answer attribute from the response, making it simpler to use.

---

Q: How can you hide a field only for a specific user role using a Client Script?

A: Use g_user.hasRole() to check the user’s role and then hide the field:

if (g_user.hasRole('itil')) {  
    g_form.setVisible('impact', false);  
}  

---

Q: How can you dynamically populate a dropdown (choice field) using a Client Script?

A: Use g_form.clearOptions() to remove existing options and g_form.addOption() to add new ones dynamically. Example:

g_form.clearOptions('category');  
g_form.addOption('category', '', '-- Select a Category --');  
g_form.addOption('category', 'hardware', 'Hardware');  
g_form.addOption('category', 'software', 'Software');  

---

12. Q: What are the differences between Client Scripts and Business Rules in ServiceNow?
    A:

• Client Scripts run on the client-side (browser) and affect form behavior dynamically.
• Business Rules run on the server-side and are used for database operations like inserts, updates, and deletes.
• Client Scripts execute before form submission, while Business Rules execute after records are modified in the database.

---