Demystifying ServiceNow: Your Top Service Portal Questions Answered

In the dynamic world of IT service management, ServiceNow stands as a titan. As administrators, developers, and end-users navigate its vast landscape, a common set of questions invariably arises. This article delves into those frequently asked questions, providing clear, human-like explanations designed to empower you with practical knowledge and a deeper understanding of ServiceNow’s core functionalities. Whether you’re preparing for an interview, troubleshooting an issue, or simply looking to sharpen your skills, this guide is your go-to resource.

Navigating Your ServiceNow Instance: Versions and Starting Points

Understanding where you are and where you’ve been in your ServiceNow journey is crucial for effective platform management.

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

As of my last update, many organizations are actively working on the Washington DC release, which is the latest stable version. ServiceNow consistently releases new versions, so it’s always a good practice to stay informed about the current one.

From which version did you start working?

My journey began with the Rome release. Since then, I’ve had the opportunity to work with subsequent major versions including San Diego, Tokyo, Utah, Vancouver, and now Washington DC. Each release brings enhancements and new features, making it an exciting evolution to follow.

User and Group Management: The Foundation of Access Control

Effective security and access control in ServiceNow hinge on how you manage users, groups, and their associated permissions (roles). Let’s break down the essentials.

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

Absolutely! Permissions in ServiceNow are primarily managed through roles. You can assign roles directly to individual users or, more effectively, to groups. The best practice is to assign roles to groups. This is a game-changer for efficiency and security. When an employee leaves the organization, or their role changes, you simply remove them from the relevant group(s), and their permissions are automatically revoked. This prevents orphaned roles and streamlines user lifecycle management.

What is the user table name?

The primary table for user records is sys_user.

What is the group member table name?

The table that links users to groups is sys_user_grmember. This table is crucial for understanding group memberships.

How to create a user account using a script?

You can create user accounts programmatically using GlideRecord. Here’s a typical script:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();

How to create a group using a script?

Similarly, you can create groups using GlideRecord:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group'; // A descriptive name for your group
userGr.description = 'This group is for testing purposes.'; // A brief description
newGr.manager = 'sys_id_of_manager'; // Replace with the sys_id of the manager
newGr.email = 'testing@tcs.com';
newGr.insert();

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

Permissions are managed via roles. The system uses specific tables to track user-role and group-role assignments:

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

Here are the scripts for adding roles:

Adding a role to a user:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', 'sys_id_of_user'); // Replace with the user's sys_id
userRole.setValue('role', 'sys_id_of_role'); // Replace with the role's sys_id
userRole.insert();

Adding a role to a group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', 'sys_id_of_group'); // Replace with the group's sys_id
grpRole.setValue('role', 'sys_id_of_role'); // Replace with the role's sys_id
grpRole.insert();

What exactly does user delegation mean in ServiceNow?

User delegation is a powerful feature that allows one user to perform tasks and access resources on behalf of another user. This is particularly useful when an employee is on leave, vacation, or otherwise unavailable. The delegated user gains the necessary permissions to act as the original user, ensuring critical workflows like approvals continue without interruption.

Example: If an employee is going on vacation, they can delegate their approval tasks to a colleague. This colleague can then access and approve records as if they were the original employee.

Configuration: This is typically configured within the original user’s account profile. Scroll down to the “Delegates” section where you can specify the delegate’s name, the start and end dates of the delegation, and the types of permissions they will have (e.g., assignments, notifications, approvals).

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

Managing group memberships programmatically is a common task:

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = 'sys_id_of_user'; // User to add
grMem.group = 'sys_id_of_group'; // Group to add to
grMem.insert();

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'sys_id_of_user'); // User to remove
grMem.addQuery('group', 'sys_id_of_group'); // Group to remove from
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}

ServiceNow User Interfaces and Web Services

Understanding how users interact with ServiceNow and how external systems connect is key.

How many user interfaces are there in ServiceNow?

Historically, ServiceNow has offered several UIs. The most prominent ones you’ll encounter are:

• UI15 & UI16: These are older, but still prevalent, interface styles.
• Next Experience UI: This is the modern, sleek, and intuitive interface that ServiceNow is pushing forward, offering a more user-friendly experience.

Many organizations are migrating to the Next Experience UI for its enhanced usability and modern design principles.

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

A “web services user” (often referred to as a service account) is a user account in ServiceNow specifically created to allow third-party applications or integrations to connect to and interact with the ServiceNow platform. Crucially, these users cannot log in directly to the ServiceNow graphical user interface (GUI) as a regular user would. Their sole purpose is to facilitate automated data exchange and process execution between systems.

Client-Side vs. Server-Side Scripting: Accessing User Information

Knowing where you are in the ServiceNow architecture (client-side or server-side) dictates how you access information, especially about the currently logged-in user.

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

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

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

This will output the `sys_id` of the currently logged-in user.

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

On the server-side (e.g., within business rules, script includes, or workflow scripts), you use the gs (GlideSystem) object:

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

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

This is a common check, especially in security or workflow logic. On the server-side, you can use:

if (gs.getUser().isMemberOf('group_name')) { // Replace 'group_name' with the actual name or sys_id of the group
    gs.info('User is a member of the specified group.');
    // Perform actions for members
} else {
    gs.info('User is NOT a member of the specified group.');
    // Perform actions for non-members
}

You can also use the group’s `sys_id` for more precise checks.

Security and Administration: Roles, Impersonation, and Preferences

Securing your ServiceNow instance and managing user experiences involves understanding administrative roles and user settings.

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

To create, modify, or manage Access Control Lists (ACLs) in ServiceNow, you need the security_admin role.

What is impersonation?

Impersonation is a feature that allows an administrator or a user with appropriate permissions to temporarily log in and act as another user. This is invaluable for testing user experiences, troubleshooting issues from a specific user’s perspective, or demonstrating functionality. You can access impersonation from the user profile menu.

What is user preference?

User preferences are settings that an individual user can configure to personalize their ServiceNow experience. These preferences are specific to that user and do not affect other users on the platform. Examples include list column configurations, form layouts, or notification settings. When a user changes their preferences, it only impacts their view.

ITSM Fundamentals: Incidents, Problems, and Changes

These three modules form the backbone of IT Service Management within ServiceNow, and understanding their distinctions and relationships is crucial.

What is an incident?

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 a sudden issue that prevents them from performing their work (e.g., their laptop won’t boot, an application crashes), they report it as an incident. The goal is to restore normal service operation as quickly as possible.

What is a problem?

A problem is the underlying cause of one or more incidents. If the same type of incident occurs repeatedly, it signals an underlying problem. The goal of problem management is to identify the root cause of incidents and provide workarounds or permanent fixes to prevent future occurrences. In complex scenarios, a major incident might have multiple child incidents linked to it.

Can we create a problem record from an incident?

Yes, absolutely. If a support engineer identifies that an incident is part of a recurring issue, they can escalate it by creating a linked Problem record from the incident form. This is a key step in moving from reactive incident resolution to proactive problem management.

Can we create a change request from an incident?

Yes. If resolving an incident requires making a change to the IT infrastructure or software (e.g., patching a server, deploying a new version of an application), a Change Request can be created directly from the incident. This ensures that necessary changes are properly managed, planned, and executed.

How to create an incident record using a script?

Creating incidents programmatically is common for integrations or automated ticket creation:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = 'sys_id_of_caller'; // User reporting the incident
gr.category = 'inquiry'; // e.g., Hardware, Software
gr.subcategory = 'antivirus'; // More specific category
gr.cmdb_ci = 'sys_id_of_ci'; // Related Configuration Item (CI)
gr.short_description = 'Test record created via script';
gr.description = 'Detailed description of the issue.';
gr.assignment_group = 'sys_id_of_assignment_group'; // Group responsible for resolving
gr.insert();

How to create a problem record using a script?

Similar to incidents, problems can be created via script:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = 'sys_id_of_caller';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'sys_id_of_ci';
gr.short_description = 'Test problem record via script';
gr.description = 'Detailed description of the underlying problem.';
gr.assignment_group = 'sys_id_of_assignment_group';
gr.insert();

How to create a change request using a script?

And for change requests:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry'; // e.g., Normal, Emergency, Standard
gr.subcategory = 'antivirus'; // Specific type of change
gr.cmdb_ci = 'sys_id_of_ci'; // CI affected by the change
gr.short_description = 'Test change request via script';
gr.description = 'Detailed description of the change.';
gr.assignment_group = 'sys_id_of_assignment_group'; // Group responsible for the change
gr.insert();

Automation and Business Logic: Workflow Automation

ServiceNow’s power lies in its ability to automate complex processes. Business Rules and workflows are key to this.

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

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

When to run: After

Update: True

Condition: current.state.changesTo(7) (assuming 7 is the state value for ‘Closed’). Also, ensure it’s a top-level incident (no parent).

Script:

if (current.state == 7 && current.parent == '') { // Check if it's the closed state and no parent
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find incidents where the parent is the current incident
    grChild.query();
    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident
    }
}

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.

This requires a Before Business Rule on the incident (and similarly for problem and change_request) table:

When to run: Before

Update: True

Condition: current.state.changesTo(7) (or your closed state value).

Script:

// For Incident Tasks
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
grTask.query();
if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open incident tasks.');
    current.setAbortAction(true);
}

// You would implement similar checks for Problem Tasks (task_SOW) and Change Tasks (change_task) if applicable.

The logic would be similar for Problem and Change Request, querying their respective task tables (e.g., problem_task, change_task).

Whenever a problem is closed, the associated incident will also get closed?

This is another scenario for a Before Business Rule on the problem table:

When to run: Before

Update: True

Condition: current.state.changesTo(7) (assuming 7 is the closed state).

Script:

if (current.state == 7) { // If the problem is being closed
    // Find incidents associated with this problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Assumes 'problem_id' is the field linking incidents to problems
    grIncident.addQuery('state', '!=', 7); // Only update incidents that are not already closed
    grIncident.query();
    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
    }
}

ServiceNow Data Model: Tables, Relationships, and Fields

A solid understanding of ServiceNow’s data structure is fundamental for any serious administrator or developer.

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

These ITIL processes are interconnected:

• Incident Management: Focuses on restoring normal service operation as quickly as possible after an interruption.
• Problem Management: Investigates the root cause of recurring incidents to prevent them from happening again. An incident can be linked to a problem to track this investigation.
• Change Management: Manages all changes to the IT infrastructure in a controlled way to minimize risk. If an incident or problem resolution requires a change, a Change Request is created, often linked to the incident or problem.

The flow often looks like this: Multiple Incidents -> identify a Problem -> implement a Change Request to fix the problem.

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

Out-of-the-box tables are those provided by ServiceNow without custom creation. They typically do not start with x_ or u_ (which indicate custom tables). Examples include:

• incident
• problem
• change_request
• sc_req_item (Service Catalog Requested Item)
• sys_user
• sys_user_group
• cmdb_ci (Configuration Item)
• task

What are some of the base tables?

Base tables are fundamental tables that do not extend any other table but are extended by many other tables. They often represent core entities. Key examples include:

• task: This is a foundational table for many IT workflows, including Incidents, Problems, and Change Requests. It provides common fields like number, short description, state, assignment group, etc.
• cmdb_ci: The base table for the Configuration Management Database (CMDB), representing all discoverable IT components.

Give me some examples of task tables.

Task tables are those that extend the base task table. They inherit common fields and functionalities from task. Examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• ப்படுகின்றன (ITSM Incident Task)

Whenever we create a table, how many access controls (ACLs) will get created?

By default, when you create a new table in ServiceNow and the “Create ACLs” checkbox is selected (which it is by default), four Access Control Lists (ACLs) are automatically generated:

• Read
• Write
• Create
• Delete

These provide basic access control for the new table. You can uncheck this box if you plan to define ACLs manually later.

How to create a number field, like incident number?

To create an auto-numbering field, like the incident.number field, you typically configure this within the Dictionary Entry for that field:

1. Navigate to the Dictionary entry for the table and field.
2. Under the “Control” tab (or similar section depending on the UI), you’ll find options for “Auto-number”.
3. Enable the “Auto-number” checkbox.
4. Specify a Prefix (e.g., INC for incidents) and the Number of digits (e.g., 7 for INC0000001).

What happens when you extend a table?

When you extend a table (i.e., create a child table that inherits from a parent table), several things happen:

• Inheritance of Fields: The child table inherits all fields from its parent table. You don’t need to recreate these fields.
• `sys_class_name` Field: A field named sys_class_name is automatically added to the *parent* table. This field stores the actual `sys_class_name` of the record (e.g., ‘incident’, ‘problem’). This allows a single table (like task) to hold records from multiple extended tables, and ServiceNow knows which specific table each record belongs to.
• No Duplicate System Fields: System fields (like `sys_id`, `sys_created_on`) are not duplicated in the child table; they are inherited from the parent.

Can you give me 10 field types?

ServiceNow offers a rich variety of field types to capture different kinds of data:

1. Reference: Links to another record in a different table.
2. String: For general text input (single line).
3. List: Similar to Reference, but allows multiple selections from another table.
4. Choice: A dropdown list of predefined options.
5. Email: Specifically formatted for email addresses.
6. Date/Time: Captures both date and time.
7. Date: Captures only the date.
8. Boolean: A true/false or checkbox field.
9. Integer: For whole numbers.
10. Journal: Typically used for work notes or comments, allowing multiple entries over time.
11. Attachment: Allows users to upload files.
12. HTML: For rich text formatting.

What is the difference between a temporary and normal table?

The primary distinction lies in data retention:

• Normal Tables: Store data permanently. Records remain until explicitly deleted. These are your standard application tables.
• Temporary Tables: Designed for short-term data storage, typically associated with import sets. Data in these tables usually has a limited retention period (e.g., 7 days) and they often extend the import_set_row table.

Can we increase the retention period in a temporary table?

Yes, you can influence data retention in temporary tables, often by configuring Archive Rules. While they are designed for temporary storage, specific archiving policies can be implemented to manage their lifecycle or retain data longer if needed for audit or specific processes.

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

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

• Normal Tables: Data is stored directly within your ServiceNow instance’s database.
• Remote Tables: These tables allow you to access live data from an external data source (e.g., another database, a REST API) as if it were stored locally in ServiceNow. ServiceNow acts as a proxy, fetching data in real-time when queried. This avoids data duplication but can introduce performance considerations based on the external source’s responsiveness.

What are one-to-one and one-to-many tables in ServiceNow?

These terms describe the nature of relationships between records in different tables:

• One-to-Many Relationship: This is the most common type. For example, one User can have many Incidents, but each Incident is typically associated with only one User (the caller). This is achieved by placing a reference field (e.g., `caller_id` on the `incident` table) pointing to the ‘one’ side (sys_user).
• Many-to-Many Relationship: In this scenario, records from one table can be linked to multiple records in another table, and vice-versa. A classic example is Incidents and Groups. An Incident might be assigned to multiple groups for collaboration, and a Group can work on many Incidents. This is usually managed via a separate “junction” table (e.g., incident_group or similar) which holds pairs of `incident_sys_id` and `group_sys_id`.

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

ServiceNow provides multiple avenues for record creation:

• Forms: The standard user interface for manually creating records.
• Record Producers: Catalog items designed to create records in specific tables, often simplifying the process for end-users.
• Email: Incoming email can be configured to automatically create records (e.g., incidents, requests).
• GlideRecord Scripting: Programmatic creation using server-side scripts (as shown in previous examples).
• External Systems: Data can be imported via Import Sets or created through integrations using REST/SOAP APIs.
• Excel Upload: Users can upload data from spreadsheets, which is processed via Import Sets.

Field Customization and Configuration

Tailoring fields to meet specific business needs is a core part of ServiceNow administration.

In how many ways can we make a field mandatory, read-only?

You have several powerful options:

1. Dictionary Properties: You can set a field as mandatory directly in its Dictionary Entry.
2. Dictionary Overrides: For inherited fields in child tables, you can override their properties, including making them mandatory or read-only.
3. UI Policies: Client-side scripts that dynamically control field behavior (mandatory, read-only, visible, hidden) based on conditions on the form.
4. Data Policies: Similar to UI Policies but work on both client and server sides, ensuring data integrity regardless of how the record is accessed.
5. Client Scripts (e.g., g_form.setMandatory()): For more complex client-side logic, you can use JavaScript to set mandatory or read-only states.

Can we make 2 fields display in one table?

You should generally not have more than one field marked as “Display” on a table. The “Display” attribute on a field is intended to provide a user-friendly, human-readable label for records of that table when they are referenced in other tables. Having multiple display fields can lead to confusion and inconsistent display names in related lists and reference lookups.

All tables will be stored where?

All table definitions in ServiceNow are stored in the sys_db_object table. This meta-table describes the structure of every table within the instance.

How to set a default value on a field?

Default values can be set in a few ways:

• Dictionary Entry: In the field’s Dictionary Entry, you can specify a “Default value”. This value will be pre-populated when a new record is created using the standard form.
• UI Policies/Client Scripts: You can use these to set default values dynamically based on certain conditions when a form loads or when other fields change.

Scripting Essentials: Current Object, Attributes, and Reference Qualifiers

Advanced configurations often involve server-side scripting and understanding how to manipulate field behavior.

What is the `current` object?

The current object is a server-side scripting object that represents the current record being processed. It’s available in Business Rules, Script Includes, and other server-side contexts. You use it to get and set values on the record that triggered the script.

How to set field values on the `current` form?

You use methods like `setValue` and `setDisplayValue` on the `current` object:

• `current.setValue(‘field_name’, value);`: This is used to set the *actual* value of a field. For reference fields, you must provide the sys_id of the referenced record.
• `current.setDisplayValue(‘field_name’, value);`: This is useful for setting the *display value* of a field. For reference fields, you can pass the actual display text (e.g., a username), and ServiceNow will try to find the corresponding `sys_id`. Use this with caution, as it can be less reliable than `setValue` if multiple records have the same display value.

What are reference qualifiers, and their types? Explain each one in detail and the difference between simple, dynamic, and advanced.

Reference Qualifiers are essential for filtering the records that appear in a reference field or a list collector. They ensure users select only relevant data, improving data integrity and usability.

There are three main types:

1. Simple Reference Qualifier:

   Description: This is the most basic type, where you define a fixed query using dot-walking and operators directly in the reference field’s Dictionary Entry. It’s static and doesn’t change based on form context.

   Example: To show only active users in a user reference field, you’d set the qualifier to active=true.

   How to Use: In the Dictionary Entry of the reference field, under the “Reference Qualifier” section, select “Simple” and enter your query (e.g., state=1^ORstate=2).

2. Dynamic Reference Qualifier:

   Description: This type uses a predefined “Dynamic Filter Option” that can be context-aware. These options are created in System Definition > Dynamic Filter Options and can be reused across multiple reference qualifiers.

   Example: Displaying only users who are members of a specific department (which might be derived from another field on the form).

   How to Use: Create a Dynamic Filter Option. Then, in the reference field’s Dictionary Entry, select “Dynamic” and choose your created Dynamic Filter Option from the dropdown.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier):

   Description: This is the most powerful type, allowing you to write custom JavaScript code to define complex filtering logic. It can access current form field values, perform calculations, and apply very intricate conditions.

   Example: Filtering a list of configuration items (CIs) to show only those that are of type “Server” and are currently “Operational”. Or, filtering tasks to only show those assigned to the same assignment group as the current incident.

   How to Use: In the reference field’s Dictionary Entry, select “Advanced”. In the “Reference qualifier” field, enter your JavaScript code. For example:

   javascript: 'assignment_group=' + current.assignment_group + '^state!=3';

   (This example assumes the current form has an `assignment_group` field and you want to show tasks assigned to that group where the state is not ‘Closed’ – state 3).

Key Differences:

• Simple vs. Dynamic: Simple is static; Dynamic uses pre-defined, reusable filter options.
• Dynamic vs. Advanced: Dynamic uses a UI-driven setup for predefined filters; Advanced uses custom JavaScript for maximum flexibility.
• Simple vs. Advanced: Simple uses basic dot-walking and operators; Advanced uses full JavaScript for complex logic.

What is a dependent value?

Dependent values are used to create cascaded dropdowns. When a user selects a value in one field (the parent field), the choices available in another field (the dependent field) are dynamically filtered based on that selection. This significantly improves user experience by presenting only relevant options.

Example:

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

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

Configuration: This is set up in the Dictionary Entry of the dependent field by specifying the “Dependent Field” attribute to point to the parent field and then defining the choices, linking each choice in the dependent field to a specific parent choice.

What is a calculated value?

A calculated value is a field whose value is not directly entered by a user but is derived from a calculation or logic based on other fields. This is achieved by using a “Calculation” formula in the field’s Dictionary Entry. When the form is saved or the relevant fields change, the calculation is performed, and the result populates the field.

Example: A “Total Price” field that calculates Quantity * Unit Price.

What are attributes, name some of the attributes that you have used?

Attributes are special keywords added to a field’s Dictionary Entry that modify or enhance its behavior or appearance. They provide a way to customize field functionality without extensive scripting.

Some common attributes I’ve used include:

• no_email: Prevents this field from being included in outbound emails.
• no_attachment: Hides the attachment icon/functionality for this field (though not for the record itself if attachments are enabled globally).
• ref_ac_columns: Specifies which columns should be displayed in the dropdown of a reference field.
• ref_ac_columns_search: Similar to ref_ac_columns but specifically for search results in reference fields.
• tree_picker: Enables a hierarchical tree view for selection in a reference field (often used for organizational structures).
• max_length: Limits the number of characters that can be entered into a string field.

What is a collection field on a table?

In ServiceNow’s data model, a “collection” refers to the table itself, not a specific field. When you look at a Dictionary Entry, there are entries for individual fields (e.g., `incident.short_description`) and also an entry that represents the table itself (e.g., `incident`). Attributes or properties set on this “collection” entry apply to the entire table. For instance, setting no_attachment on the `incident` collection entry would disable attachments for all incident records.

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

You enable or disable attachments for a table by modifying the collection field’s Dictionary Entry. Add the attribute no_attachment to the collection field’s attributes if you want to disable attachments for that table. To enable them, ensure the attribute is removed or not present.

What are dictionary overrides? What properties can we override in dictionary overrides?

A Dictionary Override allows you to change the behavior or properties of a field that has been inherited from a parent table into a child table. This is crucial for tailoring fields to the specific needs of child tables without altering the parent table’s definition.

You can override many properties, including:

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

Example: The task table might have a default priority of ‘4’. You can create a Dictionary Override on the incident table to change the default priority for incidents to ‘2’.

ServiceNow UI Elements: Application Menus, Process Flows, and UI Policies

Understanding how users navigate and interact with ServiceNow is key to creating intuitive experiences.

What are application menus?

Application Menus (and their associated Modules) are used to organize and provide access points to forms, lists, and other functionalities within ServiceNow. They appear in the left-hand navigation menu. You create an application menu to group related functionalities, and then modules within that menu to link to specific tables, reports, or dashboards. This is how end-users discover and interact with different parts of the platform.

What is process flow?

A process flow (or workflow visualization) is a graphical representation of the steps involved in a particular process or record’s lifecycle. It typically appears at the top of a form and visually indicates the current stage of the record. For example, on an Incident form, it might show stages like “New,” “In Progress,” “On Hold,” “Resolved,” and “Closed.” This provides users with a clear understanding of where a record is in its workflow.

What are data lookup rules?

While not a standard ServiceNow term like “UI Policy” or “Data Policy,” “data lookup rules” likely refers to mechanisms that populate field values based on selections in other fields. This can be achieved through:

• Dictionary Overrides (for default values)
• UI Policies
• Data Policies
• Client Scripts
• Server-side Business Rules or Script Includes
• Record Producers with mapping

These mechanisms allow for automated data population, ensuring consistency and reducing manual entry.

What are UI Policies?

UI Policies are client-side scripts that dynamically control the behavior of form fields and related lists based on specific conditions. They are an alternative to client scripts for simpler logic. You can use them to:

• Make fields mandatory
• Make fields read-only
• Make fields visible or hidden
• Set default values
• Show or hide related lists

They offer a more declarative way to manage form behavior compared to writing custom JavaScript for every condition.

What is the global checkbox in UI Policies?

When the “Global” checkbox is checked in a UI Policy, it means the policy will apply to all views of the form. If unchecked, you can specify particular views where the UI Policy should be active. This allows for more granular control over UI behavior across different user interfaces or contexts.

What is reverse if false in UI Policies?

The “Reverse if false” checkbox is a powerful option in UI Policies. When checked, the actions defined in the UI Policy will be reversed when the policy’s condition evaluates to false. For instance, if a UI Policy makes a field mandatory when a condition is true, and “Reverse if false” is checked, that field will become optional (or revert to its original state) when the condition becomes false.

What is the onload checkbox in UI Policy?

The “On Load” checkbox determines when the UI Policy’s conditions and actions are evaluated.

• If checked: The UI Policy runs as soon as the form loads, applying its logic immediately.
• If unchecked: The UI Policy does not run on form load. Its logic will only be triggered when a user interacts with the form in a way that meets the UI Policy’s conditions (e.g., changing a field value).

This allows you to control whether a policy should enforce its rules from the moment the form opens or only in response to user input.

What is the inherit checkbox?

The “Inherit” checkbox on a UI Policy (or Data Policy) determines if the policy should be inherited by child tables that extend the table on which the policy is defined. If checked, the UI Policy will also be applied to records in those child tables, ensuring consistent behavior across your table hierarchy.

Can you write script in UI Policy?

Yes, you can! While UI Policies aim for a declarative approach, they also support scripting for more complex scenarios. To do this:

1. You need to enable the “Run scripts” checkbox in the UI Policy record.
2. Within the related “UI Policy Actions” related list, for each action where you want to run a script, check the “Run script” box.
3. This will reveal a script field where you can write your client-side JavaScript to perform dynamic actions.

Can we convert a UI Policy as a Data Policy?

Yes, ServiceNow provides a convenient feature to convert a UI Policy into a Data Policy. You typically do this by opening the UI Policy record and looking for a button or link like “Convert to Data Policy”. This process attempts to translate the UI Policy’s conditions and actions into their Data Policy equivalents.

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

While the conversion is often straightforward, there are scenarios where a UI Policy cannot be fully converted to a Data Policy:

• Controlling Data Visibility: UI Policies can hide/show fields. Data Policies primarily focus on data integrity (mandatory, read-only) and don’t directly control field visibility on the form.
• Controlling Views: UI Policies can sometimes influence which related lists are shown based on views, a capability not directly replicated in Data Policies.
• Controlling Related Lists: While Data Policies can manipulate data, controlling the visibility of entire related lists is more of a UI-specific action.
• Controlling Scripts: UI Policies can trigger complex client-side scripts. While Data Policies can have server-side scripts, direct translation of all client-side UI policy scripts might not be feasible or appropriate.

What are Data Policies?

Data Policies are a powerful tool for enforcing data integrity. Unlike UI Policies that operate on the client-side and affect the user interface, Data Policies work on both the client and server sides. They ensure that data entered into your ServiceNow instance is consistent and adheres to business rules, regardless of how it’s entered (e.g., via form, API, import set). They can make fields mandatory, read-only, or hidden, and their enforcement is guaranteed on both the client and server.

This comprehensive overview covers many of the top questions frequently encountered in the ServiceNow ecosystem. By understanding these concepts, you’ll be better equipped to manage, develop, and troubleshoot within the platform, making your ServiceNow journey more efficient and successful.