Mastering GlideAjax: Top Scenario Questions and Best Practices in ServiceNow

In the dynamic world of ServiceNow development, understanding core concepts and common scenarios is paramount. Whether you’re a seasoned developer or just starting your journey, being able to navigate and implement solutions effectively is key. This article delves into frequently asked questions and practical scenarios surrounding GlideAjax, a cornerstone of client-side scripting and efficient data retrieval in ServiceNow. We’ll break down complex topics into digestible pieces, offering real-world examples, best practices, and insights that will not only enhance your development skills but also boost your confidence in technical interviews.

Understanding Your ServiceNow Environment

Before diving into specific scripting scenarios, it’s crucial to be aware of your ServiceNow instance’s context. Knowing the version you’re working with and your development history provides valuable perspective.

1. What is the current version you are working on in ServiceNow?

As of this writing, I’m actively working with the Washington D.C. release, ensuring I’m leveraging the latest features and improvements. It’s always beneficial to be on the latest stable release to take advantage of new functionalities and security patches.

2. From which version did you start working?

My ServiceNow journey began with the Rome release. Since then, I’ve had the opportunity to work across several subsequent versions, including San Diego, Tokyo, Utah, Vancouver, and now Washington D.C. This progression gives me a deep understanding of how features have evolved and the migration paths involved.

User and Group Management: The Foundation of Access Control

Efficiently managing users and groups is fundamental to controlling access and permissions within ServiceNow. Understanding how to programmatically create, modify, and manage these entities is a common requirement.

3. Can we add permissions to users and groups? What is the best practice?

Absolutely! Permissions in ServiceNow are primarily managed through Roles. You can assign roles directly to individual users or, more commonly and efficiently, to groups. The best practice here is to manage permissions through groups. Why? Because when an employee leaves an organization or changes roles, you simply remove them from the relevant groups, and their permissions are automatically revoked. This simplifies administration and significantly reduces the risk of orphaned access rights.

4. What is the user table name?

The primary table for user information in ServiceNow is sys_user.

5. What is the group member table name?

The table that links users to groups is sys_user_grmember. This is where the many-to-many relationship between users and groups is established.

6. How to create a user account using a script?

Creating user accounts programmatically is straightforward using GlideRecord. Here’s a practical example:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Note: Field names might vary slightly; 'first_name' is common
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.password = gs.generatePassword('Password123!'); // Always generate secure passwords programmatically
userGr.insert();
gs.info('User ' + userGr.username + ' created with sys_id: ' + userGr.sys_id);
    

Troubleshooting Tip: Always ensure you’re setting required fields. Check the ‘sys_user’ table schema for mandatory fields specific to your instance configuration.

7. How to create a group using a script?

Similarly, groups can be created using GlideRecord:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'IT Support Team';
newGr.description = 'Handles all IT-related incidents and requests.';
// Assigning a manager (replace with actual sys_id)
// newGr.manager = '62826bf03710200044e0bfc8be5df1';
newGr.insert();
gs.info('Group ' + newGr.name + ' created with sys_id: ' + newGr.sys_id);
    

8. How to add permissions (roles) to a user/group account using a script?

Roles are managed through specific association tables:

• To a User: The association is stored in sys_user_has_role.
• To a Group: The association is stored in sys_group_has_role.

Here’s how you’d script it:

// Add a role to a user (replace sys_ids with actual ones)
var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.user = 'USER_SYS_ID'; // e.g., '62826bf03710200044e0bfc8be5d94'
userRole.role = 'ROLE_SYS_ID'; // e.g., '2831a114c611228501d4ea6c309d626d' (e.g., ITIL role)
userRole.insert();
gs.info('Role added to user.');

// Add a role to a group (replace sys_ids with actual ones)
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.group = 'GROUP_SYS_ID'; // e.g., '477a05d153013010b846ddeeff7b1225'
grpRole.role = 'ROLE_SYS_ID'; // e.g., '2831a114c611228501d4ea6c309d626d'
grpRole.insert();
gs.info('Role added to group.');
    

9. What exactly does user delegation mean in ServiceNow?

User delegation allows one user (the delegate) to perform actions on behalf of another user (the delegator). This is incredibly useful when the delegator is unavailable, such as during vacation or extended leave. The delegate gains access to perform tasks, receive notifications, and even approve items that would normally be handled by the delegator. It ensures business continuity without granting permanent access.

How to Set Up: Navigate to the delegator’s user record, scroll down to the “Delegates” related list, and add a delegate record specifying the delegate’s name, start/end dates, and the types of permissions they should have (assignments, notifications, approvals).

10. How to add and remove a group member from a group using a script?

This involves the sys_user_grmember table:

// Add a group member
var grMemAdd = new GlideRecord('sys_user_grmember');
grMemAdd.initialize();
grMemAdd.user = 'USER_SYS_ID'; // Sys ID of the user to add
grMemAdd.group = 'GROUP_SYS_ID'; // Sys ID of the group
grMemAdd.insert();
gs.info('User added to group.');

// Remove a group member
var grMemRemove = new GlideRecord('sys_user_grmember');
grMemRemove.addQuery('user', 'USER_SYS_ID'); // Sys ID of the user to remove
grMemRemove.addQuery('group', 'GROUP_SYS_ID'); // Sys ID of the group
grMemRemove.query();
if (grMemRemove.next()) {
    grMemRemove.deleteRecord();
    gs.info('User removed from group.');
}
    

Core ServiceNow Concepts: Incidents, Problems, and Changes

The Incident, Problem, and Change Management modules are the backbone of IT Service Management (ITSM) in ServiceNow. Understanding their purpose, relationships, and scripting capabilities is crucial.

11. How many user interfaces are there in ServiceNow?

Historically, ServiceNow has had several UI frameworks, including UI15 and UI16. The modern and recommended interface is the Next Experience UI (also known as Polaris), which offers a more intuitive and streamlined user experience.

12. What is meant by a web services user in the User account?

A “web services user” (or integration user) is a specific type of user account created in ServiceNow primarily for external applications or systems to interact with ServiceNow programmatically. These users typically authenticate using credentials (like username/password or OAuth) and are granted specific roles necessary for API access. Crucially, they cannot log in to the ServiceNow graphical user interface (GUI); their purpose is solely for system-to-system communication.

13. How to get the current logged-in user’s system ID on the client side?

On the client-side (e.g., within UI Policies, Client Scripts), you can access the current user’s `sys_id` using the global variable g_user:

var currentUserId = g_user.userID;
gs.info('Client-side User ID: ' + currentUserId); // Note: gs.info is server-side, this would typically be alert() or console.log() on client
    

Real-world Example: You might use this to dynamically set a reference field to the current user when a form loads.

14. How to get the current logged-in user’s system ID on the server side?

On the server-side (e.g., within Business Rules, Script Includes), you use the gs (GlideSystem) API:

var currentUserId = gs.getUserID();
gs.info('Server-side User ID: ' + currentUserId);
    

15. How to check if the current logged user is a member of a particular group?

This is a common check, especially for controlling visibility or actions:

// Replace 'Group Name' with the actual name of the group
if (gs.getUser().isMemberOf('Group Name')) {
    gs.info('User is a member of the group.');
} else {
    gs.info('User is NOT a member of the group.');
}
    

Interview Tip: Understanding server-side vs. client-side APIs (like gs.getUserID() vs. g_user.userID) is a frequent interview topic.

16. Which role is required to work on Access Control Lists (ACLs)?

To create, modify, or delete ACLs, you need the security_admin role.

17. What is impersonation?

Impersonation is a powerful feature in ServiceNow that allows an administrator (or someone with the appropriate role) to temporarily “act as” another user. This is invaluable for testing roles, permissions, and user-specific configurations without logging out and back in as the other user. You can access it via the user profile menu.

18. What is user preference?

User preferences are settings that individual users can configure to personalize their ServiceNow experience. These preferences are specific to the user and do not affect other users globally. Examples include list personalization (columns, sorting), form layout choices, or notification settings. They are stored in the sys_user_preference table.

19. What is an Incident?

An Incident represents a sudden interruption in IT service or a reduction in the quality of an IT service. When an employee experiences something that stops working unexpectedly, they report it as an incident to get support and restore normal service operations as quickly as possible.

20. What is a Problem?

A Problem is identified when the root cause of one or more incidents is unknown, or when it’s clear that multiple incidents share a common underlying cause. The goal of Problem Management is to find the root cause and either resolve it permanently (a “permanent fix”) or implement a workaround to prevent recurrence. If the same issue happens repeatedly to one employee, it might be tracked as a problem.

Distinction from Incident: If a single issue affects multiple users simultaneously, it’s treated as an incident. A Problem record might be created to investigate the root cause of this widespread incident. This often involves creating a “parent incident” for the initial report, with other affected users’ reports becoming “child incidents” linked to the parent. Closing the parent incident typically closes the associated child incidents.

21. Can we create a Problem record from an Incident?

Yes, absolutely. If during the investigation of an incident, it becomes apparent that the issue is recurring or has a deeper, underlying cause, you can create a Problem record directly from the incident form. This helps initiate the Problem Management process.

22. Can we create a Change Request from an Incident?

Yes. If resolving an incident requires a modification to the IT infrastructure or application (e.g., a software patch, configuration update), a Change Request can be initiated from the incident. This ensures that any changes are properly assessed, approved, and implemented following a defined change management process.

23. How to create an Incident record using a script?

Using GlideRecord to create incidents is a common task:

var incGr = new GlideRecord('incident');
incGr.initialize();
incGr.caller_id = 'USER_SYS_ID'; // Sys ID of the user reporting the incident
incGr.category = 'inquiry'; // Example category
incGr.subcategory = 'antivirus'; // Example subcategory
// incGr.cmdb_ci = 'CI_SYS_ID'; // Associate with a Configuration Item if known
incGr.short_description = 'User reports slow system performance';
incGr.description = 'The user is experiencing significant slowdowns when opening applications.';
incGr.assignment_group = 'GROUP_SYS_ID'; // Assign to a specific group
incGr.insert();
gs.info('Incident created with number: ' + incGr.number);
    

24. How to create a Problem record using a script?

Similar to incidents:

var probGr = new GlideRecord('problem');
probGr.initialize();
probGr.caller_id = 'USER_SYS_ID'; // Can be the user who reported the recurring issue
probGr.category = 'inquiry';
probGr.subcategory = 'antivirus';
// probGr.cmdb_ci = 'CI_SYS_ID';
probGr.short_description = 'Recurring issue with antivirus software';
probGr.description = 'Multiple users reporting that the antivirus scans are failing and causing system instability.';
probGr.assignment_group = 'GROUP_SYS_ID';
probGr.insert();
gs.info('Problem created with number: ' + probGr.number);
    

25. How to create a Change Request using a script?

And for change requests:

var changeGr = new GlideRecord('change_request');
changeGr.initialize();
changeGr.category = 'normal'; // Example change type
changeGr.subcategory = 'application_update';
// changeGr.cmdb_ci = 'CI_SYS_ID';
changeGr.short_description = 'Apply critical security patch to Application X';
changeGr.description = 'This change implements a security patch to address CVE-XXXX-XXXX.';
changeGr.assignment_group = 'GROUP_SYS_ID'; // Assign to CAB or Change Implementation group
changeGr.insert();
gs.info('Change Request created with number: ' + changeGr.number);
    

Business Rules and Automation: Orchestrating Workflows

Business Rules are powerful server-side scripting tools that allow you to automate processes based on record changes. They are essential for implementing complex logic and ensuring data integrity.

26. Logic for closing child incidents when a parent incident is closed.

This is a classic use case for an After Business Rule on the incident table:

• When to run: After
• Operation: Update
• Condition: current.state.changesTo(7) && current.parent == '' (Assuming state 7 is ‘Closed’ and it’s a parent incident)

// Business Rule Script:
if (current.state == 7 && current.parent == '') {
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();

    while (grChild.next()) {
        grChild.state = 7; // Set state to Closed
        grChild.update();
        gs.info('Child incident ' + grChild.number + ' closed.');
    }
}
    

27. Preventing incident closure if associated tasks are open.

This requires a Before Business Rule on the incident table to intercept the closure action:

• When to run: Before
• Operation: Update
• Condition: current.state.changesTo(7) (or the state value for Closure)

// Business Rule Script:
if (current.state.changesTo(7)) { // Check if state is changing to Closed
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    grTask.addQuery('state', '!=', 3); // Assuming state 3 is 'Closed' for incident tasks
    grTask.query();

    if (grTask.hasNext()) {
        gs.addErrorMessage('Cannot close the incident because there are open tasks.');
        current.setAbortAction(true); // Prevent the update
    }
}
    

This same logic can be applied to problem and change_request tables by adjusting the task table name (e.g., problem_task, change_task) and the conditions.

28. Closing associated incidents when a problem is closed.

Another After Business Rule on the problem table:

• When to run: After
• Operation: Update
• Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’)

// Business Rule Script:
if (current.state.changesTo(7)) {
    var grIncident = new GlideRecord('incident');
    // Find incidents linked to this problem
    grIncident.addQuery('problem_id', current.sys_id);
    grIncident.addQuery('state', '!=', 7); // Ensure we only update open incidents
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set state to Closed
        grIncident.update();
        gs.info('Incident ' + grIncident.number + ' closed due to Problem closure.');
    }
}
    

29. What is the relationship between Incident, Problem, and Change Management?

These three processes are tightly integrated within IT Service Management (ITSM):

• Incident: Focuses on restoring normal service operation as quickly as possible to minimize the impact on business operations. It’s about a reactive fix.
• Problem: Focuses on identifying the root cause of incidents and preventing their recurrence. It’s about proactive investigation and resolution of underlying issues. An incident might lead to a problem investigation.
• Change: Focuses on managing all changes to the IT environment in a controlled way to minimize risk and disruption. A problem resolution often requires a change (e.g., deploying a patch), and sometimes even incidents might necessitate a emergency change.

Flow: User reports an Incident -> If the issue is recurring or complex, a Problem is created to find the root cause -> If a permanent fix or improvement is identified, a Change Request is created to implement it.

ServiceNow Platform Fundamentals: Tables, Fields, and Configurations

A deep understanding of ServiceNow’s data model and configuration options is essential for effective development.

30. Give me some names of out-of-the-box (OOTB) tables.

OOTB tables are those provided by ServiceNow and typically do not start with x_ (custom applications) or u_ (legacy custom tables). Examples include:

• incident
• problem
• change_request
• sys_user
• sys_user_group
• cmdb_ci (Configuration Item)
• task

31. What are some of the base tables?

Base tables are fundamental tables that often serve as foundations for other tables. They typically don’t extend another table but are extended by many other tables. Key examples include:

• task: The base table for all task-based records like Incidents, Problems, Changes, Catalog Tasks, etc.
• cmdb_ci: The base table for all Configuration Items in the CMDB.
• sys_user: The base table for all user records.

32. Give me some examples of task tables.

As mentioned, these extend the task table:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• sc_req_item (Requested Item)

33. Whenever we create a table, how many Access Controls (ACLs) get created by default?

By default, when you create a new table and check the “Create application scope” or similar options that imply generating basic security, ServiceNow automatically generates four base ACLs:

• create
• delete
• read
• write

These provide basic CRUD (Create, Read, Update, Delete) permissions. You can uncheck the relevant option during table creation if you want to manage ACLs manually from the start.

34. How to create a number field, like an incident number?

Number fields (often called “Auto Number” fields) are configured in the field’s dictionary entry. When creating or editing a field:

• Go to the Control tab.
• Check the Auto number checkbox.
• Provide a Prefix (e.g., INC for incidents).
• Specify the Number of digits (e.g., 7).
• You can also define a Sequence if needed.

This ensures unique, sequentially generated numbers for records.

35. What happens when you extend a table?

When you extend a table (create a child table that inherits from a parent table):

• Inheritance: The child table inherits all fields and attributes from the parent table.
• No Duplicate System Fields: System fields (like sys_created_on, sys_updated_on, sys_id) are not duplicated in the child table; they are managed at the parent level.
• ‘Class’ Field: A field named sys_class_name (or similar, historically ‘class’) is added to the parent table. This field stores the specific type (sys_class_name) of the record, allowing ServiceNow to correctly identify which child table a record belongs to. Even if a table extends multiple other tables through inheritance chains, it typically only has one sys_class_name field in the ultimate parent.

36. Can you give me 10 field types?

Certainly! Here are 10 common field types in ServiceNow:

1. Reference: Links to a record in another table.
2. String: For text input (single-line or multi-line).
3. List: A many-to-many relationship field (e.g., adding multiple watch list users).
4. Choice: Dropdown list with predefined options.
5. Email: Specifically formatted for email addresses.
6. Date/Time: For storing both date and time.
7. Date: For storing only the date.
8. Boolean: True/False (checkbox).
9. Integer: Whole numbers.
10. Journal: For comments and work notes, allowing multiple entries over time.
11. Attachment: Allows users to attach files.

37. What is the difference between a temporary and a normal table?

• Normal Tables: Store data permanently. These are your standard ServiceNow tables like incident, sys_user, etc.
• Temporary Tables: Designed for short-term data storage. They typically extend the import_set_row table and automatically purge data after a set period (usually 7 days). They are often used for staging data during import processes or for temporary scripting needs.

38. Can we increase the retention period in a temporary table?

Yes, you can influence the retention period of temporary data, primarily through Archive Rules. While temporary tables have a default purge mechanism, archiving allows you to move older data to a separate archive table, effectively extending its accessibility beyond the default retention but managing performance on the main instance.

39. What is the difference between a remote table and normal tables?

The key difference lies in where the data resides and how it’s accessed:

• Normal Tables: Data is stored directly within your ServiceNow instance’s database.
• Remote Tables: Data is stored in an external data source (e.g., another database, a cloud service). ServiceNow connects to this external source to retrieve and display the data live. This is often achieved using features like IntegrationHub ETL or specific custom integrations. You’re essentially querying data from outside your instance.

40. What are one-to-one and one-to-many relationships in ServiceNow?

These describe how records in different tables relate to each other:

• One-to-Many Relationship: This is the most common. One record in Table A can be associated with multiple records in Table B, but each record in Table B is associated with only one record in Table A.
  • Example: A User (Table A) can have many Incidents (Table B). Each incident is typically assigned to one user (caller_id).
• Many-to-Many Relationship: Records in Table A can be associated with multiple records in Table B, AND records in Table B can be associated with multiple records in Table A. This requires a bridging table.
  • Example: An Incident (Table A) can be assigned to multiple Groups (Table B) via the sys_group_has_role table (or a custom assignment table). A group can be assigned to multiple incidents.
• Note: A one-to-one relationship is less common and often implemented using specific field configurations or constraints. For instance, if a user could only have one “profile” record, that would be one-to-one. The sys_user and a potential custom user_profile table could have this if designed that way.

41. In how many ways can we create a record in a ServiceNow table?

There are numerous ways to create records:

1. Forms: Manually filling out a form.
2. Record Producers: User-friendly forms that create backend records (often used with Service Catalog).
3. GlideRecord Scripting: Programmatically creating records using server-side scripts (Business Rules, Script Includes).
4. Client Scripts / UI Actions: Using g_form.save() or custom scripts on the client side.
5. Email: Configuring inbound email actions to create records.
6. Import Sets/Data Import: Importing data from files (Excel, CSV) or external sources.
7. APIs: Using REST, SOAP, or other web services.
8. UI Actions: Custom buttons or links that trigger record creation.

42. In how many ways can we make a field mandatory or read-only?

Several methods exist, offering flexibility based on the context:

1. Dictionary Properties: Directly on the field’s dictionary entry (sys_dictionary) – set ‘Mandatory’ or ‘Read only’ checkboxes.
2. Dictionary Overrides: To change parent table field behavior on a child table.
3. UI Policies: Client-side logic to make fields mandatory, read-only, visible/invisible based on conditions.
4. Data Policies: Similar to UI Policies but work on both client and server sides, enforcing data integrity.
5. Client Scripts: Using g_form.setMandatory('field_name', true/false); or g_form.setReadOnly('field_name', true/false);.
6. Business Rules: Server-side scripts can modify field attributes, though less common for simple mandatory/read-only than Data Policies.

43. Can we make two fields display fields in one table?

Technically, you can configure multiple fields as “Display” in the dictionary (typically only one is intended). However, this is strongly discouraged. The “Display” attribute is primarily used to determine which field’s value is shown in reference fields when a user searches for a record. Having multiple display fields can lead to confusion and inconsistent reference field behavior. ServiceNow recommends having only one primary display field.

44. Where are all tables stored?

Information about all tables defined in ServiceNow, including custom tables, OOTB tables, and their configurations, is stored in the sys_db_object table.

45. How to set a default value on a field?

Default values can be set in multiple ways:

• Dictionary Entry: In the field’s dictionary definition (sys_dictionary), there’s a ‘Default value’ field. This value is applied when a new record is created and the field is not otherwise populated.
• UI Policies/Client Scripts: You can dynamically set default values using scripts when a form loads or based on other conditions.
• Data Policies: Can also set default values server-side.

Example (Dictionary Default Value): For a ‘State’ field, you might set the default value to ‘1’ (Open).

46. What is the ‘current’ object?

The current object is a server-side GlideRecord object representing the record that is currently being processed. It’s available in Business Rules, Script Includes (when processing a record), and other server-side scripts. You use it to get and set values on the record that triggered the script execution.

47. How to set field values on the ‘current’ form (server-side)?

Using the current object:

• current.setValue('field_name', value);: Sets the internal value of a field. For reference fields, you provide the `sys_id` of the referenced record.
• current.setDisplayValue('field_name', value);: Sets the display value of a field. For reference fields, you provide the human-readable value (e.g., username), and ServiceNow will try to find the corresponding `sys_id`. This is often used for simpler fields or when the exact `sys_id` isn’t readily available but the display value is known.

// Example setting values on 'current' incident record
current.setValue('short_description', 'Issue resolved');
current.setValue('state', 6); // Assuming 6 is Resolved
current.setDisplayValue('assigned_to', 'John Doe'); // If 'assigned_to' is a reference to sys_user
    

Advanced Field Configurations: Qualifiers, Dependencies, and Calculations

Mastering these advanced configurations allows for highly dynamic and user-friendly forms.

48. What are Reference Qualifiers and their types?

Reference Qualifiers are used to filter the records displayed in Reference and List type fields. They restrict the choices available to the user, ensuring they select relevant data. There are three main types:

1. Simple Reference Qualifier:

   Description: A basic, static query defined using dot-walking and comparison operators. It’s straightforward and good for fixed filtering criteria.

   Example: To show only ‘Active’ users in a reference field pointing to sys_user, you’d set the condition in the dictionary entry to active=true.

   How to Use: Directly enter the query string in the “Reference qual” field of the reference field’s dictionary entry.

2. Dynamic Reference Qualifier:

   Description: Uses pre-defined “Dynamic Filter Options” which provide a more organized and reusable way to define context-aware filters. These options can be configured to adapt based on values from other fields on the form.

   Example: Displaying only incidents assigned to the same assignment group as the current record.

   How to Use: Create a Dynamic Filter Option (System Definition > Dynamic Filter Options). Then, in the reference field’s dictionary entry, select the “Dynamic” option and choose your created Dynamic Filter Option.

3. Advanced Reference Qualifier (JavaScript):

   Description: This is the most powerful type, allowing you to write custom JavaScript code to define complex filtering logic. It can leverage the current form’s context, user information, and intricate business rules.

   Example: Filter incidents to show only those assigned to the current user’s assignment group AND have a priority less than 3.

   How to Use: In the reference field’s dictionary entry, select “Advanced”. Enter your JavaScript code in the “Reference qual” field. The code should return a query string.

   javascript:
   var userGroup = g_user.getMyGroups().toString(); // Get current user's groups
   var query = "assignment_groupIN" + userGroup + "^priority<3";
   query;
               

   Note: The exact JavaScript syntax for dynamic queries can be complex and might involve functions like getRefQual() or directly referencing g_form variables.

Differences:

• Simple vs. Dynamic: Simple is static, Dynamic uses predefined options.
• Dynamic vs. Advanced: Dynamic uses configured options, Advanced uses custom JavaScript for maximum flexibility.
• Simple vs. Advanced: Simple is a basic query string, Advanced is a JavaScript function returning a query string.

49. What is a “Dependent Value”?

Dependent Values are used to create cascaded dropdowns. The choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This is a dictionary attribute.

How to Configure:

1. Identify your parent field (e.g., Category) and dependent field (e.g., Subcategory).
2. In the dictionary entry for the dependent field (Subcategory), set the Dependent field attribute to the name of the parent field (Category).
3. Define the choices for the dependent field, linking them to the specific parent field values. For example, under the ‘Subcategory’ choices, you’d specify that if ‘Category’ is ‘Hardware’, the choices are ‘Laptop’, ‘Desktop’, etc.

Example: Selecting “Hardware” in Category shows Laptop, Printer, Monitor in Subcategory. Selecting “Software” shows Operating System, Application.

50. What is a Calculated Value?

A Calculated Value is a field whose value is automatically determined by a script. This is typically configured within the field’s dictionary entry using the “Calculated ( a field value is calculated by a script)” option. When the record is saved, the script runs and populates the field.

Example: A ‘Full Name’ field that automatically concatenates ‘First Name’ and ‘Last Name’ using current.first_name + ' ' + current.last_name.

51. What are Attributes? Name some attributes you have used.

Attributes are special keywords defined in the dictionary entry of a field or table that modify or enhance its behavior. They provide a declarative way to add functionality without extensive scripting.

Some common attributes I’ve used:

• no_email: Prevents email notifications from being sent for changes to this field.
• no_attachment: Disables the attachment capability for a specific table or field.
• ref_auto_completer=...: Configures auto-completion behavior for reference fields.
• tree_picker: Changes a reference field to use a tree-like picker interface.
• readonly=true: Makes a field read-only (similar to dictionary setting).
• max_length=...: Sets the maximum character limit for a string field.

52. What is a Collection field on a table?

A “Collection field” in the context of a table’s dictionary entry actually refers to the entry that represents the table itself, not a specific field on the table. When you look at the dictionary entries for a table, there will be one entry where the ‘Type’ is ‘Collection’. Attributes or settings applied to this ‘Collection’ entry affect the table as a whole (e.g., `no_attachment`, `label`). This entry is automatically created when a table is created.

53. How to enable/disable attachments on the form using attributes?

You can disable attachments for an entire table by adding the no_attachment attribute to the Collection field’s dictionary entry for that table. To enable, simply remove the attribute or ensure it’s not present.

54. What are Dictionary Overrides? What properties can be overridden?

Dictionary Overrides allow you to modify the behavior or definition of a field that has been inherited from a parent table onto a child table. This is crucial for customizing inherited fields without altering the parent table’s definition.

You can override properties such as:

• Default value
• Mandatory flag
• Read-only flag
• Display flag
• Max length
• Label
• Attributes
• Reference qualifiers
• Choice list specifications
• …and many other dictionary attributes.

Example: The ‘Priority’ field might be mandatory on the ‘Task’ table, but you want to make it optional on the ‘Incident’ table. You would create a Dictionary Override for ‘Incident’ on the ‘Priority’ field to uncheck the mandatory box.

User Interface and Policy Configurations

Understanding how to control the user experience through various UI elements and policies is vital.

55. What are Application Menus?

Application Menus (also called Modules) are the entries in the ServiceNow navigation filter (the left-hand menu). They provide users with access to specific forms, lists, reports, or other functionalities within an application. Creating modules is how you make your custom applications or specific views of OOTB applications accessible to end-users.

56. What is a Process Flow?

A Process Flow visually represents the stages or states of a record as it moves through a workflow. It provides a clear indication of where the record is in its lifecycle, helping users understand the process and what steps are next. It’s often implemented using the “Process Flow” formatter on a form.

57. What are Data Lookup Rules?

Data Lookup Rules (found under System Definition > Data Lookups) are used to automatically populate field values on a record based on matches found in a lookup table. When a user enters data in specific fields (the “Lookup” fields), the system checks the lookup table for a matching record and populates other fields (the “Result” fields) on the current form accordingly.

Example: If a user enters a Country, a lookup rule might automatically populate the State/Province and Zip Code fields based on pre-defined data.

58. What are UI Policies?

UI Policies are client-side scripting tools used to dynamically modify form behavior. They allow you to make fields mandatory, read-only, visible/invisible, set default values, or execute client scripts based on specific conditions. They are a more user-friendly alternative to Client Scripts for many common form manipulations.

59. What is the ‘Global’ checkbox in UI Policies?

When the ‘Global’ checkbox is checked on a UI Policy, it means the policy will apply to all views of the form. If it’s unchecked, you can specify particular views where the UI Policy should be active.

60. What is ‘Reverse if false’ in UI Policies?

If the ‘Reverse if false’ checkbox is selected, the actions defined in the UI Policy (e.g., making a field mandatory) will be undone when the UI Policy’s conditions evaluate to false. For instance, if a field is made mandatory when a condition is true, checking ‘Reverse if false’ will make it optional again when the condition becomes false.

61. What is the ‘On Load’ checkbox in UI Policy?

When ‘On Load’ is checked, the UI Policy’s conditions and actions are evaluated and applied as soon as the form loads. If ‘On Load’ is unchecked, the UI Policy will only trigger its actions when a change occurs on the form that meets its conditions (e.g., a field value changes).

62. What is the ‘Inherit’ checkbox in UI Policy?

If the ‘Inherit’ checkbox is checked, the UI Policy will also be applied to child tables that extend the table on which the UI Policy is defined. This allows for consistent UI behavior across an inheritance hierarchy.

63. Can you write script in UI Policy?

Yes. To execute custom JavaScript within a UI Policy, you need to:

1. Enable the “Run scripts” checkbox on the UI Policy itself.
2. Within the UI Policy Actions related list, enable the “Run scripts” checkbox for a specific action.

This allows you to embed client-side scripts that execute when the UI Policy conditions are met.

64. Can we convert a UI Policy as a Data Policy?

Yes, ServiceNow provides a feature to convert UI Policies into Data Policies. You typically open the UI Policy, and there will be an option (often a button or link) like “Convert to Data Policy”.

65. Which are all the cases where a UI Policy cannot be converted as a Data Policy?

While conversion is often possible, UI Policies might not be directly convertible if they rely heavily on client-side specific actions that don’t translate well to server-side execution, such as:

• Directly manipulating the visibility of related lists.
• Controlling view switching logic.
• Complex client-side script actions that don’t have a direct server-side equivalent or are too performance-intensive for server-side execution.
• When the UI Policy’s primary purpose is purely visual presentation that doesn’t need server-side enforcement.

Data Policies are designed for data integrity enforcement across all data sources (client and server), so UI-specific visual manipulations are their main limitation.

66. What are Data Policies?

Data Policies are powerful tools that enforce data policies on records regardless of the data source (client-side form, server-side script, API call, import). They can make fields mandatory, read-only, or visible/invisible based on defined conditions, ensuring data consistency across the platform.

By understanding these scenarios and best practices, you’ll be well-equipped to tackle common development tasks and excel in technical discussions and interviews related to ServiceNow’s powerful capabilities.