Top 50 ServiceNow Scripting Interview Questions & Answers for 2024

By /






Top 50 ServiceNow Scripting Interview Questions & Answers


Mastering ServiceNow Scripting: Your Ultimate Interview Prep Guide (Top 50 Questions)

So, you’re gearing up for a ServiceNow scripting interview? Fantastic! This is where you get to shine and demonstrate your ability to leverage the platform’s power through code. ServiceNow scripting is the engine that drives automation, custom workflows, and intelligent solutions. Understanding these concepts isn’t just about passing an interview; it’s about becoming a more effective ServiceNow developer.

I’ve compiled a comprehensive list of the top 50 ServiceNow scripting interview questions, drawing from real-world scenarios and common interview topics. I’ll walk you through each question, not just with a correct answer, but with explanations that provide context, best practices, and even a touch of troubleshooting. Let’s dive in and make sure you’re interview-ready!

Pro Tip: When answering, don’t just recite the answer. Explain the ‘why’ and ‘how’. Relate it to your experience, and don’t be afraid to mention alternative approaches or potential challenges.

Current ServiceNow Version: Washington DC – the latest and greatest!

My Journey Started With: Rome, San Diego, Tokyo, Utah, Vancouver, and now Washington DC. It’s been a fantastic evolution!

I. Core Concepts & User Management

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

Answer: Absolutely! Permissions in ServiceNow are primarily managed through roles. You can assign roles to individual users directly, or more commonly and effectively, to groups.

Best Practice: Assigning roles to groups is the recommended approach. Why? Because when an employee joins or leaves your organization, you manage their access by simply adding or removing them from the relevant groups. This significantly reduces administrative overhead and minimizes the risk of orphaned permissions or security gaps. It’s all about scalability and maintainability!

2. What is the user table name?

Answer: The core user information resides in the sys_user table.

3. What is the group member table name?

Answer: To link users to groups, we use the sys_user_grmember table. This table acts as the bridge, establishing the many-to-many relationship between users and groups.

4. How to create a user account using script?

Answer: You can create user accounts programmatically using GlideRecord. Here’s a common way to do it:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Note: field name is 'first_name'
userGr.last_name = 'Doe';   // Note: field name is 'last_name'
userGr.email = 'jdoe@example.com';
userGr.password = gs.generatePassword(); // Best practice to generate a secure password
userGr.insert();

Troubleshooting: Always ensure you’re using the correct field names (e.g., first_name, last_name instead of firstname, lastName). You can find these by inspecting the ‘sys_user’ table dictionary entry. Also, consider setting a password, as it’s a security requirement.

5. How to create a group using script?

Answer: Similar to user creation, GlideRecord is your go-to tool for creating groups:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group';
newGr.manager = '62826bf03710200044e05d94'; // Replace with a valid sys_id of a user
newGr.email = 'testing@example.com';
newGr.description = 'A group for testing purposes';
newGr.insert();

The manager field expects the sys_id of a user. Ensure this sys_id is valid.

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

Answer: Permissions are managed by linking roles to users or groups.

For Users: A record is created in the sys_user_has_role table.

var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', '62826bf03710200044e05d94'); // sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
userRole.insert();

For Groups: A record is created in the sys_group_has_role table.

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
grpRole.insert();

Interview Relevance: Demonstrating knowledge of these underlying tables shows a deeper understanding of ServiceNow’s data model.

7. What exactly does user delegation mean in ServiceNow?

Answer: User delegation in ServiceNow allows one user to perform actions and manage tasks on behalf of another user. This is incredibly useful for scenarios where a user is on leave, on vacation, or otherwise unavailable. The delegated user gains the necessary permissions to handle tasks, respond to notifications, and even process approvals as if they were the original user.

Think of it as granting temporary power of attorney within the platform. For instance, if a manager is out of office, they can delegate their approval tasks to their assistant. This ensures that critical workflows continue uninterrupted. You configure this by navigating to the original user’s record, scrolling down to the ‘Delegates’ related list, and specifying the delegate, start/end dates, and the specific permissions (assignments, notifications, approvals) they can have.

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

Answer: Again, GlideRecord on the sys_user_grmember table is the way to go.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e05d94'; // sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
grMem.insert();

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e05d94'); // sys_id of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord(); // Use deleteRecord() to remove the specific record
}

Troubleshooting: Ensure you’re querying for the correct user and group combination before attempting deletion. If the record doesn’t exist, grMem.next() will be false, and deleteRecord() won’t be called.

9. How many user interfaces are there in ServiceNow?

Answer: Historically, ServiceNow has evolved through several user interfaces:

  • UI15 (Older, classic UI)
  • UI16 (The widely adopted, modern UI)
  • Next Experience UI (The latest, most advanced UI, often referred to as the “Now Experience” or “Polaris” UI, introduced in recent versions like Vancouver and Washington DC)

While UI16 is still prevalent, the Next Experience UI is the direction the platform is moving towards, offering a more streamlined and intuitive user experience.

10. What is a web services user in the User account?

Answer: A web services user is an account specifically designed to allow third-party applications or integrations to connect to ServiceNow programmatically. Crucially, these users do not have the ability to log in to the ServiceNow graphical user interface (GUI). Their purpose is solely for API-driven interactions.

This is a vital security measure. Instead of using a regular user account with full GUI access for integrations, you create a dedicated web services user with only the necessary permissions for API calls, minimizing the attack surface.

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

Answer: On the client-side (e.g., in Client Scripts or UI Policies), you can access the current user’s sys_id using the g_user object:

var currentUserID = g_user.userID; // This will be a string like '6816f79cc0a8016401c5a33be04be441'

This is extremely useful when you need to perform actions based on who is currently logged in, like pre-filling fields or dynamically adjusting UI elements.

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

Answer: On the server-side (e.g., in Business Rules, Script Includes, or Workflow scripts), you use the gs (GlideSystem) object:

var currentUserID = gs.getUserID(); // Returns the sys_id of the current logged-in user

This is the equivalent of g_user.userID but for server-side scripting.

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

Answer: Again, the gs object on the server-side comes to the rescue:

var groupName = 'ITIL Users'; // Or the sys_id of the group
var isMember = gs.getUser().isMemberOf(groupName); // Returns true if the user is a member, false otherwise

// You can also use the sys_id of the group:
var groupSysID = 'a715cd759f2002002920bde8132e7018';
var isMemberBySysID = gs.getUser().isMemberOf(groupSysID);

This is a fundamental check for controlling access or triggering logic based on group membership.

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

Answer: To create, modify, or manage ACLs, you need the security_admin role.

This is a highly privileged role, and it’s crucial to manage its assignment carefully. ACLs define the security model of your ServiceNow instance, so only authorized personnel should have the ability to alter them.

15. What is impersonation?

Answer: Impersonation is a powerful feature that allows an administrator (typically with the admin role) to temporarily log in as another user. This is invaluable for testing and troubleshooting, as it allows you to see exactly what another user sees and experiences within the platform.

By impersonating a user, you can verify if their roles and permissions are correctly configured, test workflows from their perspective, and diagnose issues that might only occur for specific users. It’s a critical tool for ensuring a smooth user experience.

16. What are user preferences?

Answer: User preferences are user-specific settings that allow individuals to customize their ServiceNow experience. These are settings that only affect the individual user and don’t have a global impact across the instance.

Examples include: the default view for lists, how many records are displayed per page, or even the theme of their UI. Users can typically manage their preferences through their profile settings. This empowers users to tailor the platform to their working style.

II. Incident, Problem, and Change Management (ITSM Fundamentals)

17. What is an incident?

Answer: An incident is defined as an unplanned interruption to an IT service or a reduction in the quality of an IT service. When an employee encounters an issue that prevents them from performing their work, they typically report it as an incident. The primary goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations.

Think of it as a broken car – you need to get it fixed to resume your journey. The incident record tracks the problem, its impact, and the steps taken to resolve it.

18. What is a problem?

Answer: A problem is the underlying cause of one or more incidents. While an incident focuses on restoring service, a problem focuses on identifying the root cause of recurring incidents and preventing them from happening again. If the same issue keeps popping up for an employee, or if multiple employees report similar incidents, it’s a strong indicator of an underlying problem.

If the same issue affects multiple people simultaneously, it might be logged as a major incident, with a parent incident and several child incidents. Addressing the root cause through problem management prevents future incidents. It’s like finding out why the car keeps breaking down and fixing the fundamental issue, not just patching it up each time.

19. Can we create a problem record from an incident?

Answer: Yes, absolutely! This is a core part of ITIL best practices. If a support engineer investigates an incident and realizes it might be a symptom of a recurring issue, they can create a related problem record directly from the incident. This helps in documenting the root cause analysis and implementing a permanent fix.

Interview Relevance: This shows you understand the lifecycle of ITSM processes and how they interrelate.

20. Can we create a change request from an incident?

Answer: Yes, this is also a standard practice. If resolving an incident requires a modification to the IT infrastructure or software (e.g., applying a patch, updating a configuration), a change request can be initiated from the incident. This ensures that any necessary changes are properly planned, approved, and implemented following a defined change management process.

21. How to create an incident record using script?

Answer: Using GlideRecord on the incident table:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e05d94'; // sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of a CI
gr.short_description = 'Test record created via script';
gr.description = 'Detailed description of the test incident';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();

Remember to replace the placeholder sys_id values with actual valid IDs from your instance.

22. How to create a problem record using script?

Answer: Similar to incidents, using GlideRecord on the problem table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e05d94'; // sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of a CI
gr.short_description = 'Test problem record created via script';
gr.description = 'Detailed description of the test problem';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();

23. How to create a change request using script?

Answer: Using GlideRecord on the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of a CI
gr.short_description = 'Test change request created via script';
gr.description = 'Detailed description of the test change request';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();

Change requests often have more complex fields like ‘type’, ‘risk’, ‘impact’, ‘assignment group’, etc., that you might want to populate.

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

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

// Business Rule: Auto-close child incidents
// Table: Incident
// When: After
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

if (current.state == 7 && current.parent == '') { // Check if it's being closed and it's not already a child

    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();

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

Troubleshooting: Ensure the ‘state’ value for ‘Closed’ is correct in your instance. Also, the condition `current.parent == ”` prevents an infinite loop if child incidents are also being closed automatically.

25. There is an incident with associated incident tasks. When closing the incident, if any incident task is open, the user 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.

// Business Rule: Prevent closing incident with open tasks
// Table: Incident
// When: Before
// Insert: false
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is '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 incident tasks.');
    current.setAbortAction(true); // This stops the update operation
}

You would implement similar logic for problem (checking problem_task) and change_request (checking change_task) using Before Business Rules on their respective tables.

26. Whenever a problem is closed, the associated incidents will also get closed.

Answer: This also calls for an After Business Rule on the problem table.

// Business Rule: Auto-close associated incidents
// Table: Problem
// When: After
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

if (current.state == 7) { // Check if the problem is closed

    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link incidents to the problem
    grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed'
    grIncident.query();

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

Ensure your incidents are correctly linked to the problem using the problem_id field.

27. What is the relationship between incident, problem, and change management?

Answer: They form a crucial part of the IT Service Management (ITSM) framework:

  • Incident Management: Focuses on restoring normal service operation as quickly as possible. When a user reports an issue, it’s logged as an incident.
  • Problem Management: Investigates the root cause of recurring or significant incidents. Its goal is to prevent future incidents by finding and fixing the underlying problem.
  • Change Management: Controls the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. Changes are often implemented to fix problems or prevent future incidents.

The typical flow is: an incident occurs -> if it’s recurring or significant, it leads to a problem investigation -> the solution to the problem might involve a change to the system. So, incidents are about service restoration, problems are about root cause, and changes are about controlled modifications.

III. ServiceNow Data Model & Tables

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

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

  • incident
  • problem
  • change_request
  • sys_user
  • sys_user_group
  • task
  • cmdb_ci
  • sys_audit
  • sys_attachment
  • sys_documentation

Understanding OOTB tables is fundamental as most customizations build upon them.

29. What are some of the base tables?

Answer: Base tables are foundational tables in ServiceNow that don’t extend any other table themselves but are extended by many other tables. They often represent core entities or common structures. Key examples include:

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

When you extend a base table, you inherit its fields and structure.

30. Give me some examples of task tables.

Answer: As mentioned, these tables extend the task table. This inheritance allows them to share common fields like number, state, assigned_to, assignment_group, short_description, description, etc. Some common examples are:

  • incident
  • problem
  • change_request
  • sc_task (Service Catalog Task)
  • ப்படுகின்றன (Knowledge Article) – though it has its own specific lineage, it shares many task-like characteristics.
  • approval_group

31. Whenever we create a table, how many access controls (ACLs) are created by default?

Answer: When you create a new table and check the “Create ACLs” checkbox (which is usually checked by default), ServiceNow automatically generates four ACLs:

  • read: Allows users to read records.
  • write: Allows users to update records.
  • create: Allows users to create new records.
  • delete: Allows users to delete records.

These are basic, default ACLs, typically assigned to roles like admin and potentially itil. You will almost always need to customize these to implement proper role-based access control.

32. How to create a number field, like incident number?

Answer: For fields that need to be auto-generated sequential numbers (like INC0010001), you configure this at the table level, not on a specific field. When defining or editing a table:

  1. Go to the Control tab of the table definition.
  2. Check the Auto number checkbox.
  3. Provide a Prefix (e.g., “INC”).
  4. Specify the Digits (e.g., 7 for the numbers after the prefix).

When you create a record in this table, ServiceNow will automatically generate a unique number based on this configuration. The system manages the sequence behind the scenes.

33. What happens when you extend a table?

Answer: When you extend a table (e.g., create a new table that inherits from `task`), the child table automatically gains all the fields and properties of the parent table.

Key points:

  • Inherited Fields: Fields from the parent table are available in the child table without needing to redefine them.
  • No Re-creation of System Fields: System fields (like sys_id, sys_created_on, sys_updated_on) are not recreated in the child table; they are inherited.
  • `class` Field in Parent: A field named class is created in the parent table. This field stores the sys_id of the child table that the current record belongs to. This is how ServiceNow knows which specific table a record originated from, especially when querying the parent table.
  • Single Class Field: Even if a table extends multiple tables (though this is less common and often discouraged), it will still have only one class field in its ultimate parent.

34. Can you give me 10 field types?

Answer: ServiceNow offers a rich variety of field types. Here are 10 common ones:

  1. Reference: Links to another record in a different table (e.g., referencing a user in an incident).
  2. String: For text input.
  3. List: Allows selecting multiple records from another table (e.g., a list of groups).
  4. Choice: A dropdown list of predefined options.
  5. Email: Specifically formatted for email addresses.
  6. Date/Time: For selecting both date and time.
  7. Date: For selecting only the date.
  8. Boolean: A true/false checkbox.
  9. Integer: For whole numbers.
  10. Journal: For adding free-form text entries, often with a history (e.g., Work Notes, Activity).
  11. Attachment: Allows users to upload files.

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

Answer:

  • Normal Tables: Store data permanently. These are your standard tables like incident, sys_user, etc. Data persists until explicitly deleted or archived.
  • Temporary Tables: Designed for short-term data storage. They typically have a data retention period (e.g., 7 days) after which the data is automatically purged. These tables often extend the import_set_row table and are commonly used for staging data during import processes or for holding transient data.

Temporary tables are excellent for ETL (Extract, Transform, Load) processes where you need to process data in batches before it’s moved to permanent storage.

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

Answer: Yes, you can typically extend the retention period for data in temporary tables by configuring Archive Rules. While temporary tables are designed for short retention, archiving allows you to define policies to retain data for longer if needed, though their primary purpose remains short-term staging.

37. 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 them, you’re accessing data that resides locally.
  • Remote Tables: These tables act as a gateway to data residing outside your ServiceNow instance, typically in another external system or database. When you query a remote table, ServiceNow fetches the data live from the external source in real-time.

Remote tables are powerful for integrating ServiceNow with other systems without needing to replicate all their data locally. However, performance can be dependent on the external system’s responsiveness.

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

Answer: These terms describe how records in different tables are related.

  • One-to-Many Relationship: This is the most common type. 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 is assigned to only one user. This is implemented using a reference field on the “many” side (e.g., caller_id on the incident table referencing sys_user).
  • One-to-One Relationship: In ServiceNow, a true one-to-one relationship is less common and often achieved by making a reference field mandatory and ensuring uniqueness through ACLs or business rules. More practically, it’s about one record in Table A having *at most* one related record in Table B.
    • Example: User and User Profile (hypothetical). If a user record had a single, mandatory reference to a `sys_user_profile` record, and the `sys_user_profile` record also had a mandatory reference back to the user with uniqueness enforced, you’d effectively have a one-to-one mapping.
  • Many-to-Many Relationship: This is where 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.
    • Example: Incidents and Groups. An incident can be assigned to multiple groups (though typically one primary assignment group), and a group can be assigned to multiple incidents. This is implemented using a many-to-many field type (often a list field) or more commonly, through a join table. For instance, sys_user_grmember is a join table for users and groups. For incidents and groups, you might see a custom join table or a field that allows multiple selections.

Understanding these relationships is key to designing your data model and writing efficient queries.

IV. Scripting Best Practices & Advanced Concepts

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

Answer: There are numerous ways to create records:

  1. Form: Manually via the ServiceNow user interface.
  2. GlideRecord: Using server-side scripting (e.g., in Business Rules, Script Includes).
  3. Record Producers: A specific type of catalog item that creates a record in a table.
  4. Import Sets/Transform Maps: Importing data from external sources like Excel, CSV.
  5. Email: Incoming email actions can create records.
  6. REST API/SOAP Web Services: Creating records programmatically from external systems.
  7. Workflow Activities: Creating records as part of an automated workflow.
  8. UI Actions: Custom buttons/links on forms can trigger record creation.

Interview Relevance: Mentioning a variety of methods showcases your breadth of knowledge beyond just GlideRecord.

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

Answer: This is a crucial question about controlling the user interface and data integrity:

  1. Dictionary Properties: You can set a field as mandatory directly in its dictionary entry. Read-only is less common here, usually managed via ACLs.
  2. Dictionary Overrides: To change the behavior of a field from a parent table in a child table, you use dictionary overrides.
  3. UI Policies: Client-side logic that makes fields mandatory, read-only, visible/hidden, or sets their values based on conditions on the form.
  4. Data Policies: Similar to UI Policies but can be enforced on both client and server sides, ensuring data integrity regardless of how the record is created or modified.
  5. Client Scripts: Using g_form.setMandatory('field_name', true/false);, g_form.setReadOnly('field_name', true/false);, and g_form.setVisible('field_name', true/false); for dynamic client-side control.
  6. Access Control Lists (ACLs): Primarily used for read and write (edit) permissions, effectively making fields read-only or inaccessible based on roles and conditions.

UI Policies and Client Scripts are for client-side dynamic behavior, Data Policies for data integrity across all data sources, and ACLs for security-level permissions.

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

Answer: Technically, you can set the Display attribute to true for multiple fields in a table’s dictionary entry. However, it’s strongly discouraged and considered a bad practice.

The ‘Display’ attribute is intended to indicate which field should be used to uniquely represent a record when it’s shown as a choice in a reference field’s dropdown or in a lookup. Having multiple display fields will cause confusion and unpredictable behavior. ServiceNow’s documentation and best practices recommend only one display field per table.

42. Where are all tables stored?

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

This table contains metadata about every table in the instance, including its name, label, schema, and other configuration details.

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

Answer: You can set default values in several ways:

  • Dictionary Entry: In the dictionary definition for a field, there’s a “Default value” field. This value will be pre-populated when a new record is created via the form.
  • UI Policies: You can set default values as actions within a UI Policy, often triggered on load.
  • Client Scripts: Using g_form.setValue('field_name', 'default_value'); in an OnLoad client script.
  • Business Rules: For server-side creation (e.g., in an after insert Business Rule on a different table that creates a record in this table), you can set the default value before inserting.

The dictionary entry is the most straightforward method for static default values.

44. What is the ‘current’ object?

Answer: The current object is a fundamental server-side object available in Business Rules, UI Actions, and Workflow scripts. It represents the record that is currently being processed or acted upon.

When a record is inserted, updated, or deleted, the current object holds the state of that record. You use it to get and set field values on the record being processed.

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

Answer: Using the current object:

  • `current.setValue(‘field_name’, value);`: This is the standard way to set a field’s value. For reference fields, you must provide the sys_id of the referenced record.
  • `current.setDisplayValue(‘field_name’, value);`: This is useful for reference fields. You can provide the display value (e.g., the username) instead of the sys_id, and ServiceNow will attempt to resolve it to the correct sys_id.

Example:

// Setting a string field
current.setValue('short_description', 'Updated short description');

// Setting a reference field using sys_id
current.setValue('caller_id', '6816f79cc0a8016401c5a33be04be441');

// Setting a reference field using display value
current.setDisplayValue('assigned_to', 'John Doe'); // ServiceNow will find the sys_id for 'John Doe'

46. What are reference qualifiers, and what are their types? Explain each one and their differences.

Answer: Reference qualifiers are used to restrict the records that can be selected in a reference field or a list field. They act as filters.

There are three main types:

  1. Simple Reference Qualifier:

    This is the most basic type. You define a static query string directly in the reference qualifier field of the dictionary entry. It’s a set of conditions like you’d use in a GlideRecord query.

    Example: To show only active users, you’d set the condition to active=true.

  2. Dynamic Reference Qualifier:

    This type uses predefined “Dynamic Filter Options” (found under System Definition > Dynamic Filter Options). These options allow you to create reusable filters that can be context-aware. They are useful for common filtering scenarios.

    Example: You might have a dynamic filter that shows users from the current record’s department. You select this dynamic option in the reference qualifier field.

  3. Advanced Reference Qualifier (JavaScript Reference Qualifier):

    This is the most powerful type, allowing you to write custom JavaScript code to dynamically filter records. This script runs on the server-side and should return a query string. It’s used for complex filtering logic that cannot be achieved with simple or dynamic qualifiers.

    Example: To show only users who are members of the same group as the current incident’s assignment group:

    javascript: 'sys_idIN' + gs.getUser().getGroups().toString(); // A very basic example, often more complex logic is needed

    Or, to filter based on fields on the current form:

    javascript: 'assignment_group=' + current.assignment_group + '^active=true';

Differences:

  • Simple vs. Dynamic: Simple is static; Dynamic uses reusable pre-configured filters.
  • Dynamic vs. Advanced: Dynamic uses pre-built filters for common scenarios; Advanced allows complete custom JavaScript logic for any scenario.
  • Simple vs. Advanced: Simple is a static query string; Advanced is executable JavaScript code that generates a query string.

Interview Relevance: This is a very common and important question. Be prepared to explain the practical application and when you’d choose each type.

47. What is a dependent value?

Answer: Dependent values in a dictionary entry are used to create cascaded dropdowns. When a user selects an option in one field (the “parent” field), the available choices in another field (the “dependent” field) are dynamically filtered to show only relevant options.

Example: You have a “Category” field (e.g., Hardware, Software) and a “Subcategory” field. If the user selects “Hardware” for Category, the Subcategory dropdown should only show options like “Laptop,” “Desktop,” “Printer.” If they select “Software,” it should show “Operating System,” “Application,” etc.

How it works: You configure this in the dictionary entry of the dependent field by setting the “Dependent field” attribute to the name of the parent field and defining the choices for the dependent field, linking them to specific parent field values.

48. What is a calculated value?

Answer: A calculated value is a field whose value is not directly entered by the user but is automatically computed based on other fields or logic. This is configured using the “Calculation” field in the dictionary entry for a field.

You can write a simple formula (e.g., `field1 + field2`) or a JavaScript snippet in the “Calculation” field. When the record is saved, ServiceNow executes this calculation and populates the field. This is useful for fields like “Total Cost,” “Net Amount,” or derived scores.

Example: If you have fields `price` and `quantity`, you could set the `total_price` field’s calculation to `price * quantity`.

49. What are attributes? Name some of the attributes you have used.

Answer: Attributes are special keywords defined in the dictionary entry for a field or a table (in the collection field). They are used to modify or enhance the default behavior of fields or the table itself.

Examples of Attributes I’ve Used:

  • no_email: Prevents email notifications from being triggered for changes to this field.
  • no_attachment: Disables the attachment functionality for a specific table.
  • ref_auto_completer: Enables auto-completion for reference fields.
  • ref_ac_columns: Specifies which columns should be displayed in the auto-completion dropdown for a reference field.
  • ref_ac_columns_search: Controls whether the search in the auto-completion dropdown should be limited to specified columns.
  • tree_picker: For reference fields, it enables a tree-like picker interface.
  • no_add_me: Typically used on assignment group fields, it prevents the current user from being added to the group directly via a button.

50. What is a collection field on a table?

Answer: When you view the dictionary entries for a table, you’ll see entries that represent fields. However, there’s also a special type of dictionary entry where the “Type” is set to “Collection.” This entry doesn’t represent a specific field but rather the table itself.

Any attributes or configurations applied to this “Collection” dictionary entry affect the entire table. For example, if you add the no_attachment attribute to the collection field’s dictionary entry, attachments will be disabled for all records in that table.

51. How to enable/disable attachment on the form using attributes?

Answer: You disable attachments on a form (table) by adding the no_attachment attribute to the collection field’s dictionary entry for that table. Conversely, if you wanted to ensure attachments are enabled (which is the default), you wouldn’t add this attribute.

52. What are dictionary overrides? What properties can we override?

Answer: Dictionary overrides allow you to modify the definition of a field that exists in a parent table when it’s used in a child table. This is crucial for customizing inherited fields without altering the base table definition.

You can override various properties of a field, including:

  • Default value
  • Mandatory flag
  • Read-only flag
  • Display flag
  • Max length
  • Choice list specifications
  • Reference qualifier
  • Help text
  • Attributes

For example, the `priority` field might have a default value of 4 on the `task` table. In the `incident` table, you might use a dictionary override to set its default value to 5 and make it mandatory. This is a clean way to customize inherited fields.

53. What are application menus?

Answer: Application Menus are top-level entries in the ServiceNow navigation menu (the left-hand navigator). They act as containers for modules. When you click on an Application Menu, it typically expands to show a list of modules associated with it.

Modules (which are created under Application Menus) are what link users to specific forms, lists, or reports. So, Application Menus provide the organizational structure for your navigation.

54. What is a process flow?

Answer: A process flow visualizes the stages or steps a record goes through during its lifecycle. It’s typically displayed on a form and shows the current state of the record in a graphical representation, highlighting the progress and guiding the user through the defined workflow.

For example, on an Incident form, a process flow might show stages like “New,” “In Progress,” “On Hold,” and “Resolved,” visually indicating where the incident stands. This helps users understand the workflow and what actions might be appropriate next.

55. What are data lookup rules?

Answer: Data Lookup Rules (found under System UI > Data Lookup Rules) allow you to automatically populate field values on a form based on specific conditions. They are configured in a separate table and work by matching values from a “lookup table” to fields on the target table.

This is different from Business Rules or UI Policies because it’s a declarative way to handle data population. For instance, if a user selects a specific “Location,” a data lookup rule could automatically populate their “Department” and “Manager” fields based on pre-defined mappings in the lookup table.

56. What are UI policies?

Answer: UI Policies are client-side scripts that dynamically change the behavior of fields on a form based on conditions. They can make fields mandatory, read-only, visible/hidden, or set their values.

They are a powerful alternative to Client Scripts for many common UI manipulations, offering a more declarative and easier-to-manage approach for simple to moderately complex conditional logic on the client-side.

57. What does the ‘Global’ checkbox in UI policies mean?

Answer: When the ‘Global’ checkbox is checked on a UI Policy, it means the UI Policy will apply to all views of the table. If it’s unchecked, you must specify which views the UI Policy should apply to in the “Views” related list.

Checking ‘Global’ is generally the preferred approach unless you have specific reasons to control UI Policy behavior on a per-view basis.

58. What does ‘Reverse if false’ mean in UI policies?

Answer: If the ‘Reverse if false’ checkbox is checked, the actions defined in the UI Policy will be reversed when the UI Policy’s condition evaluates to false.

Example: If a UI Policy makes a field mandatory when a condition is true, and ‘Reverse if false’ is checked, that field will automatically become optional again when the condition becomes false.

59. What does the ‘On Load’ checkbox in UI policy mean?

Answer: When the ‘On Load’ checkbox is selected, the UI Policy’s conditions and actions are evaluated and applied as soon as the form is loaded.

If ‘On Load’ is *not* selected, the UI Policy’s actions will not be applied when the form initially loads. They will only trigger when a change on the form causes the UI Policy’s condition to be met.

60. What does the ‘Inherit’ checkbox mean in UI policies?

Answer: When the ‘Inherit’ checkbox is checked on a UI Policy, it means that the UI Policy will also be applied to child tables that extend the table on which the UI Policy is defined.

This is a great way to ensure consistent UI behavior across a table hierarchy. For instance, a UI Policy on the `task` table could inherit to `incident`, `problem`, and `change_request` tables.

61. Can you write scripts in UI policies?

Answer: Yes, you can! To enable scripting within a UI Policy, you need to check the ‘Run scripts’ checkbox in the UI Policy record itself. Then, within the UI Policy Actions, you can enable the ‘Run scripts’ checkbox for specific actions and write client-side JavaScript code.

This allows for more dynamic and complex client-side logic beyond what simple conditions can handle, such as custom field manipulations or dynamic visibility based on intricate calculations.

62. Can we convert a UI policy into a data policy?

Answer: Yes, you can convert a UI Policy into a Data Policy. There’s a handy button or link within the UI Policy form (usually labeled “Convert to Data Policy”) that will generate a corresponding Data Policy record based on the UI Policy’s conditions and actions.

Interview Relevance: This demonstrates understanding of how different platform features can be transitioned to ensure data integrity.

63. Which are all the cases where a UI policy cannot be converted as a data policy?

Answer: While conversion is generally straightforward, there are scenarios where a UI Policy cannot be directly converted to a Data Policy because Data Policies operate on data integrity (client and server) and don’t directly control UI elements in the same way:

  • Controlling Data Visibility (Show/Hide): Data Policies cannot directly hide or show fields. This is a UI concern.
  • Controlling Views: UI Policies can sometimes influence which views are loaded or active, but Data Policies do not manage view logic.
  • Controlling Related Lists: UI Policies can show/hide related lists; Data Policies cannot.
  • Scripts that solely manipulate UI elements: If the UI Policy script’s primary purpose is to manipulate form elements (like changing colors, adding buttons dynamically that aren’t related to data validation), it won’t translate directly.

Essentially, any UI Policy action that is purely about the visual presentation of the form and not about enforcing data rules might not be convertible.

64. What are data policies?

Answer: Data Policies are server-side (and can also be client-side) logic that enforces data consistency and integrity across all data sources, including forms, import sets, and web services. They are used to make fields mandatory, read-only, or set their values based on specified conditions.

Think of them as business rules for data integrity. They ensure that regardless of *how* a record is created or modified, certain data rules are always applied. This is critical for maintaining the quality and reliability of your data.

Phew! That’s a lot, but covering these questions thoroughly will give you a massive advantage. Remember to practice explaining these concepts in your own words, and if possible, relate them to projects you’ve worked on. Good luck with your interview!


Scroll to Top