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

Answer: “I’m currently working on the Washington DC release. I always strive to stay updated with the latest innovations and best practices that ServiceNow introduces with each new version.”

2. From which version did you start working?

Answer: “My ServiceNow journey began with the Rome release. Since then, I’ve had the opportunity to work on San Diego, Tokyo, Utah, Vancouver, and now Washington DC. This progression has given me a solid understanding of how features and functionalities have evolved over time.”

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

Answer: “Absolutely, permissions are primarily managed through roles in ServiceNow. You can assign roles directly to users or to groups. The best practice is to assign roles to groups. When an employee joins, you add them to the relevant groups, and they inherit the roles. Conversely, when an employee leaves, removing them from the group automatically revokes their permissions. This significantly simplifies user lifecycle management and reduces administrative overhead.”

Scripting Example: While manual assignment is common, you can script this. For instance, to add a role to a group using GlideRecord:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.group = 'YOUR_GROUP_SYS_ID'; // e.g., '477a05d153013010b846ddeeff7b1225'
grpRole.role = 'YOUR_ROLE_SYS_ID';  // e.g., '2831a114c611228501d4ea6c309d626d'
grpRole.insert();
        

4. What is the user table name?

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

5. What is the group member table name?

Answer: The table that links users to groups is sys_user_grmember.

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

Answer: You can create user accounts programmatically using GlideRecord. Here’s a basic example:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstName = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.password = gs.generatePassword('Pa$$w0rd'); // Consider more secure password handling
userGr.insert();
        

7. How to create a group using a script?

Answer: Similar to user creation, you can create groups with GlideRecord:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'IT Support - Level 1';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the manager user
newGr.email = 'itsupportl1@example.com';
newGr.description = 'Handles initial IT support requests.';
newGr.insert();
        

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

Answer: Permissions (roles) are managed through specific tables. For users, it’s sys_user_has_role, and for groups, it’s sys_group_has_role.

To a User:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.user = 'USER_SYS_ID'; // e.g., '62826bf03710200044e0bfc8bcbe5df1'
userRole.role = 'ROLE_SYS_ID';   // e.g., '2831a114c611228501d4ea6c309d626d'
userRole.insert();
        

To a Group:

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();
        

9. What exactly does user delegation mean in ServiceNow?

Answer: User delegation allows one user to perform actions on behalf of another user. This is typically used when the primary user is unavailable, such as during vacation or leave. The delegated user gains the necessary permissions to handle tasks, approvals, or notifications that would normally be routed to the original user. It ensures business continuity without interruption. You configure this by navigating to the original user’s record, scrolling to the ‘Delegates’ related list, and specifying the delegate’s name, start/end dates, and the types of actions they can perform (assignments, notifications, approvals).”

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

Answer: Group membership is managed via the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = 'USER_SYS_ID';       // Sys ID of the user to add
grMem.group = 'GROUP_SYS_ID';     // Sys ID of the group
grMem.insert();
        

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'USER_SYS_ID');   // Sys ID of the user to remove
grMem.addQuery('group', 'GROUP_SYS_ID'); // Sys ID of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
        

11. How many user interfaces are there in ServiceNow?

Answer: ServiceNow has evolved its user interfaces over time. The main ones you’d encounter are UI15 (an older classic interface), UI16 (the more common classic interface before the Next Experience), and the modern Next Experience UI (also known as the “Polaris” UI or “Now Experience UI”).

12. What is meant by a web services user in ServiceNow?

Answer: A web services user is an account configured in ServiceNow specifically to allow external applications or systems to interact with ServiceNow via web services (like REST or SOAP). Crucially, these users cannot log in directly to the ServiceNow instance’s user interface. Their sole purpose is for programmatic data exchange and integration. They are typically assigned specific roles to limit their access to only what’s necessary for the integration.

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

Answer: On the client-side (e.g., within client scripts or UI policies), you can access the current user’s sys_id using the global variable g_user: g_user.userID;

Example:

var currentUserId = g_user.userID;
console.log('Current User Sys ID (Client-side): ' + currentUserId);
        

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

Answer: On the server-side (e.g., within business rules, script includes), you use the gs object: gs.getUserID();

Example:

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

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

Answer: On the server-side, you can use the gs.getUser() object’s isMemberOf() method:

var groupName = 'ITIL Users'; // Or the sys_id of the group
if (gs.getUser().isMemberOf(groupName)) {
    gs.info('User is a member of the ' + groupName + ' group.');
} else {
    gs.info('User is NOT a member of the ' + groupName + ' group.');
}
        

On the client-side, you can use g_user.isMemberOf('groupName').

16. 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.

17. What is impersonation?

Answer: Impersonation in ServiceNow is a powerful feature that allows administrators or users with appropriate roles (like admin or impersonator) to temporarily “act as” another user. This is invaluable for testing functionality, troubleshooting user-specific issues, or verifying that ACLs and UI policies are working correctly for different user roles without needing to log out and log back in with different credentials.

18. What is a user preference?

Answer: User preferences are individual settings that a user can configure to personalize their ServiceNow experience. These settings affect only the specific user and do not have a global impact. Examples include setting the list column layout, default form views, notification preferences, or homepage configurations. These are stored in the sys_user_preference table.

19. What is an Incident?

Answer: An Incident represents an unplanned interruption to an IT service or a reduction in the quality of an IT service. The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, ensuring that the best possible levels of service quality are maintained.

20. What is a Problem?

Answer: A Problem is an underlying cause of one or more Incidents. The goal of Problem Management is to identify the root cause of Incidents and then to minimize the recurrence of those Incidents. If the same issue repeatedly affects a single user, it might be logged as a Problem. If it affects multiple users simultaneously, it might start as multiple Incidents that are then linked to a single Problem record to investigate the root cause.

Relationship with Incidents: When multiple incidents share a common underlying cause, a Problem record is created. All related incidents are then linked to this Problem. Closing the Problem often involves implementing a change or workaround that resolves the root cause, which then allows all associated incidents to be closed.

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

Answer: Yes, absolutely. If during the resolution of an Incident, it becomes apparent that the issue is recurring or has a deeper root cause that needs investigation, you can create a Problem record directly from the Incident form. This is a crucial step in the Problem Management process to ensure underlying issues are addressed.

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

Answer: Yes, this is a common practice. If an Incident is caused by a faulty configuration, a missing feature, or a known issue that can be resolved by implementing a change in the IT environment, a Change Request can be raised from the Incident. This initiates the Change Management process to assess, plan, and implement the necessary change safely.

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

Answer: Using GlideRecord to create an Incident:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys ID of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the Configuration Item
gr.short_description = 'System is running slow.';
gr.description = 'User reports that their workstation is experiencing significant slowdowns, impacting productivity.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
        

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

Answer: Similar to Incident creation, using GlideRecord for a Problem record:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys ID of the reporter
gr.category = 'network';
gr.subcategory = 'connectivity';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the affected CI
gr.short_description = 'Intermittent network connectivity issues.';
gr.description = 'Multiple users reporting sporadic loss of network access, affecting access to critical applications.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
        

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

Answer: Using GlideRecord for a Change Request:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'standard'; // Or normal, emergency
gr.subcategory = 'software_update';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the CI to be changed
gr.short_description = 'Deploy security patch for Apache server.';
gr.description = 'Applying the latest security patch (CVE-XXXX-XXXX) to all production Apache web servers.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
        

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

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

Business Rule Configuration:

• Table: Incident
• When: after
• Update: checked
• Condition: current.state.changesTo(7) && current.parent == '' (Assuming state ‘7’ is ‘Closed’. Adjust if your state values differ.)

Script:

// This business rule runs after an incident is updated.
// It checks if the incident is closed (state 7) AND if it's a parent incident (no parent field populated).

if (current.state == 7 && current.parent == '') {
    // GlideRecord to find child incidents linked to this parent.
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Filter by the parent incident's sys_id
    grChild.query();

    while (grChild.next()) {
        // Ensure we only update if the child isn't already closed.
        if (grChild.state != 7) {
            grChild.state = 7; // Set the state to Closed
            grChild.update();  // Update the child incident record
        }
    }
}
        

27. There is an incident and that incident has associated 2 tasks. When you try to close that incident, if any incident task is open, the employee should not be able to close the incident. Similarly for Problem and Change Request.

Answer: This requires a Before Business Rule on the incident table (and similar rules for problem and change_request).

Business Rule Configuration (for Incident):

• Table: Incident
• When: before
• Update: checked
• Condition: current.state.changesTo(7) (Assuming state ‘7’ is ‘Closed’)

Script:

// This business rule runs before an incident is updated.
// It checks for open incident tasks before allowing the incident to be closed.

// Check for open incident tasks associated with this incident.
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
// Assuming state '3' represents 'Closed' for incident tasks. Adjust as needed.
grTask.addQuery('state', '!=', 3);
grTask.query();

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

// You would implement similar logic for Problem (checking problem_task) and Change Request (checking change_task).
        

28. Whenever a Problem is closed, the associated Incident will also get closed.

Answer: This is an After Business Rule on the problem table.

Business Rule Configuration:

• Table: Problem
• When: after
• Update: checked
• Condition: current.state.changesTo(7) (Assuming state ‘7’ is ‘Closed’)

Script:

// This business rule runs after a problem is updated.
// It closes associated incidents if the problem is closed.

if (current.state == 7) { // If the problem state is now Closed
    // GlideRecord to find incidents associated with this problem.
    var grIncident = new GlideRecord('incident');
    // Assuming 'problem_id' is the field linking incidents to problems.
    grIncident.addQuery('problem_id', current.sys_id);
    // Ensure we only close incidents that are not already closed.
    grIncident.addQuery('state', '!=', 7); // Assuming state '7' is 'Closed'
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the incident state to Closed
        grIncident.update();  // Update the incident
    }
}
        

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

Answer: These three ITIL processes are closely intertwined:

• Incident Management: Focuses on restoring normal service operation as quickly as possible. When users report an issue, an Incident is logged.
• Problem Management: Investigates the root cause of Incidents. If an Incident is recurring, or if multiple Incidents share a common cause, a Problem record is created to identify and resolve the underlying issue.
• Change Management: Manages the lifecycle of all changes to the IT infrastructure. If the resolution to a Problem (or sometimes an Incident) requires modifying the IT environment (e.g., deploying a patch, reconfiguring a server), a Change Request is initiated.

In essence, Incidents are disruptions, Problems are their underlying causes, and Changes are the actions taken to fix those causes and prevent future Incidents.

30. Give me some names of Out-of-the-Box (OOTB) tables?

Answer: Out-of-the-Box (OOTB) tables are those provided by ServiceNow itself, not created by customizations. They typically do not start with x_ or u_ prefixes. Examples include:

• incident
• problem
• change_request
• sc_req_item (Service Catalog Request Item)
• sys_user
• sys_group
• cmdb_ci (Configuration Item base table)
• task (A very common base table)
• sys_audit (for audit trails)

31. What are some of the base tables?

Answer: Base tables in ServiceNow are tables that are not extended by any other table but are extended by many other tables. They form the foundation of hierarchies. Key examples include:

• task: The fundamental base table for all task-based records like Incidents, Problems, Changes, Requested Items, etc.
• cmdb_ci: The base table for Configuration Items in the CMDB. All specific CI classes (like Servers, Applications, Databases) extend from this.
• sys_security_role: The base for all roles.

32. Give me some examples of Task tables?

Answer: Task tables are tables that extend the task base table. They represent work items that need to be performed. Common examples include:

• incident
• problem
• change_request
• sc_task (Catalog Task)
• ப்படுகின்றன (Help Desk Task – older, less common now)
• request_item (often has related catalog tasks)

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

Answer: By default, when you create a new table and the “Create application access” checkbox is selected, ServiceNow automatically generates four Access Control Lists (ACLs):

• A create ACL
• A read ACL
• An update ACL
• A delete ACL

These ACLs grant the admin role full access to the new table. If you uncheck this box during table creation, no default ACLs are generated, and you’ll need to create them manually.

34. How to create a number field, like Incident Number?

Answer: For fields that need auto-generated, sequential numbering like INC0001000, you don’t create a regular “Number” field type. Instead, this behavior is configured at the table level. When defining the table properties (System Definition > Tables), there’s an option to enable “Auto number”. You then configure the prefix (e.g., “INC”) and the number of digits (e.g., 7 for 0000001). ServiceNow automatically manages this sequence for records inserted into that table.

35. What happens when you extend a table?

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

• Inheritance of Fields: All fields from the parent table are automatically available in the child table. You don’t need to recreate them.
• No Sys Fields in Child: System fields like sys_created_by, sys_updated_on, etc., are not duplicated in the child table. They reside in the parent table and are inherited.
• ‘Class’ Field in Parent: A field named class is added to the parent table. This field stores the sys_id of the actual table the record belongs to. For example, a record in the incident table would have its class field pointing to the sys_id of the incident table itself.
• Single Class Field: Even if a table extends multiple tables (though direct multiple inheritance isn’t standard, think of a chain), there’s only one class field in the top-level parent, which points to the most specific child.

36. Can you give me 10 field types?

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

1. String: For text input (e.g., short description).
2. Reference: To link to another record in a different table (e.g., caller_id in Incident referencing sys_user).
3. List: Allows selecting multiple records from another table (e.g., groups a user belongs to).
4. Choice: A dropdown list of predefined options (e.g., state, priority).
5. Date/Time: For storing date and time values.
6. Date: For storing date values only.
7. Boolean: For true/false values (e.g., active, on_hold).
8. Integer: For whole numbers.
9. Journal: For free-form text input, often with a history (e.g., work notes, comments).
10. Attachment: Allows users to attach files to a record.

Other important ones include HTML, URL, Currency, Email, etc.

37. What is the difference between a Temporary and Normal table?

Answer:

• Normal Tables: These are your standard ServiceNow tables (like incident, sys_user). Data stored in these tables persists permanently until explicitly deleted or archived. They are the backbone of your instance’s data.
• Temporary Tables: These tables are designed for short-term data storage. Data in temporary tables typically has a limited retention period (often 7 days by default) and is automatically purged afterwards. They often extend the import_set_row table or similar structures and are commonly used for staging data during import processes or for temporary processing needs.

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

Answer: Yes, you can. While temporary tables often have a default retention period, you can often configure or extend this using Archive Rules. You can set up archive rules to retain data in these tables for longer periods if business requirements dictate, although this deviates from their “temporary” nature and should be done with consideration for storage and performance.

39. What is the difference between a Remote table and Normal tables?

Answer:

• Normal Tables: These tables store data directly within your ServiceNow instance’s database. When you query them, you are retrieving data that resides locally.
• Remote Tables: These tables act as proxies or connectors to data residing in an external system or database. When you query a remote table, ServiceNow fetches the data in real-time from that external source. This is often achieved through integrations like IntegrationHub or by defining tables that point to external data sources.

40. What is a one-to-one and one-to-many table relationship in ServiceNow?

Answer:

• One-to-Many Relationship: This is the most common type. 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) assigned to them. Each Incident is assigned to one User. (incident.caller_id is a reference to sys_user).
• Many-to-Many Relationship: This occurs when multiple records in Table A can be associated with multiple records in Table B, and vice versa. This is typically implemented using a “junction table”.
  • Example: Incidents (Table A) and Groups (Table B). An Incident can be assigned to multiple groups, and a Group can be assigned to multiple Incidents. The junction table might be incident_group (or similar, conceptually). ServiceNow often uses tables like sys_user_group and the assignment_group field on task tables to achieve this for assignment scenarios. Another classic example is users and groups: a user can be in many groups, and a group can have many users (managed by sys_user_grmember).

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

Answer: There are several ways to create records:

1. Forms: The most common method, using the standard ServiceNow form interface.
2. Record Producers: User-friendly forms, often presented on portals, that generate records in tables (e.g., submitting a “Request IT Support” form creates an Incident).
3. Scripts (GlideRecord): Programmatic creation using server-side JavaScript (as shown in previous examples).
4. Email: ServiceNow can be configured to create records (like Incidents or Requests) from incoming emails.
5. Import Sets/Data Import: Importing data from spreadsheets (CSV, Excel) or other files.
6. Web Services (REST/SOAP): Creating records via API calls from external systems.
7. Scheduled Jobs: Scripts running on a schedule to create records.

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

Answer: You can achieve mandatory or read-only field behavior in several ways:

1. Dictionary Properties: Directly on the field’s dictionary entry, you can set ‘Mandatory’ and ‘Read only’ checkboxes. This is the most basic level.
2. Dictionary Overrides: To change the behavior of a field in a child table from its parent table definition.
3. UI Policies: Client-side logic that makes fields mandatory, read-only, visible, or hidden based on conditions when a form loads or when field values change.
4. Data Policies: Similar to UI Policies but work on both client-side and server-side, ensuring data integrity regardless of the entry method.
5. Client Scripts (g_form API): Using g_form.setMandatory('field_name', true/false); or g_form.setReadOnly('field_name', true/false); for dynamic client-side control.
6. Business Rules: Server-side scripts can set fields as read-only or even prevent record submission if certain conditions aren’t met (though Data Policies are often preferred for data integrity).

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

Answer: No, you should not. By convention and best practice, only one field in a table should be marked as the ‘Display’ field. This field is used in reference fields on other tables to show a meaningful value (e.g., the name field in sys_user is the display field). If multiple fields were marked as display, it would lead to ambiguity and confusion when selecting records from reference fields.

44. All tables will be stored where?

Answer: All table definitions in ServiceNow are stored in the sys_db_object table.

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

Answer: You can set default values for fields in a few ways:

• Dictionary Entry: The most common method. In the field’s dictionary entry, there’s a “Default value” field where you can enter a static value (e.g., ‘In Progress’ for a State field) or a simple script (e.g., javascript: gs.getUser().getFirstName();).
• UI Policies: You can configure a UI Policy Action to set a default value for a field when certain conditions are met.
• Client Scripts: Using g_form.setValue('field_name', 'default_value'); in an OnLoad client script.
• Business Rules: In a “before insert” business rule, you can set default values using current.field_name = 'default_value';.

46. What is the ‘current’ object?

Answer: The current object is a server-side JavaScript object that represents the record being processed in the current operation. It’s available in business rules, script includes (when invoked with a record context), and other server-side scripts. You use it to get and set values of fields on that specific record.

47. How to set field values on the ‘current’ object?

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

• current.setValue('field_name', value);: This method sets the *internal* value of a field. For reference fields, you must provide the sys_id of the referenced record. For choice lists, you provide the choice value.
• current.setDisplayValue('field_name', display_value);: This method sets the field’s value using its *display value*. For reference fields, you can pass the actual name or other identifiable string. ServiceNow will try to find the corresponding sys_id. This is often more convenient but can be less performant or lead to ambiguity if display values aren’t unique.

Example:

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

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

// Setting a reference field using display value (less common in server-side scripts)
// current.setDisplayValue('assigned_to', 'Abel Tutor');
        

48. What are Reference Qualifiers, and their types? Explain each one in detail and what is the difference between simple and dynamic, dynamic and advanced, simple and advanced.

Answer: Reference Qualifiers are powerful tools used to filter the list of records that can be selected in a Reference or List type field. They ensure users select only relevant data.

There are three primary types:

1. Simple Reference Qualifier

Description: This is the most straightforward type, using basic query conditions directly in the reference field’s dictionary entry. It’s ideal for static filtering.

How to Use: You enter conditions similar to those used in GlideRecord queries.

Example: To show only active users in a caller_id field:

active=true
        

Example: To show only users in the ‘IT’ department:

department=IT
        

2. Dynamic Reference Qualifier

Description: This type uses a pre-configured “Dynamic Filter Option” (DFO). DFOs allow you to define filter logic that can adapt based on the context of the form or the user. They provide more flexibility than simple qualifiers without requiring custom code.

How to Use:

1. Navigate to System Definition > Dynamic Filter Options.
2. Create a new DFO, defining your filter logic (e.g., “Active Users”, “Users in My Department”).
3. In the reference field’s dictionary entry, select “Dynamic” for the Reference Qualifier type and choose your created DFO.

Example: A DFO might filter users to show only those whose location matches the location of the current incident.

3. Advanced Reference Qualifier (JavaScript)

Description: This is the most powerful and flexible type. It allows you to write custom JavaScript code to dynamically build the filter query. This is used for complex filtering scenarios that cannot be achieved with simple or dynamic qualifiers.

How to Use:

1. In the reference field’s dictionary entry, select “Advanced” for the Reference Qualifier type.
2. Enter your JavaScript code in the “JavaScript Condition” field. This script should return a query string.

Example: To show only users who are members of the same assignment group as the current incident, and have a priority less than 3:

javascript:
var currentUserSysId = gs.getUserID();
var incidentSysId = current.sys_id; // Assuming this script runs in context of an incident

if (incidentSysId) {
    var incRec = new GlideRecord('incident');
    if (incRec.get(incidentSysId)) {
        var assignmentGroupId = incRec.assignment_group;
        return 'sys_idIN' + getGroupMembers(assignmentGroupId) + '^active=true'; // Simplified example
    }
}
return 'active=true'; // Fallback if no incident context

function getGroupMembers(groupId) {
    var members = [];
    var grMem = new GlideRecord('sys_user_grmember');
    grMem.addQuery('group', groupId);
    grMem.query();
    while (grMem.next()) {
        members.push(grMem.user.toString());
    }
    return members.join(',');
}
        

Simplified Example:

javascript: 'assignment_group=' + current.assignment_group + '^priority<3';
        

Differences:

• Simple vs. Dynamic: Simple is static query string; Dynamic uses pre-configured DFOs that can be more reusable and context-aware.
• Dynamic vs. Advanced: Dynamic uses DFOs for common contextual filtering. Advanced uses custom JavaScript for complete control and complex logic not achievable with DFOs.
• Simple vs. Advanced: Simple is for basic, static queries. Advanced uses JavaScript for dynamic, complex logic that can query other tables, use user context, and perform intricate calculations.

49. What is a Dependent Value?

Answer: Dependent values, often referred to as dependent fields or cascading dropdowns, are used to filter the available choices in one field (the dependent field) based on the selection made in another field (the parent field). This creates a hierarchical selection process.

Example:

1. Parent Field: Category (e.g., Hardware, Software, Network)
2. Dependent Field: Subcategory (dependent on Category)

If the user selects ‘Hardware’ in Category, the Subcategory dropdown might show options like ‘Laptop’, ‘Desktop’, ‘Printer’. If they select ‘Software’, it might show ‘Operating System’, ‘Application’, ‘Database’.

How to Configure:

1. Ensure the parent field has its choices defined.
2. Go to the dictionary entry of the dependent field (e.g., Subcategory).
3. In the Attributes field, add dependent=parent_field_name (e.g., dependent=category).
4. Crucially, in the Choice List Specification for the dependent field, you define choices and link them to specific parent field values using the “Dependent value” column.

50. What is a Calculated Value?

Answer: A calculated value refers to a field whose value is not entered directly by the user but is determined by a calculation or script. This is typically achieved through one of the following methods:

• Dictionary Entry (Default Value): As mentioned before, the “Default value” field in a dictionary entry can contain a script that calculates the initial value when a record is created.
• Calculated Fields (Dictionary Type): ServiceNow has a specific field type called “Calculated” (though often implemented via scripts). When you select a field type as “Calculated”, you provide a script in the “Calculated value” field that computes the value for that field based on other fields in the same record or related records. This calculation happens server-side.
• Business Rules: A “before insert” or “before update” business rule can calculate and set field values.

51. What are Attributes, and name some attributes you have used?

Answer: Attributes are special parameters added to dictionary entries (fields) or collection entries (tables) that modify the behavior or appearance of those elements. They are essentially configuration directives.

Common Attributes I’ve Used:

• ref_ac_columns: Controls which columns are displayed in the reference field’s lookup list.
• ref_ac_columns_search: Specifies which columns in the reference lookup should be searchable.
• no_email: Prevents email notifications from being sent for changes to this field.
• no_attachment: Disables attachments for this specific field (though typically done at the table level).
• tree_picker: Used for reference fields to display a hierarchical tree view instead of a flat list.
• dependent=field_name: Used in choice lists to create dependent dropdowns (as discussed in Dependent Values).
• max_length=N: Sets a maximum character limit for a string field.
• read_only: Makes the field read-only (though often handled by UI/Data policies or dictionary entries directly).

52. What is a Collection field on a table?

Answer: A “Collection” entry in the dictionary (found in sys_dictionary) doesn’t represent a field on a table; it represents the table itself. When you go to define a table (System Definition > Tables), the system automatically creates a dictionary entry for the table itself. Changes made to this collection entry, like adding attributes or setting read-only properties at the table level, apply to the entire table, not just one field.

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

Answer: To disable attachments for an entire form (table), you would typically add the no_attachment attribute to the collection entry for that table in the dictionary. This attribute prevents the attachment icon and functionality from appearing on any records of that table.

Example: In the dictionary entry for the incident table (the collection entry), you would add no_attachment to the Attributes field.

54. What are Dictionary Overrides, and what properties can we override?

Answer: A Dictionary Override allows you to modify the definition of a field that is inherited from a parent table. This is essential when you need a field to behave differently in a child table than it does in its parent. You override properties on a field-by-field basis for a specific child table.

Properties You Can Override:

• Default value
• Mandatory flag
• Read only flag
• Max length
• Display value flag
• Reference qualifier
• Attributes
• Label (though often changed via Dictionary Overrides on the child table itself if it’s a direct field there)
• And others…

Example: The priority field might have a default value of ‘4’ in the base task table. In the incident table (a child of task), you can create a dictionary override for the priority field to set its default value to ‘5’ or make it mandatory.

55. What are Application Menus?

Answer: Application Menus (also known as Modules) are the entries that appear in the left-hand navigation filter navigator in ServiceNow. They provide users with quick access to specific forms, lists, reports, or other functionalities within an application (like Incident, Problem, Change, or custom applications). When you create an Application Menu, you define its title, order, and link it to a specific URL or list view.

56. What is a Process Flow?

Answer: A Process Flow is a visual representation that shows the progression of a record through different stages or states. It typically appears at the top of a form and highlights the current step the user is on. For example, on an Incident form, it might show stages like “New”, “In Progress”, “On Hold”, “Resolved”, “Closed”. Process Flows help users understand where they are in a workflow and what the next steps are.

57. What are Data Lookup Rules?

Answer: Data Lookup Rules (found under System Policy > Rules > Data Lookup Rules) are used to automatically populate field values on a form based on selections made in other fields on the same form. They are essentially a simplified way to create dynamic field population without extensive scripting, often used for mapping selections to specific values. They are stored in the sys_data_lookup table.

58. What are UI Policies?

Answer: UI Policies are client-side scripts that dynamically change form behavior. They are used to make fields mandatory, read-only, visible, or hidden, and can also control related lists, based on specific conditions evaluated when a form loads or when field values change. They provide a more user-friendly and interactive form experience without requiring users to refresh the page.

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

Answer: The ‘Global’ checkbox in a UI Policy determines whether the UI Policy applies to all views or only specific views. When checked, the UI Policy’s actions will execute on any view of the table. If unchecked, you will need to specify the view(s) in the ‘View name’ field, meaning the UI Policy will only apply to those specific views.

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

Answer: The ‘Reverse if False’ checkbox in a UI Policy Action is crucial. When checked, if the condition defined in the UI Policy evaluates to false, the actions configured for that UI Policy Action will be reversed. For instance, if an action makes a field mandatory when the condition is true, checking ‘Reverse if False’ means that field will become optional again when the condition becomes false.

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

Answer: The ‘On Load’ checkbox in a UI Policy determines whether the UI Policy’s conditions and actions are evaluated and applied immediately when the form is first loaded.

• Checked: The UI Policy runs as soon as the form loads.
• Unchecked: The UI Policy will not run on load. Its actions will only be triggered when a specific event occurs, such as a field value change that matches the UI Policy’s conditions.

62. What is the ‘Inherit’ checkbox?

Answer: The ‘Inherit’ checkbox in a UI Policy (or Data Policy) determines whether the UI Policy will be applied to child tables that extend the table the UI Policy is defined on.

• Checked: The UI Policy and its actions will automatically apply to any tables that inherit from this table (e.g., if a UI Policy is on the ‘task’ table and ‘Inherit’ is checked, it will also affect ‘incident’, ‘problem’, ‘change_request’, etc.).
• Unchecked: The UI Policy will only apply to the table it is defined on.

63. Can you write a script in a UI Policy?

Answer: Yes, you can. Within a UI Policy, you can define UI Policy Actions. For each UI Policy Action, there’s a “Run scripts” checkbox. If you enable this, you can write custom client-side JavaScript code that will execute when the UI Policy’s conditions are met and the specific UI Policy Action is triggered. This allows for more complex client-side manipulations beyond simple field visibility or mandatory settings.

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

Answer: Yes, you can convert a UI Policy into a Data Policy. If you have a UI Policy that enforces mandatory fields or read-only settings on the client-side, you can convert it to a Data Policy to ensure these rules are also enforced server-side. This is done by opening the UI Policy record and clicking a button or link that says “Convert this to a Data Policy”.

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

Answer: While many UI Policies can be converted, some actions or functionalities are inherently client-side and cannot be directly translated into a Data Policy:

• Controlling Data Visibility (Show/Hide Fields): Data Policies enforce data integrity; they don’t control what the user *sees* on a form. Showing or hiding fields is a UI concern.
• Controlling Views: Changing the form view is a client-side UI action.
• Controlling Related Lists: Manipulating related lists on a form is a UI behavior.
• Executing Client Scripts Directly: While Data Policies can trigger client scripts (via UI Policies converted to Data Policies), the direct manipulation of UI elements like field visibility is not their domain.

66. What are Data Policies?

Answer: Data Policies are a server-side (and can also run client-side) mechanism for enforcing data integrity and consistency. They define rules to make fields mandatory, read-only, or visible based on specified conditions, regardless of how the record is accessed or updated (form, import, API, etc.). This ensures data quality at its source.