This is a straightforward question to establish your current environment. For instance, if you’re on the latest stable release, you might say: “I’m currently working with the Washington DC release. It’s been great to experience the latest features and enhancements firsthand.”

This question helps gauge your journey and exposure to different ServiceNow iterations. A detailed answer shows progression: “My ServiceNow journey began with the Rome release. Since then, I’ve had the opportunity to work with and upgrade through San Diego, Tokyo, Utah, and Vancouver, and now I’m actively involved with Washington DC.”

Absolutely! In ServiceNow, permissions are primarily managed through Roles. You can assign roles directly to individual users or, more effectively, to groups. When a user is a member of a group, they inherit the roles assigned to that group.

Best Practice: The recommended approach is to assign roles to groups rather than individual users. This is significantly more manageable. When an employee leaves the organization or changes roles, you simply remove them from the relevant groups, and their permissions are automatically revoked. Conversely, adding a new team member involves adding them to the appropriate groups, granting them the necessary access without individual role assignments. This minimizes the risk of orphaned roles and simplifies access reviews.

The primary table for user information in ServiceNow is sys_user.

The table that links users to groups is sys_user_grmember. This is a many-to-many relationship table.

You can create a user account programmatically using a GlideRecord object in a server-side script (like a Business Rule or Script Include).

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Initializes a new record
userGr.setValue('username', 'jdoe');
userGr.setValue('first_name', 'John');
userGr.setValue('last_name', 'Doe');
userGr.setValue('email', 'jdoe@example.com');
userGr.setValue('active', true); // Essential to make the user active
userGr.insert(); // Inserts the new record into the database
        

Similar to user creation, you use GlideRecord for group creation.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.setValue('name', 'IT Support Team');
// The manager field is a reference to a user, so you'd use their sys_id
newGr.setValue('manager', '62826bf03710200044e0bfc8bcbe5df1'); // Example sys_id
newGr.setValue('email', 'itsupport@example.com');
newGr.setValue('description', 'Handles all IT-related incidents and requests.');
newGr.insert();
        

Permissions (roles) are managed via relationship tables. For users, it’s sys_user_has_role. For groups, it’s sys_group_has_role.

Adding a Role to a User:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
// Specify the sys_id of the user and the sys_id of the role
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // User sys_id
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Role sys_id
userRole.insert();
        

Adding a Role to a Group:

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

User delegation in ServiceNow allows one user (the delegate) to perform tasks on behalf of another user (the original user). This is typically used when the original user is unavailable, such as on vacation, extended leave, or during critical periods. The delegate gains the necessary permissions to access and act upon resources that would normally be available to the original user, ensuring business continuity.

Real-world Example: Imagine an IT manager who needs to approve numerous change requests daily. If they go on vacation, they can delegate their approval responsibilities to a senior team lead. The team lead can then log in (or perform actions that appear as if the manager is doing them) and approve/reject requests, keeping workflows moving smoothly.

How it’s set up: This is configured within the original user’s record. Scroll down to the ‘Delegates’ related list. Here, you can specify the delegate’s name, the start and end dates for the delegation period, and crucially, what actions they are permitted to perform on behalf of the original user (e.g., assignments, notifications, approvals).

You’ll use the sys_user_grmember table for this.

Adding a Group Member:

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

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
// Query for the specific user-group membership
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // User sys_id
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Group sys_id
grMem.query(); // Execute the query

if (grMem.next()) { // Check if a record was found
    grMem.deleteRecord(); // Delete the found record
}
        

ServiceNow has evolved its user interfaces over time. Historically, you might have encountered UI15 and UI16. The current and modern interface is the Service Portal for end-users and the Now Experience UI (sometimes referred to as the “Next Experience UI”) for administrators and fulfillers, which offers a streamlined and intuitive design.

A “web services user” (or more accurately, an integration user or system user) is an account specifically created to facilitate programmatic access to ServiceNow from external applications or systems via its web services APIs (like REST or SOAP). These users typically:

• Do not have credentials to log in to the ServiceNow graphical user interface (GUI).
• Are assigned specific roles that grant them permissions to read, write, or execute data and operations necessary for the integration.
• Are crucial for automated data exchange and process integration between ServiceNow and other enterprise systems.

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

var currentUserId = g_user.userID;
gs.info('Current User Sys ID (Client-side): ' + currentUserId); // Note: gs.info is server-side, but this shows variable access
// In a client script, you'd typically use it like:
// alert('Your User ID is: ' + g_user.userID);
        

On the server-side (e.g., in 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);
        

Again, this is done on the server-side using gs.getUser() and its isMemberOf() method:

// Replace 'Your Group Name' with the actual name of the group
if (gs.getUser().isMemberOf('IT Support Team')) {
    gs.info('User is a member of the IT Support Team.');
    // Perform actions specific to members of this group
} else {
    gs.info('User is NOT a member of the IT Support Team.');
}

// You can also use the group's sys_id for better performance and accuracy
// var groupId = '477a05d153013010b846ddeeff7b1225';
// if (gs.getUser().isMemberOf(groupId)) { ... }
        

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

Impersonation in ServiceNow allows an administrator or a user with specific permissions to temporarily act as another user. This is an invaluable tool for troubleshooting issues from a specific user’s perspective, testing role-based access, and verifying how different configurations affect individual users without actually logging in with their credentials. You can impersonate a user by going to the User menu (usually at the top right) and selecting ‘Impersonate User’.

User preferences in ServiceNow allow individual users to customize certain aspects of their interface and experience. These preferences are personal and only affect the user who sets them. Examples include preferred language, list display settings (e.g., number of records per page), theme selection, and notification settings. These are stored in the sys_user_preference table.

Example: A user might prefer to see 50 records per page in lists, while another prefers 20. This is managed via user preferences.

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

Real-world Example: A user cannot access their email. This is an incident that needs immediate resolution to restore their ability to work.

A problem is the underlying cause of one or more incidents. The goal of problem management is to identify the root cause of incidents and to minimize the recurrence of incidents. If the same issue (incident) is happening repeatedly for a single user, or if it’s affecting multiple users, it points to an underlying problem that needs to be investigated and resolved.

Relationship with Incidents: Often, a problem record is created to investigate a recurring or widespread incident. Multiple incidents can be linked to a single problem. Once the root cause is found and a workaround or fix is implemented, all associated incidents can be resolved.

Example: If multiple users report intermittent network connectivity issues (incidents), a problem investigation might reveal a faulty router as the root cause.

Yes, absolutely. This is a standard practice in ITSM. If a support engineer identifies that an incident is recurring or potentially has a broader impact, they can create a related Problem ticket directly from the Incident form. This initiates the root cause analysis process.

Yes. If resolving an incident requires making a modification to the IT infrastructure or an application (e.g., applying a patch, reconfiguring a server), a Change Request is created from the Incident. This ensures that the change is properly assessed, approved, scheduled, and implemented in a controlled manner, minimizing the risk of introducing new incidents.

Using GlideRecord on the incident table:

var gr = new GlideRecord('incident');
gr.initialize();
gr.setValue('caller_id', '86826bf03710200044e0bfc8bcbe5d94'); // Sys ID of the caller
gr.setValue('category', 'inquiry');
gr.setValue('subcategory', 'antivirus');
gr.setValue('cmdb_ci', 'affd3c8437201000deeabfc8bcbe5dc3'); // Sys ID of Configuration Item
gr.setValue('short_description', 'User reporting slow performance on laptop.');
gr.setValue('description', 'The user has been experiencing significant slowdowns for the past two days. Applications are taking a long time to load.');
gr.setValue('assignment_group', 'a715cd759f2002002920bde8132e7018'); // Sys ID of the assignment group
gr.insert();
        

Similar to incidents, using GlideRecord on the problem table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.setValue('caller_id', '86826bf03710200044e0bfc8bcbe5d94');
gr.setValue('category', 'software');
gr.setValue('subcategory', 'os_patching');
gr.setValue('cmdb_ci', 'affd3c8437201000deeabfc8be5dc3');
gr.setValue('short_description', 'Frequent application crashes after recent OS update.');
gr.setValue('description', 'Multiple users are reporting application crashes following the deployment of the latest operating system patches. Root cause needs to be identified.');
gr.setValue('assignment_group', 'a715cd759f2002002920bde8132e7018');
gr.insert();
        

Using GlideRecord on the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.setValue('category', 'standard'); // Example category
gr.setValue('type', 'normal'); // Example type
gr.setValue('cmdb_ci', 'affd3c8437201000deeabfc8be5dc3');
gr.setValue('short_description', 'Apply security patch to Web Servers.');
gr.setValue('description', 'Applying a critical security patch to all web servers in the production environment to address CVE-XXXX-YYYY.');
gr.setValue('assignment_group', 'a715cd759f2002002920bde8132e7018');
// For change requests, you often need to set start/end dates, risk, etc.
gr.setValue('start_date', '2023-10-27 22:00:00');
gr.setValue('end_date', '2023-10-28 02:00:00');
gr.insert();
        

This is a perfect use case for an After Business Rule on the Incident table. We’ll trigger it when the state changes to ‘Closed’ and the incident is a parent (i.e., has no parent itself).

// Business Rule Configuration:
// Table: Incident
// When: after
// Insert: false
// Update: true
// Condition: current.state.changesTo(7) && current.parent == ''
// Script:

(function executeRule(current, previous /*null when async*/) {

    // Check if the state is 'Closed' (assuming 7 is the value for Closed)
    // and if this incident is a parent incident (no parent_incident field populated)
    if (current.state == 7 && current.parent == '') {
        gs.info('Parent incident ' + current.number + ' is closed. Closing associated child incidents.');

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

        while (grChild.next()) {
            // Set the state to Closed for the child incident
            grChild.state = 7; // Assuming 7 is the value for Closed
            // Optionally add comments or closure notes to child incidents
            // grChild.work_notes = 'Automatically closed as parent incident ' + current.number + ' was closed.';
            grChild.update();
            gs.info('Closed child incident: ' + grChild.number);
        }
    }

})(current, previous);
        

This requires a Before Business Rule on the Incident table (and similarly for Problem and Change Request tables). We want to prevent the update if conditions aren’t met.

// Business Rule Configuration:
// Table: Incident
// When: before
// Insert: false
// Update: true
// Condition: current.state.changesTo(7) // Trigger only when state is changing to Closed
// Script:

(function executeRule(current, previous /*null when async*/) {

    // Check if the state is changing to 'Closed'
    if (current.state.changesTo(7)) {
        gs.info('Checking for open incident tasks before closing incident ' + current.number);

        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id); // Link to the current incident
        // Assuming state 3 is 'Closed'. Adjust if your system uses a different value.
        grTask.addQuery('state', '!=', 3);
        grTask.query();

        if (grTask.hasNext()) {
            gs.addErrorMessage('Cannot close the incident. There are open incident tasks associated with this incident.');
            current.setAbortAction(true); // Prevent the incident from being closed
            gs.info('Aborted closing incident ' + current.number + ' due to open tasks.');
        }
    }

})(current, previous);

// For Problem and Change Request, you'd adapt this logic:
// - For Problem, query 'problem_task' table.
// - For Change Request, query 'change_task' table.
// - Use the respective sys_id field (e.g., 'problem', 'change_request') in the addQuery.
        

This is another scenario for an After Business Rule on the Problem table.

// Business Rule Configuration:
// Table: Problem
// When: after
// Insert: false
// Update: true
// Condition: current.state.changesTo(7) // Trigger when state changes to Closed
// Script:

(function executeRule(current, previous /*null when async*/) {

    // Check if the problem is being closed
    if (current.state == 7) { // Assuming 7 is the state for 'Closed'
        gs.info('Problem ' + current.number + ' is closed. Closing associated incidents.');

        // GlideRecord to find incidents associated with this problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Link incidents to the problem
        // Ensure we only close incidents that are not already closed
        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
            // Optionally add work notes
            // grIncident.work_notes = 'Automatically closed as parent problem ' + current.number + ' was resolved.';
            grIncident.update();
            gs.info('Closed incident: ' + grIncident.number + ' linked to problem ' + current.number);
        }
    }

})(current, previous);
        

These three ITSM processes are tightly interconnected and form a crucial part of IT Service Management (ITSM):

• Incident Management: Focuses on restoring normal service operation as quickly as possible after an interruption. Its primary goal is to minimize the impact on business operations.
• Problem Management: Aims to identify the root cause of recurring or significant incidents and prevent them from happening again. It’s a reactive process to incidents but proactive in preventing future ones.
• Change Management: Manages all changes to the IT infrastructure in a controlled way. The goal is to minimize the risk and disruption associated with changes.

The Flow:

1. An Incident occurs (e.g., an application is down).
2. If the incident is recurring, widespread, or complex, a Problem record is created to investigate the root cause.
3. If the resolution to the problem (or a workaround) requires a change to the IT environment (e.g., patching servers, updating configurations), a Change Request is created.
4. The Change Request is assessed, approved, and implemented.
5. Once the change is successfully implemented, the Problem and associated Incidents can be closed.

Out-of-the-box tables are those provided by ServiceNow and do not start with a custom prefix like x_ (custom applications) or u_ (legacy custom tables). Some common examples include:

• incident
• problem
• change_request
• sc_req_item (Requested Item)
• sc_catalog_item (Catalog Item)
• sys_user
• sys_user_group
• cmdb_ci (Configuration Item – base table)
• task (base table for task-based tables)
• sys_audit (for audit trail)

Base tables are fundamental tables that other tables extend. They often contain common fields that are inherited by their child tables. They are typically tables that are not extended by any other table but are extended by many.

Key examples:

• task: The base table for all task-like records (Incidents, Problems, Changes, Catalog Tasks, etc.). It provides fields like assignment group, assigned to, state, due date, etc.
• cmdb_ci: The base table for the Configuration Management Database (CMDB). It contains common fields for all Configuration Items (CIs) like name, manufacturer, model, etc.
• sys_user: While often considered an OOTB table, it’s also a base for user-related extensions if needed (though direct extension is less common).

These are tables that extend the task base table and inherit its common fields and functionality. Examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• ப்படுகின்றன_task (Knowledge Article Tasks – if applicable)
• std_change_request (Standard Change Request)

When you create a new table in ServiceNow (either OOTB or custom), and you leave the default security settings checked (typically four checkboxes related to Create, Read, Write, Delete ACLs), ServiceNow automatically generates four Access Control Lists (ACLs) for that table:

• Create ACL
• Read ACL
• Write ACL
• Delete ACL

These provide basic security, ensuring that users with appropriate roles can perform these fundamental operations. If you uncheck these boxes during table creation, these default ACLs will not be automatically generated, and you’ll need to create them manually.

Number fields like incident.number are created using the “Auto-Number” feature. When defining a table (or a field if applicable, though typically it’s table-level), you configure an “Auto-Number” entry in ServiceNow’s system:

1. Navigate to System Definition > Number Maintenance.
2. Click New.
3. Table: Select the table you want this number format for (e.g., incident).
4. Prefix: Enter a prefix if desired (e.g., INC for incidents).
5. Number of digits: Specify the desired number of digits for the sequential part (e.g., 7 for 0000001).
6. Auto-inrementing: Ensure this is checked.
7. Next number: Set the starting number (e.g., 1).

When you create a record on this table and the number field is not explicitly set, ServiceNow will automatically generate a unique number based on this configuration.

When you extend a table in ServiceNow (e.g., creating the incident table which extends the task table), the child table inherits all the fields and properties from its parent table. This is the core principle of table extension and allows for data modeling reuse. Key consequences include:

• Inherited Fields: All fields from the parent table (e.g., assigned_to, state from task for incident) are available on the child table without needing to redefine them.
• No Sys Fields in Child: System fields like sys_created_on, sys_updated_on, sys_id, etc., are NOT recreated in the child table. They reside in the actual parent table.
• ‘Class’ Field in Parent: A field named ‘class’ is automatically created in the parent table. This field stores the sys_id of the child table that the record belongs to. For example, a record in the incident table will have its sys_id from the task table’s class field pointing to the incident table.
• Single Inheritance: A table can only extend one other table directly. This is single inheritance.

Certainly! Here are 10 common field types in ServiceNow:

1. String: For short text entries.
2. Reference: To link to another record in a different table (e.g., User, Group).
3. List: A multi-reference field, allowing selection of multiple records from another table.
4. Choice: A dropdown list where administrators define the available options.
5. Date/Time: For storing both date and time information.
6. Date: For storing only the date.
7. Boolean: A true/false or checkbox field.
8. Integer: For whole numbers.
9. Journal: For storing free-form text entries, often with history (like Work Notes or Activity Log).
10. Attachment: Allows users to upload files.
11. Bonus: HTML: For rich text content.
12. Bonus: URL: For web addresses.

The distinction lies in data retention and purpose:

• Normal Tables: These are standard tables designed to store data permanently. Records in normal tables persist until they are explicitly deleted. Examples include incident, sys_user, etc.
• Temporary Tables: These tables are designed for short-term data storage. They typically extend the import_set_row table and are used for staging data during import processes or for transient data that doesn’t need to be retained long-term. Data in these tables is usually automatically purged after a set period (e.g., 7 days).

Yes, you can. While temporary tables have a default retention period, you can often extend this using Archive Rules. By configuring archive rules, you can specify criteria for when data should be archived or deleted, allowing you to manage the lifecycle of data in these tables, including extending how long it’s kept before purging.

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

• Normal Tables: Data is stored directly within the ServiceNow instance’s database. When you query a normal table, you’re retrieving data from your own instance.
• Remote Tables: These tables are defined in ServiceNow but the actual data resides in an external data source (e.g., an external SQL database, a cloud storage service). ServiceNow connects to this external source to retrieve and display the data in real-time. This allows you to leverage data from other systems within your ServiceNow interface without physically importing it.

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

• One-to-Many Relationship: This is the most common type. It means one record in Table A can be related to many records in Table B, but each record in Table B is related to only one record in Table A.
  • Example: A User (Table A) can have multiple Incidents (Table B) assigned to them. The incident.caller_id field is a reference to the sys_user table.
• One-to-One Relationship: Here, one record in Table A can be related to only one record in Table B, and vice versa. This is less common and often achieved using reference fields with specific ACLs or specific configurations.
  • Example: A User record might have a single linked record in a custom User Profile Extension table.
• Many-to-Many Relationship: One record in Table A can be related to many records in Table B, AND one record in Table B can be related to many records in Table A. This is typically implemented using a “glue” or “join” table.
  • Example: Incidents (Table A) and Groups (Table B). An incident can be assigned to multiple groups (though usually one primary assignment group), and a group can be assigned multiple incidents. The sys_user_group and incident tables don’t directly link many-to-many. Instead, a join table like sys_group_has_role (for roles) or custom relationships might manage this. A more direct example is Users and Groups, managed by the sys_user_grmember table.

You can create records in ServiceNow tables through several methods:

1. Form Submission: The most common way, filling out a form and clicking ‘Submit’ or ‘Save’.
2. Record Producers: User-friendly forms, often found in the Service Portal, that create records in backend tables.
3. Email: Inbound email actions can parse emails and create records (e.g., creating an incident from an email to support@example.com).
4. GlideRecord Scripting: Server-side scripts (Business Rules, Script Includes, Background Scripts) using GlideRecord to insert new records.
5. Import Sets / Data Sources: Importing data from files (Excel, CSV) or external systems.
6. Web Services (SOAP/REST): External applications can create records via ServiceNow’s APIs.
7. UI Actions: Custom buttons or links can trigger scripts to create related records.

There are several ways to control field behavior (mandatory, read-only, visible):

• Dictionary Entry (Field Attributes): You can set attributes like mandatory=true or readonly=true directly on the field’s dictionary definition.
• Dictionary Overrides: If a field is inherited from a parent table, you can use a dictionary override on the child table to change its properties (e.g., make it mandatory).
• UI Policies: Client-side logic that makes fields mandatory, read-only, or hidden/visible based on conditions on the form. They are executed in the browser.
• Data Policies: Similar to UI Policies but can run on both the client and server side. They enforce data constraints (mandatory, read-only) regardless of the data source (form, import, API).
• Client Scripts: Using g_form.setMandatory('field_name', true); or g_form.setReadOnly('field_name', true); for dynamic, script-driven control.
• Server-side Scripts (Business Rules): While you can’t directly make a field read-only or mandatory for form display, you can abort actions or add error messages if required conditions aren’t met, effectively controlling data integrity.

No, you should not have more than one field marked as ‘Display’ on a table. The ‘Display’ attribute on a field is used by ServiceNow to determine which field value is shown when the record is displayed in a list or as a reference. Having multiple display fields can lead to ambiguity and unpredictable behavior in how records are presented.

All table definitions in ServiceNow are stored in the sys_db_object table. This table contains metadata about each table in the instance.

You can set a default value for a field in several ways:

• Dictionary Entry: In the field’s dictionary definition, there’s a ‘Default value’ field. You can enter a static value or a simple script (e.g., javascript: gs.getUser().getDepartmentID();).
• UI Policies: You can set a default value as an action within a UI Policy.
• Client Scripts: Using g_form.setDefaultValue('field_name', 'your_default_value'); in an OnLoad Client Script.
• Business Rules: In an ‘Before’ insert Business Rule, you can set current.setValue('field_name', 'your_default_value');.

The current object is a special global object available in server-side scripts (like Business Rules, Script Includes called from Business Rules, etc.). It represents the record that is currently being processed or acted upon. You use it to:

• Get values from the current record: current.getValue('field_name');
• Set values on the current record: current.setValue('field_name', 'new_value');
• Check conditions based on the current record’s state.
• Abort actions: current.setAbortAction(true);

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

• setValue(fieldName, 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. For choice lists, provide the choice value. For strings, provide the string.

// Setting a simple string field
current.setValue('short_description', 'Updated Short Description');

// Setting a reference field (e.g., assigning to a user)
current.setValue('assigned_to', 'sys_id_of_user_to_assign');

// Setting a choice field
current.setValue('state', '2'); // Assuming '2' is the value for 'In Progress'
            

• setDisplayValue(fieldName, value): This is used to set the *display* value of a field, primarily useful for reference fields when you want to set the value using its human-readable name instead of its sys_id. However, it’s generally recommended to use setValue() with sys_ids for robustness.

// Setting a reference field using its display value (less common, use setValue with sys_id if possible)
current.setDisplayValue('caller_id', 'John Doe'); // This will look up John Doe's sys_id internally
            

Reference Qualifiers are used to filter the records that appear in a reference field or a list field. They act like a WHERE clause in SQL, restricting the choices available to the user.

Types of Reference Qualifiers:

1. Simple Reference Qualifier

Description: This is the most straightforward type. You define a static query directly in the reference qualifier field. It’s used for filtering based on fixed conditions.

How to Use: In the dictionary entry for the reference field, in the “Reference qual” field, you can enter conditions like:

active=true^department=3e2b52a30730000001058310510302d6

Example: To show only active users from a specific department in a user reference field.

Difference: It’s static; the conditions don’t change based on form context.

2. Dynamic Reference Qualifier

Description: This type uses a dynamically generated query. You configure a “Dynamic Filter Option” (under System Definition) which then gets called by the reference qualifier. This allows the filter to adapt based on the context of the current record or user.

How to Use:

1. Create a Dynamic Filter Option (System Definition > Dynamic Filter Options).
2. Define conditions within the Dynamic Filter Option.
3. In the reference field’s dictionary entry, select the “Reference qual” option and choose the “Dynamic” type, then select your created Dynamic Filter Option.

Example: Displaying only customers from the same country as the currently logged-in user.

Difference: More flexible than simple, as it can use context, but requires setup of Dynamic Filter Options.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

Description: This is the most powerful type. You write custom JavaScript code that runs on the client-side to dynamically build the query. This allows for complex logic, interactions with other fields on the form, and sophisticated filtering.

How to Use: In the reference field’s dictionary entry, select “Advanced” for the reference qualifier type and enter your JavaScript code in the “Reference qual” field. The code should return a query string.

javascript:
var deptSysId = g_form.getValue('department'); // Get value from another field on the form
var query = 'active=true';
if (deptSysId) {
    query += '^department=' + deptSysId;
}
query;
        

Example: Filtering a list of products to show only those available in the user’s selected region or belonging to the chosen category.

Difference: Offers complete scripting control for the most complex filtering needs.

Comparison:

• Simple vs. Dynamic: Simple is static. Dynamic uses predefined dynamic options which might be reusable.
• Dynamic vs. Advanced: Dynamic uses pre-configured dynamic filter options. Advanced lets you write custom JavaScript for highly specific, on-the-fly logic.
• Simple vs. Advanced: Simple is for basic, fixed conditions. Advanced is for complex, dynamic conditions requiring scripting.

Dependent values (often referred to as Dependent Fields) are used to create cascaded dropdowns. When a user selects an option in one field (the parent field), the choices available in another field (the dependent field) are automatically filtered to show only relevant options.

How it works:

1. Parent Field: Has a set of choices (e.g., Category: Hardware, Software, Network).
2. Dependent Field: Its choices are linked to the parent field’s selection.

Configuration: In the dictionary entry for the dependent field, you set the ‘Dependent field’ attribute to the name of the parent field. Then, within the ‘Choice List Specification’ for the dependent field, you define choices and link them to specific parent field values.

Example:

• Parent Field: Category (e.g., ‘Hardware’)
• Dependent Field: Subcategory (e.g., ‘Laptop’, ‘Printer’)

When a user selects ‘Hardware’ in Category, the Subcategory dropdown will only show ‘Laptop’, ‘Printer’, etc. If they select ‘Software’, Subcategory might show ‘Application’, ‘OS’, etc.

A calculated value for a field means that the field’s value is not entered directly by the user but is computed dynamically based on a script. This is configured in the field’s dictionary entry under the ‘Calculated value’ or ‘Advanced view’ section, where you can write a JavaScript expression.

Example: A field that automatically calculates the total cost by summing up values from other fields on the form.

// In the dictionary entry for the 'total_cost' field:
javascript: current.getValue('quantity') * current.getValue('unit_price');
        

Attributes are special keywords used in ServiceNow dictionary entries (for fields and tables) to modify or control the behavior of fields, forms, or the platform itself. They act like hints or instructions to the system.

Some common attributes I’ve used include:

• no_email: Prevents email notifications from being sent for changes to this field.
• no_attachment: Disables attachments for this specific field (less common, usually managed at table level).
• ref_auto_completer=true: Enables auto-completion for reference fields.
• tree_picker=true: Displays a reference field as a tree-like structure.
• max_length=...: Sets the maximum character length for a String field.
• glide_date_time: Ensures a field behaves as a date/time picker.
• mandatory=true: Makes the field mandatory (though usually set directly in dictionary properties).
• readonly=true: Makes the field read-only.
• is_month_picker=true: Makes a date field act as a month picker.

A “collection field” entry in the dictionary (sys_dictionary table) doesn’t represent a field on the table itself. Instead, it represents the table definition. When you create a table, an entry is automatically made in sys_dictionary where the ‘Element’ is blank or represents the table name, and the ‘Type’ is often ‘Collection’.

Attributes or properties set on this “collection” entry apply to the entire table, not a specific field. For example, setting the no_attachment attribute on the table’s collection entry will disable attachments for all records of that table.

To control attachments for an entire table, you apply attributes to the table’s “collection” dictionary entry (the one representing the table itself, not a specific field). The attribute to disable attachments is no_attachment.

Steps:

1. Navigate to System Definition > Dictionary.
2. Filter for the table you want to modify (e.g., incident). Look for the entry where the ‘Element’ field is empty or represents the table name.
3. Open that dictionary record.
4. In the ‘Attributes’ field, add no_attachment.
5. Save the record.

This will remove the paperclip/attachment icon from the form header for all records of that table.

Dictionary Overrides allow you to change the definition of a field that is inherited from a parent table for a specific child table. This is essential for customizing inherited fields without altering the parent table’s definition, thus respecting the principle of single inheritance and maintaining platform stability.

Example: The task table has a priority field. The incident table inherits this. If you want the default priority for incidents to be different from the default for general tasks, you create a dictionary override for the priority field on the incident table.

Properties you can override: You can override most of the properties found in a standard dictionary entry, including:

• Default value
• Mandatory (Yes/No)
• Read only (Yes/No)
• Max length
• Attributes
• Display value (though this is usually set once on the base table)
• Reference qualifier
• Dependent field
• And many others…

Application Menus (often referred to as Modules) are navigational entries that appear in the ServiceNow platform’s left-hand navigation menu. They provide users with direct access to specific lists, forms, reports, or other parts of the application. You define an Application Menu, and then create Modules under it to point to specific tables or views.

Example: The ‘Incidents’ application menu might have modules like ‘Open’, ‘Assigned to me’, ‘All’, etc., each linking to a different view or filter of the incident list.

Process Flow (or Flow Designer in modern ServiceNow) is a visual representation of the steps or stages within a business process. It helps users understand the current state of a record (like an Incident or Change Request) and what the next expected steps are. It provides a clear, guided path for users to follow, ensuring processes are executed consistently.

Example: An Incident Process Flow might show stages like ‘New’, ‘In Progress’, ‘On Hold’, ‘Resolved’, ‘Closed’.

Data Lookup Rules (found under System Policy > Rules > Data Lookup Rules) are a way to automatically populate field values on a form based on the values of other fields on that same form. They are configured by specifying a ‘Lookup From’ field, a ‘Lookup To’ field, and a mapping table that defines the relationship between the values.

Example: If you select a ‘Location’ and a ‘Department’ on a form, a data lookup rule could automatically populate the ‘Cost Center’ field based on a predefined map.

UI Policies are client-side scripts that dynamically change the behavior of form fields based on certain conditions. They are a more user-friendly alternative to traditional Client Scripts for many common UI manipulations. You can use UI Policies to make fields:

• Mandatory
• Read-only
• Hidden or Visible
• Set default values

They execute in the user’s browser.

The ‘Global’ checkbox on a UI Policy determines whether the policy applies to all views of a form or only specific views.

• Checked: The UI Policy will apply to all available views of the form.
• Unchecked: You will need to specify which view(s) the UI Policy should apply to. This allows for view-specific UI behavior.

The ‘Reverse if false’ checkbox is a powerful feature in UI Policies. When checked, it means that the actions defined in the UI Policy will be undone if the UI Policy’s condition evaluates to false.

Example: If a UI Policy makes a field mandatory when ‘Category’ is ‘Hardware’, and ‘Reverse if false’ is checked, then if the ‘Category’ is changed to anything other than ‘Hardware’, the field will become optional again (reverting the ‘mandatory’ action).

This is extremely useful for managing dynamic field states.

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

• Checked: The UI Policy runs automatically when the form initially loads.
• Unchecked: The UI Policy does NOT run when the form loads. Its actions will only trigger in response to changes made to fields on the form that affect the UI Policy’s conditions.

Use Case: If you want a field to be mandatory or hidden from the moment the form appears, you check ‘On Load’. If the behavior should only change when a user interacts with other fields, you might uncheck it.

The ‘Inherit’ checkbox on a UI Policy dictates whether the UI Policy should be applied to tables that extend the current table.

• Checked: If you apply a UI Policy to the task table and ‘Inherit’ is checked, that UI Policy will also apply to tables that extend task, such as incident, problem, and change_request, provided their conditions are met.
• Unchecked: The UI Policy will only apply to the table it’s defined on.

Yes, you can! Within a UI Policy, you can define specific actions for UI Policy Actions. For each UI Policy Action, there’s a checkbox labeled ‘Run scripts’. When you check this box, you can then write client-side JavaScript code that will execute when that specific UI Policy Action is triggered.

This allows for more complex dynamic behavior than simple show/hide or mandatory/read-only settings. For example, you could use scripts to dynamically populate other fields based on complex logic or manipulate related lists.

Yes, you generally can convert a UI Policy into a Data Policy. ServiceNow provides a built-in conversion tool. You would typically:

1. Navigate to the UI Policy you want to convert.
2. Find an option (often a related link or button) like “Convert to Data Policy”.
3. Clicking this will create a new Data Policy with equivalent logic.

Why Convert? Data policies offer server-side execution, ensuring data integrity regardless of how the data is entered (form, import, API). UI policies are client-side only.

While the conversion is powerful, there are limitations. A UI policy cannot be directly converted into a data policy if it relies heavily on client-side-only interactions or functionalities that don’t have a direct server-side equivalent. Specific cases include:

• Controlling Data Visibility (UI Specific): UI Policies can directly hide/show fields or make them read-only purely for the UI. While Data Policies can make fields read-only or mandatory, they don’t “hide” fields from the data model itself.
• Controlling Views: UI Policies can sometimes be used to manipulate view-specific elements or related lists, which are UI constructs not directly managed by Data Policies.
• Controlling Related Lists: Displaying or hiding related lists is a UI behavior. Data Policies focus on field-level data constraints.
• UI Policy Scripts with Purely Client-Side Logic: If a UI Policy’s script performs actions that have no server-side equivalent (e.g., complex DOM manipulation, browser-specific alerts not handled by gs.addErrorMessage), direct conversion might not be possible or might require significant refactoring.

Data Policies are server-side (and optionally client-side) rules that enforce data integrity by making fields mandatory, read-only, or hidden. Unlike UI Policies, which only affect the form’s user interface, Data Policies enforce these constraints regardless of how the data is entered – whether through a form, an import, or an API call. They are crucial for maintaining data accuracy and consistency across the platform.

Key Features:

• Server-side Execution: Ensures data validation happens at the database level.
• Client-side Option: Can be configured to run on the client as well, providing a smoother user experience by enforcing rules as the user types.
• Mandatory, Read-only, Hidden: Control field requirements and accessibility.