Currently, I’m actively working with the Washington DC release. It’s been exciting to leverage its latest enhancements and capabilities in our production environment.

My ServiceNow journey began with the Rome release. Since then, I’ve had the opportunity to work on and support San Diego, Tokyo, Utah, Vancouver, and now Washington DC.

Absolutely, we can add permissions to users and groups in ServiceNow. Permissions are managed through Roles. While you can assign roles directly to individual users, the best practice is to assign roles to groups. This approach significantly simplifies administration. When an employee joins a team or changes roles, you simply add or remove them from the relevant group, and their permissions are updated automatically. This prevents orphaned roles and ensures consistency, especially when employees leave the organization – removing them from a group instantly revokes all associated permissions.

The user table in ServiceNow is named sys_user.

The table that links users to groups is called sys_user_grmember. This table contains records showing which user belongs to which group.

We can create a user account programmatically using GlideRecord. Here’s a typical example:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Corrected field name
userGr.last_name = 'Doe';   // Corrected field name
userGr.email = 'jdoe@example.com';
userGr.password = gs.generatePassword('Password123!'); // Example of setting a password securely
userGr.active = true; // Ensure the user is active
userGr.insert(); // Saves the new record to the database
        

When creating users via script, remember to set essential fields like username, name, email, and ensure they are active. For production environments, consider how you’ll handle password management securely.

Creating a group via script is also done using GlideRecord. The manager field typically requires the sys_id of a user record.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual user sys_id
newGr.email = 'testingteam@example.com';
newGr.description = 'This group is for testing purposes.';
newGr.insert();
        

Permissions are granted by associating Roles. When you assign a role to a user or group, new records are created in specific tables:

• To a User: Roles are assigned to users via the sys_user_has_role table.
• To a Group: Roles are assigned to groups via the sys_group_has_role table.

Here’s how you can script this:

Adding a Role to a User:

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

Adding a Role to a Group:

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

Troubleshooting Note: Always ensure you are using the correct sys_id for both users, groups, and roles. You can find these by right-clicking on a record’s header and selecting “Copy sys_id”.

User delegation in ServiceNow allows one user to perform tasks on behalf of another user. This is invaluable when a user is unavailable due to vacation, leave, or extended absence. The delegated user gains the necessary permissions to act on behalf of the original user, ensuring critical processes like approvals, notifications, and task assignments continue without interruption. You can configure delegation by going to the original user’s record, scrolling down to the ‘Delegates’ related list, and specifying the delegate, the date range, and the specific permissions (assignments, notifications, approvals) they can exercise.

We manage group membership using the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // User's sys_id
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Group's sys_id
grMem.insert();
        

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // User's sys_id
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Group's sys_id
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord(); // Removes the specific membership record
}
        

Troubleshooting Tip: If a user isn’t being added or removed as expected, double-check the sys_ids and ensure you’re querying the correct table.

ServiceNow has had several user interfaces over the years. The primary ones you’ll encounter are UI15, UI16, and the modern Next Experience UI (formerly Polaris).

A web services user account in ServiceNow is specifically created to enable external applications or systems to connect and interact with ServiceNow data via its APIs (like REST or SOAP). These users are not intended for interactive login by humans. They typically have minimal roles, often just enough to perform the required API operations. The key characteristic is that they cannot log in to the standard ServiceNow user interface.

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

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

On the server-side, you can use gs.getUser().isMemberOf(‘group_name_or_sys_id’);. This method returns true if the user is a member of the specified group and false otherwise. You can use either the group’s name or its sys_id.

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

Impersonation in ServiceNow allows an administrator (or a user with the appropriate role) to temporarily log in and act as another user. This is a critical tool for troubleshooting, testing, and demonstrating functionality from a specific user’s perspective, ensuring that permissions and configurations are working as expected.

User preferences allow individual users to personalize certain aspects of their ServiceNow interface and experience. This could include things like default list columns, form layouts, or notification settings. Crucially, these changes only affect the individual user and do not have a global impact on other users or the system configuration.

An Incident is defined as any event that interrupts or reduces the quality, performance, or availability of an IT service. In simpler terms, it’s when something breaks or stops working as expected, impacting a user’s ability to perform their job. The primary goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations.

A Problem is the underlying cause of one or more incidents. If the same incident occurs repeatedly for the same user, or if multiple users report similar issues, it indicates a potential problem. Unlike incidents, which focus on restoration, problem management aims to identify the root cause of recurring incidents and prevent them from happening again. When multiple incidents stem from a single root cause, one incident is often designated as the “parent” and the others as “child” incidents, linked to the overarching problem record.

Yes, absolutely. If during the resolution of an incident, it becomes apparent that the issue is recurring or has a deeper underlying cause, support engineers can create a Problem record directly from the incident. This is a standard practice for initiating root cause analysis.

Yes, you can. If resolving an incident requires a modification to the IT infrastructure, applications, or services (e.g., a patch, a configuration update), a Change Request can be initiated from the incident. This ensures that necessary system updates are managed through a controlled process.

Using GlideRecord, we can automate the creation of incident records. Remember to use appropriate field names and populate essential information.

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8be5d94'; // sys_id of the caller
gr.category = 'inquiry'; // Example category
gr.subcategory = 'antivirus'; // Example subcategory
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the Configuration Item (CI)
gr.short_description = 'Test record created via script';
gr.description = 'This is a test incident to demonstrate script creation.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.contact_type = 'script'; // Setting contact type
gr.insert();
        

Troubleshooting: Ensure the sys_ids for caller_id, cmdb_ci, and assignment_group are valid and active.

Creating a Problem record via script follows the same GlideRecord pattern:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8be5d94'; // sys_id of the caller
gr.category = 'inquiry'; // Example category
gr.subcategory = 'antivirus'; // Example subcategory
gr.cmdb_ci = 'affd3c8437201000deeabfc8be5dc3'; // sys_id of the CI
gr.short_description = 'Test problem record using script';
gr.description = 'This problem record was created to demonstrate scripting.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();
        

Automating the creation of Change Requests can streamline processes. Here’s a script example:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry'; // Example category
gr.subcategory = 'antivirus'; // Example subcategory
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI
gr.short_description = 'Test change request using script';
gr.description = 'This change request was generated via a script.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.type = 'normal'; // Example change type (e.g., normal, standard, emergency)
gr.insert();
        

Interview Note: When discussing change requests, be prepared to talk about different change types (Normal, Standard, Emergency) and their associated workflows.

This can be achieved using an After Business Rule on the incident table.

Table: Incident

When to run: After Update

Condition: current.state.changesTo(7) && current.parent == ” (Assuming state ‘7’ is ‘Closed’. Adjust if your state values differ. The second part ensures it only runs for top-level incidents being closed.)

Script:

if (current.state == 7) { // Ensure it's the closed state
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for incidents where 'parent' field matches the current incident's sys_id
    grChild.query();

    while (grChild.next()) {
        // Only close child incidents if they are not already closed
        if (grChild.state != 7) {
            grChild.state = 7; // Set the state to Closed
            grChild.work_notes = 'Automatically closed as parent incident was closed.'; // Add work notes for audit
            grChild.update(); // Update the child incident
        }
    }
}
        

Troubleshooting: Always verify the correct state value for “Closed” in your instance. Test this thoroughly with different scenarios (e.g., children already closed, children in specific states).

This is a perfect use case for a Before Business Rule to abort the update if conditions aren’t met.

Table: Incident

When to run: Before Update

Condition: current.state.changesTo(7) (Again, assuming ‘7’ is the ‘Closed’ state. This rule would need to be applied to Problem and Change Request tables with their respective task tables as well.)

Script:

// For Incident
if (current.state == 7) {
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    grTask.addQuery('state', '!=', 3); // Assuming '3' is the state value for 'Closed' in incident_task
    grTask.query();

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

// Note: Similar logic would be implemented for Problem (checking 'problem_task') and Change Request (checking 'change_task')
// in their respective Before Business Rules.
        

Interview Note: Emphasize the use of current.setAbortAction(true); to stop the operation and gs.addErrorMessage() to provide user feedback.

This is best handled by an After Business Rule on the problem table.

Table: Problem

When to run: After Update

Condition: current.state.changesTo(7) (Assuming ‘7’ is ‘Closed’)

Script:

if (current.state == 7) { // Ensure it's the closed state
    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link to the problem's sys_id
    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.work_notes = 'Automatically closed as the associated problem was closed.';
        grIncident.update(); // Update the incident
    }
}
        

These three processes are interconnected components of IT Service Management (ITSM), often following ITIL best practices:

• Incident Management: Focuses on restoring normal service operation as quickly as possible to minimize the impact on business operations. It’s about fixing the immediate symptom.
• Problem Management: Aims to identify the root cause of recurring incidents and prevent them from happening again. It’s about addressing the underlying issue.
• Change Management: A structured process to ensure that all changes to IT services are managed in a controlled way to minimize risk and disruption. Changes are often implemented to resolve problems or improve services.

The typical flow: A user reports an Incident. If this incident (or similar ones) occurs repeatedly, a Problem is identified to find the root cause. Once the root cause is known, a Change Request is created to implement a permanent fix or improvement, thereby preventing future incidents related to that problem.

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

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

Tables starting with x_ usually indicate tables created within a scoped application, while tables starting with u_ were historically used for global custom tables (though scoped apps are now preferred).

Base tables are foundational tables in ServiceNow’s data model that other tables extend. They don’t typically extend any other table themselves but serve as parent tables for many others. Examples include:

• task: The parent table for incidents, problems, changes, and other task-based records.
• cmdb_ci: The base table for all Configuration Items.
• sys_user: The base table for user information.

As mentioned, the task table is a base table. Tables that extend the task table are considered task tables. Common examples include:

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

When you create a new table in ServiceNow and select the option to create default Access Control Lists (ACLs) – which is typically checked by default – ServiceNow automatically generates four fundamental ACLs:

• Read
• Write
• Create
• Delete

These provide a basic level of security. If you uncheck this option during table creation, you’ll need to manually configure all necessary ACLs.

To create a field like the incident number, which is an auto-numbering field, you need to configure it in the field’s dictionary entry. When defining the field, you’ll select the ‘Number’ field type and then go to the ‘Control’ tab. Here, you’ll specify a Prefix (e.g., ‘INC’ for incidents) and the Number of digits. You also need to ensure the ‘Auto number’ checkbox is enabled for that field.

Troubleshooting: If auto-numbering isn’t working, double-check the ‘Auto number’ checkbox and ensure the prefix and number of digits are correctly configured in the field’s dictionary entry.

When you extend a table (i.e., create a child table that inherits from a parent table), the child table automatically inherits all the fields from its parent. This means you don’t need to redefine those fields in the child table. System fields like sys_id, sys_created_on, etc., are not duplicated in the child table; they are inherently available from the parent. A special field called class is created in the parent table to track which specific table a record originates from. If a table extends multiple other tables (which is less common and often points to a potential design issue), it still only has one class field pointing to its direct parent.

Certainly! Here are 10 common ServiceNow field types:

1. Reference: Links to a record in another table.
2. String: For text input.
3. List: Allows selection of multiple records from another table (e.g., a list of groups).
4. Choice: A dropdown list with predefined options.
5. Email: For email addresses, often with validation.
6. Date/Time: For storing date and time values.
7. Date: For storing only date values.
8. Boolean: A true/false (checkbox) field.
9. Integer: For whole numbers.
10. Journal: For multi-line text entries, often with history (e.g., Work Notes, Additional Comments).
11. Attachment: Allows users to upload files.

The key difference lies in data retention:

• Normal Tables: Store data permanently until it’s explicitly deleted. These are for core operational data that needs to persist.
• Temporary Tables: Designed to store data for a limited period, typically 7 days. They often extend the import_set_row table and are commonly used for staging data during import processes. After the retention period, the data is automatically purged.

Yes, you can. While temporary tables have a default retention of 7 days, you can extend this using Archive Rules. By configuring archive rules, you can specify how long data should be retained before being moved to an archive table or purged, effectively customizing the lifecycle of data in temporary tables beyond the default.

The core distinction is where the data resides and how it’s accessed:

• Normal Tables: Data is stored directly within your ServiceNow instance’s database. When you query a normal table, you’re accessing data that is physically present in your instance.
• Remote Tables: These tables are not stored within your ServiceNow instance. Instead, they represent data that resides in an external data source. When you interact with a remote table (e.g., query it), ServiceNow retrieves the data live from that external system. This is commonly used for integrations where real-time data from another application is needed within ServiceNow without duplicating it.

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

• One-to-Many Relationship: In this common scenario, one record in a parent table can be associated with multiple records in a child table, but each record in the child table is associated with only one parent record.
  
  Example: A User (parent) can have multiple Incidents (child). Each incident is typically assigned to one user, but that user can be assigned many incidents. This is implemented by having a reference field in the child table pointing to the parent.
• One-to-One Relationship: Less common, this occurs when one record in a parent table is associated with exactly one record in a child table, and vice versa.

  Example: Imagine a custom table for ‘User Preferences’ that extends sys_user. Each user would have exactly one corresponding preference record.

• Many-to-Many Relationship: This is achieved through a “junction” or “linking” table. Records in Table A can be related to multiple records in Table B, and records in Table B can be related to multiple records in Table A.

  Example: Incidents and Groups. An incident might require involvement from multiple groups (e.g., Network team, Server team), and a group (like the Network team) might be involved in many different incidents. This is typically managed using a table like sys_user_group.list and a table that links them, often implicitly through a many-to-many field type or explicitly via a linking table.

You can create records in ServiceNow tables through several methods:

1. Forms: The most common way, directly filling out a form on a record producer or a table list/view.
2. Scripts: Using GlideRecord in Business Rules, Script Includes, Scheduled Jobs, etc.
3. Record Producers: A type of form that creates records in specific tables, often used in the Service Portal.
4. Email: Incoming email can be configured to create or update records.
5. Import Sets: For bulk data loading from external sources (e.g., CSV, Excel).
6. External Systems (APIs): Via REST or SOAP APIs, allowing other applications to create records.
7. Workflow Activities: Automated creation of records as part of a workflow.

There are several ways to enforce mandatory or read-only states for fields:

1. Dictionary Properties: Directly on the field’s dictionary entry, you can set “Mandatory” and “Read only” checkboxes. These are the most basic and often server-side enforced.
2. Dictionary Overrides: Used to alter the behavior of a field inherited from a parent table for a specific child table. You can override mandatory or read-only settings here.
3. UI Policies: These are client-side scripts that can make fields mandatory, read-only, visible, or hidden based on certain conditions. They are dynamic and update in real-time on the form.
4. Data Policies: Similar to UI Policies but can execute on both client and server sides, ensuring data integrity regardless of how the record is accessed.
5. Client Scripts (g_form): You can use g_form.setMandatory(‘field_name’, true/false); and g_form.setReadOnly(‘field_name’, true/false); within client scripts for more complex conditional logic.

Troubleshooting: If a field isn’t behaving as expected (e.g., mandatory when it shouldn’t be), check all these places. UI Policies and Data Policies often override dictionary settings for client-side behavior.

No, you should not make two fields display in one table. ServiceNow has a specific mechanism for “Display” fields. Only one field in a table can be marked as the “Display” field in its dictionary entry. When a field is marked as display, its value is used in related list entries, and in some other contexts, to represent the record. Having multiple display fields would lead to ambiguity and confusion in how records are represented.

All table definitions in ServiceNow are stored in the sys_db_object table. This meta-data table contains information about every table in the system, including its name, label, and other configuration details.

You can set a default value for a field in its dictionary entry. When you navigate to the field’s dictionary configuration, there’s a field specifically for Default value. When a new record is created and the form loads, this value will automatically populate the field. This is useful for common scenarios, like setting the ‘Contact Type’ to ‘Self-service’ for portal submissions or setting a default assignment group.

Troubleshooting: If a default value isn’t appearing, ensure it’s correctly entered in the dictionary entry. Also, check if a Business Rule or UI Policy is overwriting the default value after the record is loaded.

The current object is a globally available object in ServiceNow’s server-side scripting environments (like Business Rules, Script Includes, etc.). It represents the record that is currently being processed by the script. You use it to get and set values on that specific record.

You use the current object’s methods:

• current.setValue(‘field_name’, value);: This is the primary method to set a field’s value. For reference fields, you typically provide the sys_id of the referenced record as the value.
• current.setDisplayValue(‘field_name’, value);: This method is useful for setting values that are human-readable, especially for reference fields. You can provide the display value directly (e.g., the user’s name instead of their sys_id), and ServiceNow will try to find the corresponding sys_id.

Example:

// Setting a string field
current.setValue('short_description', 'Issue resolved.');

// Setting a reference field (e.g., caller_id) using sys_id
current.setValue('caller_id', 'a1b2c3d4e5f678901234567890abcdef');

// Setting a reference field using display value
current.setDisplayValue('caller_id', 'Abel Tuter');
        

Troubleshooting: If setValue isn’t working for a reference field, ensure you are passing the correct sys_id. If setDisplayValue fails, it might be because the display value provided doesn’t uniquely match a record in the referenced table.

Reference Qualifiers are conditions applied to reference or list fields to filter the records that can be selected. They ensure that users only see relevant choices, improving usability and data integrity.

There are three main types:

a) Simple Reference Qualifier

Description: This is the most basic type, allowing you to define a fixed query using standard ServiceNow query syntax (like AND, OR, or simple field conditions). It’s ideal for static filtering.

How to Use: You define the conditions directly in the “Reference qualifier” field on the reference field’s dictionary entry. These conditions act like the .addQuery() and .addEncodedQuery() methods in scripting.

Example: To show only active users in a ‘Caller’ field on an incident form:

active=true
        

Or for a more complex condition:

state=1^assignment_group=a715cd759f2002002920bde8132e7018
        

b) Dynamic Reference Qualifier

Description: This type uses a “Dynamic Filter Option” which is a pre-configured set of conditions that can adapt based on the context of the form or user. It provides more flexibility than simple qualifiers without requiring custom scripting.

How to Use: You first define a Dynamic Filter Option in System Definition > Dynamic Filter Options. Then, you select this option from a dropdown in the “Reference qualifier” field on the dictionary entry.

Example: You could create a Dynamic Filter Option to show only CIs that are owned by the currently logged-in user’s department.

c) Advanced Reference Qualifier (JavaScript Reference Qualifier)

Description: This is the most powerful type, allowing you to use custom JavaScript code to define complex filtering logic. It can evaluate current form values, user context, and perform intricate calculations to determine which records to display.

How to Use: You select “Advanced” in the “Reference qualifier” field and then write JavaScript code that returns an encoded query string. This code often uses the javascript: prefix.

Example: To show only incidents assigned to the current user’s assignment group and with a priority less than 3:

javascript: 'assignment_group=' + gs.getUser().getDefaultAssignmentGroup() + '^priorityIN1,2'
        

Or a more complex example:

javascript: 'stateIN1,2,3^caller_id=' + g_user.userID + '^company=' + g_user.company
        

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic can adapt based on pre-defined dynamic filter options. Dynamic offers more flexibility than simple without scripting.
• Dynamic vs. Advanced: Dynamic uses pre-configured options. Advanced uses custom JavaScript, offering the highest level of customization and the ability to incorporate complex logic, user context, and real-time calculations.
• Simple vs. Advanced: Simple is for straightforward, static queries. Advanced is for complex, dynamic, and context-aware filtering that requires custom code.

Troubleshooting: When a reference qualifier isn’t working as expected, use the browser’s developer tools (console) to inspect network requests or check the ServiceNow logs for errors related to script execution.

Dependent values in a ServiceNow dictionary entry are used to create cascaded dropdowns. This means the choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This is commonly seen with Category and Subcategory fields.

Steps to Configure Dependent Values:

1. Identify Parent and Dependent Fields: For example, ‘Category’ as the parent and ‘Subcategory’ as the dependent.
2. Configure Parent Field: Ensure the parent field (e.g., Category) has a defined list of choices.
3. Configure Dependent Field: In the dictionary entry for the dependent field (e.g., Subcategory), you’ll set the Dependent Field attribute to the name of the parent field.
4. Link Choices: Within the choices for the dependent field, you associate each choice with a specific value from the parent field.

Example:

• Parent Field: Category (Values: Hardware, Software, Network)
• Dependent Field: Subcategory (dependent on Category)

Choices for Subcategory would be configured like this:

• If Category = Hardware: Laptop, Desktop, Printer
• If Category = Software: Operating System, Application, Database
• If Category = Network: Router, Switch, Firewall

This ensures that when a user selects “Hardware” for Category, only “Laptop”, “Desktop”, or “Printer” appear in the Subcategory dropdown.

A calculated value refers to a field whose value is not entered directly by a user but is automatically computed based on other fields or logic. This is typically achieved in ServiceNow through a few mechanisms:

• Calculated Fields in Dictionary: For some field types, you can define a formula or script in the dictionary entry that calculates the field’s value. For instance, a ‘Duration’ field might be calculated from ‘Start Date/Time’ and ‘End Date/Time’.
• Business Rules: A common way to calculate field values is using a Business Rule that runs on insert or update. This rule can use the current object to perform calculations based on other fields and then use current.setValue() to populate the calculated field.
• UI Policies/Client Scripts: For real-time calculations on the form, UI Policies or Client Scripts can be used.

Essentially, a calculated value field’s content is derived, not directly input.

Attributes are special key-value pairs that can be added to field dictionary entries (and collection entries) to modify their behavior or appearance on the ServiceNow platform. They provide a way to configure fields without writing extensive scripts.

Some common attributes I’ve used include:

• no_email: Prevents email notifications from being triggered for changes to this field. Useful for fields that are updated by scripts and shouldn’t generate noise.
• no_attachment: Hides the attachment icon for this field (though typically attachments are associated with the form/record, not individual fields).
• no_add_me: Applicable to list collectors, it removes the “Add Me” button.
• tree_picker: Changes the behavior of a reference field to display as a tree structure, often used for hierarchical data like CMDB or knowledge categories.
• ref_auto_completer=false: Disables the auto-complete functionality on a reference field.
• ref_ac_columns=display_column1,display_column2: Specifies which columns should be displayed in the auto-complete suggestions for a reference field.

A collection field is not a field in the traditional sense, but rather a dictionary entry that represents the table itself. When you create a table, ServiceNow automatically generates a dictionary entry for that table. Any attributes or properties set on this collection entry (like the ‘Read only’ checkbox or specific attributes) apply to the entire table, not to a single field within it.

Example: An attribute like no_attachment applied to the collection entry of the incident table would disable attachments for all incidents.

You can control the ability to add attachments to records of a specific table using an attribute on the table’s collection field. To disable attachments for a table, you add the no_attachment attribute to the collection entry of that table. Conversely, if you needed to ensure attachments were enabled (which is the default), you wouldn’t add this attribute. This attribute is set in the dictionary entry where the “Type” is identified as a “Collection”.

Dictionary Overrides are used to modify the behavior or properties of a field that is inherited from a parent table for a specific child table. They allow you to tailor a field’s definition without altering the original OOTB field in the base table.

You can override many properties of a field, including:

• Default Value: Set a different default value for the field in the child table.
• Mandatory: Make a field mandatory (or un-mandatory if it was mandatory in the parent).
• Read only: Make a field read-only (or editable if it was read-only in the parent).
• Max Length: Adjust the maximum length of a string field.
• Display Value: Change which field is the display value for a reference field.
• Reference Specification: Modify the reference qualifier or the referenced table.
• Choice List Specification: Alter the choices available for a choice field.
• Attributes: Add or remove attributes specific to the child table’s context.

Example: The Priority field on the incident table might have its default value set to ‘5’ (Low) via a dictionary override, even though the default on the parent task table might be different.

Application Menus are top-level navigation items in the ServiceNow application navigator (the left-hand menu). They act as containers for Modules. When you create an application (custom or OOTB), it gets an Application Menu. Users can then access lists, forms, reports, dashboards, and other functionalities through the modules listed under these application menus. They are the primary way users find and interact with different parts of the ServiceNow platform.

Process Flow is a visual indicator on a form that shows the current stage or state of a record within a particular workflow or lifecycle. It helps users understand where they are in a process and what the next steps might be. For example, on a Change Request form, a process flow might show stages like “New,” “Assess,” “Authorize,” “Implement,” and “Close.” It provides a clear, graphical representation of the record’s journey.

Data Lookup Rules (often configured via the “Data Lookup Rules” module or defined within dictionary entries for specific fields) are used to automatically populate field values based on the values of other fields on the form. When a user changes a field that is a trigger for a lookup rule, ServiceNow checks the rule’s conditions and, if they match, populates a target field with a predefined value. This is different from a simple default value because it’s dynamic and based on other form inputs.

Example: If a user selects a specific ‘Category’ and ‘Subcategory’ on an incident, a data lookup rule could automatically set the ‘Assignment Group’ based on that combination.

UI Policies are client-side scripts used to dynamically change the behavior of form fields. They can make fields mandatory, read-only, visible, or hidden based on specific conditions. They are a more user-friendly alternative to client scripts for many common form manipulation tasks. UI Policies execute when a form loads and when specific conditions change.

The Global checkbox in a UI Policy determines its scope. If checked, the UI Policy will apply to all views of the table. If unchecked, you can specify particular views where the UI Policy should be active. This allows for tailored form behavior across different user interfaces or custom views.

The Reverse if false checkbox in UI Policies is crucial for dynamic behavior. If checked, any actions performed by the UI Policy when its conditions evaluate to true will be reversed when the conditions evaluate to false. For example, if a UI Policy makes a field mandatory when a checkbox is selected (‘true’), and “Reverse if false” is checked, that field will become optional again when the checkbox is deselected (‘false’).

The On Load checkbox in a UI Policy determines if the UI Policy’s conditions and actions are evaluated and applied as soon as the form is loaded.

• If checked: The UI Policy runs immediately when the form opens, applying its logic based on the initial state of the form fields.
• If unchecked: The UI Policy’s actions are not applied on form load. Instead, they are triggered only when a specific field value changes on the form that meets the UI Policy’s conditions.

It’s common to check “On Load” for most UI Policies to ensure consistent form behavior from the moment the user sees it.

The Inherit checkbox in a UI Policy allows the UI Policy to be applied to child tables that extend the table on which the UI Policy is defined. If checked, the UI Policy will run on records of child tables as well, provided the conditions are met. This is a powerful way to apply consistent form behavior across an inheritance hierarchy.

Yes, you absolutely can write scripts within UI Policies. To do so, you need to enable the Run scripts checkbox on the UI Policy form. Once enabled, you’ll see options to add “UI Policy Scripts” which include “On Load” and “On Change” scripts. These scripts allow for more complex logic and customization that cannot be achieved through the UI Policy’s declarative conditions and actions alone.

Yes, in many cases, you can convert a UI Policy into a Data Policy. ServiceNow provides a “Convert to Data Policy” button on the UI Policy form. This is useful because Data Policies operate on both client and server sides, ensuring data integrity regardless of the access method. The conversion process attempts to translate the UI Policy’s actions (mandatory, read-only, visible) into equivalent Data Policy rules.

While many UI Policies can be converted, there are specific scenarios where a direct conversion isn’t possible or advisable because Data Policies focus on data integrity and not UI presentation:

• Controlling Data Visibility (Show/Hide Fields): Data Policies are not designed to control whether a field is visible or hidden on a form; this is purely a UI concern.
• Controlling Views: UI Policies can sometimes influence view-specific behavior, which Data Policies do not handle.
• Controlling Related Lists: Actions related to showing or hiding related lists are UI-specific and cannot be directly translated to Data Policies.
• Controlling Scripted Actions: If a UI Policy relies heavily on complex client-side scripting within its actions (beyond simple mandatory/read-only/visibility), that scripting logic might not have a direct equivalent in Data Policy rules and might need to be handled by other server-side mechanisms (like Business Rules).

In these cases, you might need to keep the UI Policy or re-implement the UI-specific logic using other client-side tools.

Data Policies are server-side (and can also be client-side) rules that enforce data integrity by making fields mandatory, read-only, or setting their visibility based on specific conditions. The key advantage of Data Policies over UI Policies is their server-side execution, meaning they enforce data rules regardless of how a record is accessed – whether through a form, an API, or an import. They are essential for ensuring data quality across the entire platform.