Unlocking the Power of ServiceNow: Your Top GlideForm API Questions Answered

Welcome! In the dynamic world of ServiceNow development, mastering the GlideForm API is crucial for building robust and user-friendly applications. Whether you’re a seasoned developer or just starting your journey, understanding how to manipulate forms and their elements programmatically can significantly enhance your workflow and the end-user experience. This article dives deep into some of the most frequently asked questions about GlideForm API, providing practical insights, real-world examples, and tips to help you excel.

We’ll cover everything from foundational knowledge like table names and user management to more advanced concepts like creating records, handling relationships between records, and implementing complex client-side logic. Let’s get started!

Getting Started: Foundations and Permissions

Before we dive into complex scripting, let’s lay the groundwork with some fundamental concepts. Understanding how users, groups, and permissions are managed is key to building secure and functional applications.

1. Your ServiceNow Version Journey

It’s always good to know the landscape of your development environment. When asked about the versions I’ve worked with, a comprehensive answer would include the progression of releases:

Answer: My experience spans across several key ServiceNow releases, including Rome, San Diego, Tokyo, Utah, Vancouver, and Washington D.C. This exposure allows me to understand the evolution of platform features and best practices across different versions.

2. User and Group Permissions: Best Practices

Managing who can do what is a cornerstone of any secure system. In ServiceNow, this is primarily handled through roles.

Question: Can we add permissions to users and groups? What is the best practice for this?

Answer: Absolutely! You can grant permissions (which are essentially defined by Roles in ServiceNow) to both individual users and groups. This can be done manually through the user interface or programmatically using GlideRecord.

The absolute best practice is to manage permissions primarily through groups. Here’s why: When an employee joins your organization, you add them to relevant groups. When they leave, you simply remove them from those groups, and all their associated roles and permissions are automatically revoked. This drastically simplifies user lifecycle management and reduces the risk of orphaned permissions or accidental access. Manually assigning roles to individual users can quickly become unmanageable.

3. Core Table Names: The Building Blocks

Understanding the underlying tables is fundamental for any scripting involving data manipulation.

Question: What is the user table name?

Answer: The primary table for user information in ServiceNow is sys_user.

Question: What is the group member table name?

Answer: The table that links users to groups is sys_user_grmember. This is a crucial junction table.

4. Programmatic User and Group Creation

Automating the creation of users and groups can be a lifesaver for large-scale deployments or integration scenarios.

Question: How to create a user account using script?

Answer: You can create a new user record using a GlideRecord script like this:


    var userGr = new GlideRecord('sys_user');
    userGr.initialize();
    userGr.username = 'jdoe';
    userGr.firstname = 'John';
    userGr.lastName = 'Doe';
    userGr.email = 'jdoe@example.com';
    userGr.insert();
    gs.info('User created: ' + userGr.username);

Troubleshooting: Ensure you have unique usernames and valid email formats. Check for duplicate entries before inserting to avoid errors.

Question: How to create a group using script?

Answer: Similarly, creating a group is straightforward with GlideRecord:


    var newGr = new GlideRecord('sys_user_group');
    newGr.initialize();
    newGr.name = 'Testing Group';
    // You'll need the sys_id of a user to assign as the manager
    newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
    newGr.email = 'testing@tcs.com';
    newGr.description = 'This is a test group created via script.';
    newGr.insert();
    gs.info('Group created: ' + newGr.name);

Interview Relevance: Be ready to explain the purpose of initialize(), setValue() (though not explicitly shown here, it’s often used), and insert().

5. Assigning Roles Programmatically

Now, let’s tie those users and groups to permissions.

Question: How to add permissions (roles) to a user or group account using script?

Answer: When you assign a role, ServiceNow creates a record in a specific “has role” table. The process differs slightly for users and groups:

For Users: Roles are stored in the sys_user_has_role table.


        var userRole = new GlideRecord('sys_user_has_role');
        userRole.initialize();
        userRole.setValue('user', '62826bf03710200044e0bfc8be5d94'); // Sys ID of the user
        userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
        userRole.insert();
        gs.info('Role added to user.');

For Groups: Roles assigned to groups are stored in the sys_group_has_role table.


        var grpRole = new GlideRecord('sys_group_has_role');
        grpRole.initialize();
        grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
        grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
        grpRole.insert();
        gs.info('Role added to group.');

Practical Explanation: Think of these tables as bridges. sys_user_has_role connects a user to a role, and sys_group_has_role connects a group to a role. When a user is a member of a group that has a role, they inherit that role’s permissions.

User Delegation and Group Management

ServiceNow offers powerful features for managing user availability and team collaboration. Let’s explore user delegation and how to manage group memberships.

6. Understanding User Delegation

User delegation is a vital feature for business continuity, especially when employees are out of the office.

Question: What exactly does user delegation mean in ServiceNow?

Answer: User delegation in ServiceNow allows one user (the delegate) to perform tasks and access resources on behalf of another user (the original user). This is typically used when the original user is unavailable due to vacation, leave, or other reasons. The delegate gains the necessary permissions to act, ensuring that critical workflows, like approvals, continue without interruption.

Example: If Sarah is going on a two-week vacation, she can delegate her approval responsibilities for certain records to her colleague, Mark. Mark can then log in (or ServiceNow can automatically act on his behalf based on configuration) and approve/reject requests that would normally require Sarah’s attention. This prevents bottlenecks.

How to Set It Up: To configure delegation, navigate to the original user’s record, scroll down to the ‘Delegates’ related list, and click ‘New’. Here, you can specify the delegate’s name, the start and end dates for the delegation, and crucially, the types of actions they can perform (assignments, notifications, approvals, etc.).

Interview Relevance: This question tests your understanding of business continuity features within ServiceNow.

7. Managing Group Memberships with Scripts

Automating the addition and removal of users from groups is a common administrative task.

Question: How to add and remove group members using script?

Answer: You’ll use the sys_user_grmember table for these operations:

Adding a Group Member:


        var grMem = new GlideRecord('sys_user_grmember');
        grMem.initialize();
        grMem.user = '62826bf03710200044e0bfc8be5d94'; // Sys ID of the user to add
        grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys ID of the group
        grMem.insert();
        gs.info('User added to group.');

Removing a Group Member:


        var grMem = new GlideRecord('sys_user_grmember');
        grMem.addQuery('user', '62826bf03710200044e0bfc8be5d94'); // Sys ID of the user to remove
        grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
        grMem.query();
        if (grMem.next()) {
            grMem.deleteRecord();
            gs.info('User removed from group.');
        } else {
            gs.info('User not found in the specified group.');
        }

Troubleshooting: Always verify the sys_ids for both the user and the group. Ensure you’re using the correct table (sys_user_grmember) and methods.

Client-Side vs. Server-Side Scripting

Understanding the context in which your scripts run is critical. ServiceNow differentiates between client-side (browser) and server-side (instance) execution.

8. Accessing the Current User’s Sys ID

You’ll often need to reference the currently logged-in user in your scripts.

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

Answer: On the client-side (within UI Policies, Client Scripts, etc.), you use the global g_user object:


    // Example in a Client Script
    alert('Your User ID is: ' + g_user.userID);
    // This will output something like: Your User ID is: 6816f79cc0a8016401c5a33be04be441

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

Answer: On the server-side (Business Rules, Script Includes, etc.), you use the gs (GlideSystem) object:


    // Example in a Business Rule
    var currentUserID = gs.getUserID();
    gs.info('The current user sys_id is: ' + currentUserID);

Interview Relevance: This is a fundamental distinction that interviewers often probe.

9. Checking Group Membership

Programmatically determining if a user belongs to a specific group is a common requirement for conditional logic.

Question: How to check if the current logged-in user is a member of a particular group?

Answer: On the server-side, the gs.getUser().isMemberOf() method is your go-to:


    // Example in a Business Rule or Script Include
    var groupName = 'ITIL Users'; // Replace with the actual group name
    if (gs.getUser().isMemberOf(groupName)) {
        gs.info('The current user is a member of the ' + groupName + ' group.');
        // Perform actions for members
    } else {
        gs.info('The current user is NOT a member of the ' + groupName + ' group.');
        // Perform actions for non-members
    }
    // Returns true if the user is part of the specified group, false otherwise.

Note: For client-side, you’d typically use g_user.hasRole('role_name') if you’re checking roles, or you might need to make a GlideAjax call to a server-side script to check group membership if it’s not directly exposed.

Security and Impersonation

Security is paramount in any platform. Understanding access controls and how to test them is vital.

10. Roles for Access Control

When you need to configure or manage security rules, a specific role is required.

Question: Which role is required to work on Access Control (ACLs)?

Answer: The security_admin role is required to create, modify, or delete Access Control Lists (ACLs) in ServiceNow.

Interview Relevance: Demonstrates understanding of ServiceNow’s security architecture.

11. What is Impersonation?

Impersonation is a powerful tool for testing user experiences.

Question: What is impersonation?

Answer: Impersonation in ServiceNow allows an administrator or a user with the appropriate role (like impersonator or admin) to temporarily log in and operate as another user. This is invaluable for testing user interfaces, workflows, and permissions from the perspective of different users without needing their actual credentials.

Example: If a user reports an issue with how a form looks or behaves for them, an administrator can impersonate that user to see exactly what they are seeing and diagnose the problem more effectively.

Incident, Problem, and Change Management: The Lifecycle

These three modules are the core of IT Service Management (ITSM) in ServiceNow. Understanding their relationship and how they interact is crucial.

12. Defining Incident, Problem, and Change

Question: What is an incident?

Answer: An incident is a sudden interruption in the normal IT service or a reduction in the quality of a service. When an employee experiences something that stops working unexpectedly, they create an incident to get support from the IT help desk to restore normal service operation as quickly as possible. The primary goal is restoration.

Question: What is a problem?

Answer: A problem is the underlying cause of one or more incidents. If the same issue, or a recurring symptom, is reported multiple times by the same employee or across multiple employees, it likely points to an underlying problem. The goal of problem management is to find the root cause and prevent future incidents.

Key Distinction: If a single issue is impacting multiple users simultaneously, it’s often treated as a major incident. A problem is more about identifying and resolving the *cause* of repeated incidents. If the same problem affects multiple people, you might create a “parent incident” for the current disruption and link other affected users’ reports as “child incidents” to it. Closing the parent incident typically closes its children.

13. Interconnecting ITSM Records

These modules are designed to work together seamlessly.

Question: Can we create a problem record from an incident?

Answer: Yes. If a support engineer, while working on an incident, identifies that the issue is recurring or widespread, they can create a Problem record directly from the incident form. This action often pre-populates the Problem record with details from the incident, saving time and ensuring context is maintained.

Question: Can we create a change request from an incident?

Answer: Absolutely. If resolving an incident requires a modification to the IT infrastructure or an application (e.g., applying a patch, reconfiguring a server), a Change Request can be initiated from the incident. This ensures that the proposed change is properly assessed, approved, and implemented following a defined change management process.

14. Scripting ITSM Record Creation

Automating the creation of these records can streamline workflows.

Question: How to create an incident record using script?


    var gr = new GlideRecord('incident');
    gr.initialize();
    gr.caller_id = '86826bf03710200044e0bfc8be5d94'; // Sys ID of the user reporting the issue
    gr.category = 'inquiry';
    gr.subcategory = 'antivirus';
    gr.cmdb_ci = 'affd3c843720100044e0bfc8bcbe5dc3'; // Sys ID of the Configuration Item affected
    gr.short_description = 'Test record created via script';
    gr.description = 'This is a detailed description of the test incident.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
    gr.insert();
    gs.info('Incident created with number: ' + gr.number);

Question: How to create a problem record using script?


    var gr = new GlideRecord('problem');
    gr.initialize();
    gr.caller_id = '86826bf03710200044e0bfc8be5d94';
    gr.category = 'inquiry';
    gr.subcategory = 'antivirus';
    gr.cmdb_ci = 'affd3c843720100044e0bfc8bcbe5dc3';
    gr.short_description = 'Test problem record via script';
    gr.description = 'Detailed description for the test problem.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
    gr.insert();
    gs.info('Problem created with number: ' + gr.number);

Question: How to create a change request using script?


    var gr = new GlideRecord('change_request');
    gr.initialize();
    gr.category = 'inquiry';
    gr.subcategory = 'antivirus';
    gr.cmdb_ci = 'affd3c843720100044e0bfc8bcbe5dc3';
    gr.short_description = 'Test change request via script';
    gr.description = 'Detailed description for the test change request.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
    // You would typically set planned start/end dates, risk, etc.
    gr.insert();
    gs.info('Change Request created with number: ' + gr.number);

Practical Explanation: When creating these records programmatically, always ensure you’re providing essential fields like caller_id, short_description, and relevant CI information if applicable. Use gs.info() for debugging.

15. Automating ITSM Workflows with Business Rules

Business Rules are the workhorses for server-side automation.

Question: Write logic for whenever a parent incident is closed, all its child incidents should also be closed.

Answer: This logic is best implemented as an After Business Rule on the incident table.


    // Business Rule: Close Child Incidents
    // Table: Incident
    // When: After
    // Update: true
    // Condition: current.state.changesTo(7) && current.parent == ''

    // Script:
    if (current.state == 7 && current.parent == '') { // Assuming state 7 is 'Closed' and it's a parent incident
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id);
        grChild.query();

        while (grChild.next()) {
            // Ensure the child incident isn't already closed to avoid unnecessary updates
            if (grChild.state != 7) {
                grChild.state = 7; // Set the state to Closed
                grChild.update();
                gs.info('Closed child incident: ' + grChild.number);
            }
        }
    }

Explanation: This rule triggers *after* an incident is updated. The condition checks if the state has just changed to ‘Closed’ (state 7) and if the incident has no parent (meaning it’s a top-level incident). If true, it queries for all incidents whose ‘parent’ field points to the current incident’s sys_id. For each found child, it sets the state to ‘Closed’ and updates it.

Question: Implement a rule: When closing an incident, if any associated incident task is still open, prevent the closure.

Answer: This requires a Before Business Rule on the incident table.


    // Business Rule: Prevent Incident Close with Open Tasks
    // Table: Incident
    // When: Before
    // Insert: false
    // Update: true
    // Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

    // Script:
    if (current.state == 7) { // Check if the state is being changed to Closed
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id);
        // Assuming state 3 is 'Closed' for incident tasks. Adjust if your states differ.
        grTask.addQuery('state', '!=', 3);
        grTask.query();

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

Explanation: A Before rule is used because we want to stop the action (closing the incident) *before* it happens. It checks if the incident is being set to ‘Closed’. Then, it looks for any incident_task records linked to this incident that are *not* closed. If any are found, an error message is displayed, and current.setAbortAction(true) stops the incident from being closed.

Extension: This same logic pattern applies to Problems and Changes, checking their respective task tables (e.g., problem_task, change_task).

Question: Implement a rule: Whenever a problem is closed, all associated incidents should also be closed.

Answer: Again, an After Business Rule on the problem table is suitable.


    // Business Rule: Close Associated Incidents on Problem Closure
    // Table: Problem
    // When: After
    // Update: true
    // Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

    // Script:
    if (current.state == 7) { // If the problem is being closed
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Find incidents linked to this problem
        grIncident.addQuery('state', '!=', 7); // Ensure the incident isn't already closed
        grIncident.query();

        while (grIncident.next()) {
            grIncident.state = 7; // Set the incident state to Closed
            grIncident.update();
            gs.info('Closed incident associated with problem: ' + grIncident.number);
        }
    }

Explanation: Similar to the parent/child incident rule, this triggers after a problem is updated to ‘Closed’. It then finds all incidents linked via the problem_id field and closes them.

16. The ITSM Relationship Explained

Question: What is the relationship between Incident, Problem, and Change Management?

Answer: These three processes form a crucial triad within IT Service Management (ITSM):

Incident Management: Focuses on restoring normal service operation as quickly as possible and minimizing the adverse impact on business operations. It’s about getting things working again, even if the root cause isn’t fully understood yet.
Problem Management: Aims to identify the root cause of incidents, prevent their recurrence, and minimize the impact of incidents that cannot be prevented. It delves deeper to find the ‘why’ behind issues.
Change Management: Controls the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. It ensures that changes are properly assessed, approved, scheduled, and implemented to avoid causing new incidents or problems.

The Flow: A user reports an incident. If the issue is recurring or widespread, a problem record is created to investigate the root cause. If the solution to the problem (or a fix for the incident) requires a modification to the IT environment, a change request is initiated to manage that modification.

ServiceNow Data Model and Architecture

Understanding how ServiceNow structures its data and applications is key to effective development.

17. Out-of-the-Box vs. Custom Tables

Question: Give me some names of out-of-the-box tables.

Answer: Out-of-the-box (OOB) tables are those provided by ServiceNow itself, not created by you or a scoped application. They typically do not start with x_ (custom applications) or u_ (legacy custom applications). Examples include:

incident
problem
change_request
sc_req_item (Requested Item)
sys_user
sys_group
task (a base table)
cmdb_ci (Configuration Item base table)

Note: Tables created within scoped applications will have a prefix like u_ or x_ followed by the application scope identifier (e.g., sn_customerservice_account). If a table starts with x_ and is part of a global application, it’s considered a custom table.

18. Base Tables and Table Extension

Question: What are some of the base tables?

Answer: Base tables are foundational tables in ServiceNow that are designed to be extended by other tables. They provide common fields and structures. Key examples include:

task: Provides common fields for task-like records (e.g., incident, problem, change, sc_task).
cmdb_ci: The base table for all Configuration Items in the Configuration Management Database.
sys_user: The base table for user information.

Question: Give me some examples of tables extending the task table.

Answer: Incident, Problem, and Change Request are classic examples of tables that extend the task table. This means they inherit fields like number, assigned_to, assignment_group, state, opened_at, etc., from the parent task table.

19. Table Creation and Access Controls (ACLs)

When you create a new table, ServiceNow automatically sets up basic security.

Question: When you create a table, how many access controls (ACLs) are created by default?

Answer: By default, when you create a new table (and the checkbox “Create an application menu” or similar related options are checked), ServiceNow automatically generates four Access Control Lists (ACLs). These typically include:

A read ACL for everyone (or for users with basic access).
A write ACL (often for administrators).
A create ACL.
A delete ACL.

These defaults provide a basic security framework. You’ll often need to refine these based on your specific application requirements.

Troubleshooting: If you find you cannot perform certain actions (like creating or editing records), check the ACLs associated with the table. Ensure the user attempting the action has the necessary roles and that the ACL conditions are met.

20. Field Types and Attributes

ServiceNow offers a rich set of field types to capture data effectively.

Question: Can you give me 10 field types?

Answer: Certainly! Here are 10 common field types in ServiceNow:

Reference: Links to a record in another table.
String: For short text entries.
List: Allows selection of multiple records from another table (e.g., multi-reference).
Choice: A dropdown list of predefined options.
Email: Specifically formatted for email addresses.
Date/Time: For storing both date and time.
Date: For storing only the date.
Boolean: A true/false or yes/no field (checkbox).
Integer: For whole numbers.
Journal: For audit trails and comments, typically with a history.
Attachment: Allows users to upload files.

21. Table Relationships Explained

Understanding how tables relate to each other is fundamental to database design.

Question: What is one-to-one and one-to-many relationship in ServiceNow?

Answer:

One-to-Many Relationship: This is the most common relationship. It means 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: Users and Incidents. One user (Table A) can have many incidents (Table B), but each incident (Table B) is typically assigned to only one user (Table A) as the caller. The relationship is managed by a reference field on the ‘many’ side (Incident table has a reference field to the User table).
Many-to-Many Relationship: This occurs when one record in Table A can be associated with multiple records in Table B, AND one record in Table B can be associated with multiple records in Table A. This is usually implemented using a “junction” or “linking” table.
- Example: Incidents and Groups. An incident might need to be worked on by multiple groups (e.g., Network team, Server team). A group can also be involved in many different incidents. The sys_user_group_members table is a junction table, but more broadly, if you wanted to link many incidents to many groups directly, you’d create a table like incident_group_assignment with reference fields to both incident and sys_user_group.
One-to-One Relationship: While less common than one-to-many, this happens when one record in Table A is associated with exactly one record in Table B, and vice-versa. This is often achieved by placing a unique reference field on one table pointing to the other, ensuring only one match.

22. Table Types: Temporary vs. Normal

ServiceNow uses different types of tables for various purposes.

Question: What is the difference between a temporary and a normal table?

Answer:

Normal Tables: These are your standard, persistent tables (like incident, sys_user). Data stored in these tables remains permanently until it’s explicitly deleted or archived according to retention policies.
Temporary Tables: These tables are designed for short-term data storage. They often extend the import_set_row table and are typically used for staging data during import processes or for intermediate calculations. Data in temporary tables has a limited lifespan, often automatically purged after a set period (e.g., 7 days) to manage instance performance and storage.

Question: Can we increase the retention period in a temporary table?

Answer: Yes, you can influence the retention period of data in temporary tables, primarily through Archive Rules. While they are inherently temporary, archive rules can be configured to move data to an archive rather than permanently deleting it after its initial lifespan, effectively extending its availability beyond the default purging period.

23. Remote Tables

Sometimes, you need to access data that resides outside your ServiceNow instance.

Question: What is the difference between a remote table and normal tables?

Answer:

Normal Tables: Store data directly within your ServiceNow instance’s database. When you query a normal table, you are accessing data that resides locally.
Remote Tables: These are tables that appear within ServiceNow but whose data is actually stored and managed in an external system (like another database or an external application). When you query a remote table, ServiceNow retrieves the live data from the external source in real-time. This is often achieved using technologies like IntegrationHub or custom integrations.

Form Customization and Behavior Control

The user interface is where users interact with ServiceNow. Customizing forms to be intuitive and efficient is key.

24. Creating Records in Multiple Ways

Question: In how many ways can we create a record in a ServiceNow table?

Answer: ServiceNow provides several avenues for record creation:

Forms: The most common way, directly filling out a form and clicking ‘Submit’ or ‘Save’.
GlideRecord: Programmatic creation using server-side scripts (as shown in previous examples).
Record Producers: A type of service catalog item that generates records in backend tables (e.g., creating an incident from the portal).
Email: Inbound email actions can create records based on incoming emails.
Excel Sheet / Import Sets: Using data import tools to bulk create records.
External Systems: Via APIs (REST, SOAP) or integrations.

25. Controlling Field Behavior: Mandatory, Read-Only

Making fields mandatory or read-only ensures data integrity and user guidance.

Question: In how many ways can we make a field mandatory or read-only?

Answer: You have multiple options:

Dictionary Properties: Directly on the field’s dictionary entry, you can set ‘Mandatory’ and ‘Read only’ checkboxes.
Dictionary Overrides: To change the default behavior for a field in a child table (e.g., make a field mandatory on Incident but not on its parent Task table).
UI Policies: Client-side logic to make fields mandatory, read-only, visible/hidden, or set default values based on conditions.
Data Policies: Similar to UI Policies but work on both client and server-side, enforcing mandatory/read-only attributes regardless of the data source.
g_form.setMandatory(fieldName, boolean): Client-side JavaScript to dynamically set a field as mandatory.
g_form.setReadOnly(fieldName, boolean): Client-side JavaScript to dynamically set a field as read-only.

26. Display Fields: A Unique Identifier

Display fields play a role in how records are presented.

Question: Can we make two fields display in one table?

Answer: No, you should not have more than one ‘Display’ type field checked on a table. The ‘Display’ attribute is typically used for reference fields to determine what value is shown when that field is referenced elsewhere. Having multiple display fields would lead to confusion and inconsistent behavior in reference lookups.

27. Default Values and Current Object

Pre-populating forms with default information is a common requirement.

Question: How to set a default value on a field?

Answer: You can set default values in several ways:

Dictionary Entry: The simplest method is to specify a ‘Default value’ directly in the field’s dictionary record. This value is populated when a new record is created.
UI Policies: Use a UI Policy with ‘On Load’ execution to set default values based on conditions.
Client Scripts: An ‘On Load’ Client Script can also set default values using g_form.setValue('field_name', 'default_value');.
Business Rules: An ‘Before’ Business Rule can set default values for new records before they are inserted into the database.

Question: What is the ‘current’ object?

Answer: The current object is a server-side GlideRecord object that represents the record currently being processed. It’s available in server-side scripts like Business Rules, Workflow activities, and Script Includes when operating on a specific record. It allows you to get and set values on that record.

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

Answer: You use methods like setValue() and setDisplayValue():

current.setValue('field_name', value);: Use this to set the internal value. For reference fields, this value must be the sys_id of the referenced record.
current.setDisplayValue('field_name', value);: Use this to set the display value. For reference fields, you can pass the human-readable value (e.g., the username), and ServiceNow will attempt to find the correct sys_id. This is often more convenient but can be less performant or prone to ambiguity if multiple records share the same display value.

Example:


    // Setting a string field
    current.setValue('short_description', 'Resolved issue');

    // Setting a reference field using sys_id
    current.setValue('assigned_to', '62826bf03710200044e0bfc8be5d94');

    // Setting a reference field using display value (less reliable, use sys_id if possible)
    current.setDisplayValue('assignment_group', 'Network Operations');

28. Reference Qualifiers: Refining Selections

Reference qualifiers are powerful tools for filtering lookup lists.

Question: What are reference qualifiers, and what are their types? Explain each one in detail and the differences.

Answer: Reference Qualifiers are used to restrict the list of records that can be selected in a Reference or List type field. They act as filters, ensuring users only see relevant options.

There are three main types:

Simple Reference Qualifier:
Description: The most basic type. You define a fixed query string directly in the reference field’s dictionary entry. It uses standard ServiceNow query syntax (like you’d use in the Filter builder).
Example: To show only active users in a ‘User’ reference field, you’d set the qualifier to active=true.
How to Use: Go to the Dictionary entry for the field, and in the ‘Reference Qualifer’ field, enter your query string.
Pros: Easy to set up for static filtering.
Cons: Not dynamic; cannot adapt based on other form field values.
Dynamic Reference Qualifier:
Description: Uses a pre-defined “Dynamic Filter Option” to create a query. These options can be configured to be context-aware, potentially using variables or values from the current form.
Example: Displaying only users who belong to the same department as the caller of the incident.
How to Use:
1. Navigate to System Definition > Dynamic Filter Options.
2. Create a new dynamic filter option, defining the conditions.
3. In the reference field’s dictionary entry, select ‘Dynamic’ for the Reference Qualifier type and choose your created Dynamic Filter Option.
Pros: More flexible than Simple, can leverage some context.
Cons: Configuration can be spread across multiple places; complexity can grow.
Advanced Reference Qualifier (JavaScript Reference Qualifier):
Description: This is the most powerful type. It allows you to write custom JavaScript code directly in the reference field’s dictionary entry. This script runs on the client-side and dynamically constructs the query based on any logic you define, including values from other fields on the form.
Example: Displaying only active users who are also members of a specific group, or filtering based on dates or complex calculations.
How to Use: In the reference field’s dictionary entry, select ‘Advanced’ for the Reference Qualifier type and enter your JavaScript code. The code should return a query string.
```
            // Example JavaScript for Advanced Reference Qualifier
            // Show users from the same department as the caller, and active
            javascript: 'active=true^department=' + g_form.getValue('caller_id.department');
            
```
Pros: Extremely flexible, can handle complex logic and interact with other form fields dynamically.
Cons: Requires JavaScript knowledge; debugging can be more involved.

Simple vs. Dynamic: Simple is static. Dynamic uses predefined filter options that can sometimes pull context. Dynamic is a step up from Simple.

Dynamic vs. Advanced: Dynamic uses pre-built filter options. Advanced lets you write custom JavaScript, offering much more control and the ability to directly interact with client-side form elements like g_form.

Simple vs. Advanced: Simple is a fixed query string. Advanced is a JavaScript function that generates a query string, allowing for dynamic values and complex logic.

Interview Relevance: This is a very common interview question for ServiceNow developers, testing your understanding of data filtering.

29. Dependent Values: Cascading Dropdowns

Creating linked dropdowns is a frequent UI requirement.

Question: What is a dependent value?

Answer: Dependent values are a dictionary attribute that allows you to create cascading dropdown menus. When a user selects an option in a “parent” field, the choices available in a “dependent” field are automatically filtered to show only relevant options. This significantly improves usability by guiding users to make appropriate selections.

Example: A common scenario is Category and Subcategory. When you select ‘Hardware’ in the Category field, the Subcategory field should only show options like ‘Laptop’, ‘Printer’, ‘Monitor’. If you select ‘Software’, it should show ‘Operating System’, ‘Application’, etc.

How to Configure:

Ensure both the parent field (e.g., incident.category) and the dependent field (e.g., incident.subcategory) are Choice type fields.
Go to the Dictionary entry for the dependent field (Subcategory).
In the ‘Dependent Field’ attribute, enter the name of the parent field (e.g., category).
Define the choices for the dependent field. Each choice will have a ‘Parent value’ field, which you link to the corresponding value in the parent field’s choices.

30. Calculated Values: Fields Driven by Logic

Question: What is a calculated value?

Answer: A calculated value is a field whose value is not directly entered by the user but is instead computed based on other fields using a formula or script. This is configured within the field’s dictionary entry using the ‘Calculation’ attribute.

Example: You might have a ‘Total Cost’ field that automatically calculates the sum of ‘Quantity’ and ‘Unit Price’ fields.


    // Example Calculation script for a field
    // Calculates Total Cost based on Quantity and Unit Price
    current.u_total_cost = current.u_quantity * current.u_unit_price;

Note: This script runs server-side whenever the fields it depends on are updated.

31. Attributes: Modifying Field Behavior

Attributes provide granular control over field behavior beyond standard settings.

Question: What are attributes, and name some that you have used.

Answer: Attributes are directives placed in the ‘Attributes’ field of a dictionary entry (for fields or table collection entries) that modify the behavior or appearance of that field or table. They offer a concise way to apply specific functionalities.

Commonly Used Attributes:

no_email: Prevents this field from being included in email notifications.
no_attachment: Disables attachments for this specific field (often used on Journal fields if you don’t want attachments there).
no_add_me: Hides the “Add Me” button on list view searches.
tree_picker: Changes a reference field to display as a tree structure (useful for hierarchical data like CIs).
ref_auto_completer=true: Enables auto-completion for reference fields.
ref_ac_columns=sys_id,name: Specifies which columns to display in the auto-completion suggestions for a reference field.
is_boolean_field: Used for choice lists that represent boolean values.

32. Collection Fields and Table Attributes

Question: What is a collection field on a table?

Answer: A “collection field” isn’t a standard field type. Instead, the term often refers to the dictionary entry that represents the table itself (the “collection” of records). When you view the dictionary entries for a table, you’ll see one entry where the ‘Type’ is ‘Collection’. Any attributes or properties set on this ‘Collection’ entry apply to the table as a whole, rather than a specific field. For example, setting attributes like no_attachment on the collection field disables attachments for all records in that table.

Question: How to enable/disable attachments on the form using attributes?

Answer: To disable attachments for an entire table (and thus for all forms of that table), you would add the no_attachment attribute to the Collection Field’s dictionary entry. To enable attachments if they were previously disabled, you would remove this attribute.

33. Dictionary Overrides: Extending Parent Behavior

Question: What are dictionary overrides, and what properties can be overridden?

Answer: A Dictionary Override allows you to change the default attributes or behavior of a field that exists in a parent table when it’s used in a child table. This is crucial for making inherited fields behave differently based on the specific context of the child table.

Properties You Can Override: You can override almost any property defined in the original dictionary entry, including:

Mandatory: Make a field mandatory in the child table even if it’s optional in the parent.
Read only: Make a field read-only in the child table.
Default value: Set a different default value.
Max length: Change the maximum allowed characters for a string field.
Reference Specification: Modify reference qualifiers or the referenced table.
Display value: Change whether the field is a display value.
Help text: Update the help text.
Calculation: Provide a different calculation script.
Attributes: Add or remove attributes.

Example: The priority field might have a default value of 4 in the base task table. You can create a Dictionary Override for the incident table to set the default priority to 5, or make it mandatory.

Navigating and Organizing ServiceNow Applications

Making your applications accessible and understandable to users involves proper organization.

34. Application Menus and Modules

Question: What are application menus?

Answer: Application Menus (often referred to as “Modules” in the left navigation pane) are the primary way to make forms, lists, and other application components accessible to end-users within the ServiceNow UI. An Application Menu represents a top-level grouping (e.g., “Incident”, “Problem”, “Self-Service”), and within it, you can define individual modules (e.g., “Open”, “All”, “My Incidents”) that link to specific table lists or forms.

35. Process Flow: Visualizing Workflow

Question: What is process flow?

Answer: Process Flow (or Flow Designer, or formerly Workflow Editor) is a visual tool used to design and automate business processes. It provides a graphical representation of the steps involved in a workflow, allowing administrators to define conditions, actions, approvals, and notifications. It helps users understand the current stage of a record within a defined process and guides them through the required steps.

36. Data Lookups: Conditional Data Population

Question: What are data lookup rules?

Answer: Data Lookup Rules (found under System UI > Data Lookups) provide a way to automatically populate field values on a form based on matching values from other fields. Unlike simple default values, Data Lookups create a separate table that defines these mappings. When a record is saved, ServiceNow checks the Data Lookup table for matching criteria based on specified source fields and populates the target fields accordingly.

Example: If you select a specific ‘Location’ and ‘Department’, a Data Lookup could automatically populate the ‘Assignment Group’ field.

UI Policies vs. Data Policies

Both UI Policies and Data Policies control form behavior, but they operate differently.

37. Understanding UI Policies

Question: What are UI policies?

Answer: UI Policies are client-side scripts that run in the browser to dynamically change the behavior of form fields. They can make fields mandatory, read-only, visible/hidden, or set default values based on specific conditions. They are a more user-friendly, declarative alternative to client scripts for many common UI manipulations.

Question: What is the ‘global’ checkbox in UI policies?

Answer: 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 which specific views the UI Policy should apply to. This allows for view-specific form behavior.

Question: What is ‘Reverse if false’ in UI policies?

Answer: If the ‘Reverse if false’ checkbox is selected, the actions defined in the UI Policy will be reverted when the UI Policy’s condition evaluates to false. For example, if a field is made mandatory when a condition is true, and ‘Reverse if false’ is checked, that field will become optional again when the condition becomes false.

Question: What is the ‘On Load’ checkbox in UI policy?

Answer: When ‘On Load’ is checked, the UI Policy’s conditions and actions are executed as soon as the form loads. If it’s unchecked, the UI Policy actions only trigger in response to changes made to fields on the form after the initial load (e.g., when a user changes a value in a field that matches the condition).

Question: What is the ‘Inherit’ checkbox?

Answer: When the ‘Inherit’ checkbox is checked on a UI Policy, the policy will automatically be applied to any tables that extend the table on which the UI Policy is defined. This is useful for ensuring consistent behavior across a table hierarchy.

Question: Can you write script in a UI Policy?

Answer: Yes. To add custom scripting within a UI Policy, you need to enable the ‘Run scripts’ checkbox within the UI Policy Actions. This allows you to execute specific JavaScript code when the UI Policy conditions are met, providing more complex logic than declarative actions alone.

38. Converting UI Policies to Data Policies

Question: Can we convert a UI Policy as a Data Policy?

Answer: Yes, ServiceNow provides a convenient way to convert UI Policies into Data Policies. You can find a button or link within the UI Policy form, usually labeled something like “Convert to Data Policy” or “Convert this as Data Policy”.

Question: Which cases where a UI Policy cannot be converted as a Data Policy?

Answer: While most UI Policies can be converted, some scenarios involve functionalities that Data Policies don’t directly support. These include:

Controlling field visibility (UI Policies can hide fields; Data Policies primarily focus on mandatory/read-only).
Controlling views.
Controlling related lists.
Complex scripting that heavily relies on client-side DOM manipulation or specific client-side events not directly replicable server-side.

In these cases, you would need to keep the UI Policy or reimplement the logic using client scripts and/or server-side logic.

39. Understanding Data Policies

Question: What are Data Policies?

Answer: Data Policies are similar to UI Policies in that they can make fields mandatory, read-only, or control their visibility. However, Data Policies operate on both the client-side and the server-side. This means they enforce data consistency regardless of how the record is accessed or modified (e.g., through forms, integrations, emails, or background scripts). They are essential for maintaining data integrity across the entire platform.

Conclusion

Mastering the GlideForm API and related ServiceNow platform features is an ongoing journey. By understanding the concepts covered here—from user and group management to ITSM processes, table structures, and UI/data controls—you’re well on your way to becoming a proficient ServiceNow developer. Keep practicing, exploring, and always refer to the official ServiceNow documentation for the most up-to-date information. Happy coding!

Unlocking the Power of ServiceNow: Your Top GlideForm API Questions Answered

Getting Started: Foundations and Permissions

1. Your ServiceNow Version Journey

2. User and Group Permissions: Best Practices

3. Core Table Names: The Building Blocks

4. Programmatic User and Group Creation

5. Assigning Roles Programmatically

User Delegation and Group Management

6. Understanding User Delegation

7. Managing Group Memberships with Scripts

Client-Side vs. Server-Side Scripting

8. Accessing the Current User’s Sys ID

9. Checking Group Membership

Security and Impersonation

10. Roles for Access Control

11. What is Impersonation?

Incident, Problem, and Change Management: The Lifecycle

12. Defining Incident, Problem, and Change

13. Interconnecting ITSM Records

14. Scripting ITSM Record Creation

15. Automating ITSM Workflows with Business Rules

16. The ITSM Relationship Explained

ServiceNow Data Model and Architecture

17. Out-of-the-Box vs. Custom Tables

18. Base Tables and Table Extension

19. Table Creation and Access Controls (ACLs)

20. Field Types and Attributes

21. Table Relationships Explained

22. Table Types: Temporary vs. Normal

23. Remote Tables

Form Customization and Behavior Control

24. Creating Records in Multiple Ways

25. Controlling Field Behavior: Mandatory, Read-Only

26. Display Fields: A Unique Identifier

27. Default Values and Current Object

28. Reference Qualifiers: Refining Selections

Simple Reference Qualifier:

Dynamic Reference Qualifier:

Advanced Reference Qualifier (JavaScript Reference Qualifier):

29. Dependent Values: Cascading Dropdowns

30. Calculated Values: Fields Driven by Logic

31. Attributes: Modifying Field Behavior

32. Collection Fields and Table Attributes

33. Dictionary Overrides: Extending Parent Behavior

Navigating and Organizing ServiceNow Applications

34. Application Menus and Modules

35. Process Flow: Visualizing Workflow

36. Data Lookups: Conditional Data Population

UI Policies vs. Data Policies

37. Understanding UI Policies

38. Converting UI Policies to Data Policies

39. Understanding Data Policies

Conclusion