As of my current knowledge and experience, I’ve been actively working with the Washington DC release, which is the latest one. I always strive to stay updated with the most recent features and enhancements ServiceNow offers.

My ServiceNow journey began with the Rome release. Since then, I’ve had the opportunity to work with subsequent versions including San Diego, Tokyo, Utah, Vancouver, and most recently, Washington DC. This progression has given me a good perspective on the platform’s evolution.

Absolutely. In ServiceNow, permissions are primarily managed through Roles. You can assign roles directly to individual users or to groups. The best practice, without a doubt, is to manage permissions through groups. This is a critical aspect of good governance. When an employee leaves an organization, or their role changes, you simply remove them from the relevant group(s). This automatically revokes all the roles and associated permissions they inherited from that group, significantly simplifying user lifecycle management and reducing the risk of orphaned permissions. Assigning roles directly to users can quickly become unmanageable.

The primary table for user information in ServiceNow is sys_user.

The table that links users to groups, essentially representing group membership, is sys_user_grmember.

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

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Correct field name is first_name
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.active = true; // Always good practice to set active status
userGr.insert();
        

Similar to user creation, you can create a new group using GlideRecord on the sys_user_group table:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team'; // More descriptive name
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual sys_id of a user
newGr.email = 'testing@example.com';
newGr.description = 'This group handles testing activities.';
newGr.insert();
        

Permissions are managed via roles. Adding a role to a user creates a record in the sys_user_has_role table. For groups, it’s the sys_group_has_role table.

To a User:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize(); // Initialize to add a new record
userRole.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
userRole.role = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role
userRole.insert();
        

To a Group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize(); // Initialize to add a new record
grpRole.group = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group
grpRole.role = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role
grpRole.insert();
        

User delegation in ServiceNow allows one user to perform tasks and manage approvals on behalf of another user. This is incredibly useful when a user is out of office, on vacation, or otherwise unavailable. The delegated user gains the necessary permissions to access resources and act within the scope of the original user. It ensures critical workflows don’t halt due to absences.

For instance, an employee going on leave can delegate their approval responsibilities to a colleague. This is configured within the original user’s account profile by navigating to ‘Delegates’ and specifying the delegate, the duration of delegation (start and end dates), and the types of actions they can perform (assignments, notifications, approvals).

This involves manipulating records in the sys_user_grmember table.

Adding a Group Member:

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

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys_id of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Sys_id of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord(); // Delete the specific membership record
}
        

ServiceNow has evolved its user interfaces over time. The main ones you’ll encounter are UI15, UI16 (which is still widely used), and the more modern Next Experience UI (often referred to as Polaris). Each offers a different look and feel, and the Next Experience UI provides a more streamlined and intuitive user experience.

A “web services user” in ServiceNow is typically an account designated for integration purposes. This type of user account allows external applications to connect to ServiceNow and interact with its data via web services (like REST or SOAP) without needing to log in through the standard user interface. Crucially, these users generally cannot log in to the ServiceNow instance as a regular end-user. They are strictly for programmatic access, ensuring secure and automated data exchange.

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

var currentUserId = g_user.userID;
console.log("Current User ID: " + currentUserId);
        

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

var currentUserId = gs.getUserID();
gs.info("Current User ID: " + currentUserId);
        

Again, on the server-side, you can use the gs.getUser() object:

// For server-side scripts (e.g., Business Rules, Script Includes)
var isMember = gs.getUser().isMemberOf('group_name'); // Replace 'group_name' with the actual group name or sys_id

if (isMember) {
    gs.info("User is a member of the specified group.");
} else {
    gs.info("User is NOT a member of the specified group.");
}

// For client-side scripts, you would typically use g_user.hasRole() or check group membership via a server-side call (e.g., GlideAjax)
// g_user.hasRole('role_name') is for checking roles, not direct group membership. For group membership client-side, GlideAjax is preferred.
        

To create, modify, or manage Access Control Lists (ACLs) in ServiceNow, you need the security_admin role. This is a highly privileged role and should be assigned with care.

Impersonation in ServiceNow is a powerful feature that allows an administrator (or a user with the ‘admin’ role) to log in and operate as another user. This is invaluable for testing purposes, troubleshooting user-specific issues, and verifying permissions without having to share login credentials. You can access impersonation from the user menu at the top right of the platform.

User preferences are settings that individual users can configure to customize their ServiceNow experience. These settings are specific to each user and do not affect other users on the platform. Examples include personalizing the notification settings, preferred language, theme, or default list columns. These are stored in the sys_user_preference table.

An incident, in ServiceNow terms, represents an unplanned interruption to an IT service or a reduction in the quality of an IT service. Its primary goal is to restore normal service operation as quickly as possible with minimal business impact. Think of it as something breaking unexpectedly that needs immediate attention to get things running again.

A problem is the underlying cause of one or more incidents. While an incident focuses on restoring service, a problem focuses on identifying the root cause of recurring incidents and finding a permanent solution or workaround. If the same issue keeps happening, it’s likely a problem we need to investigate. In ServiceNow, a problem record can be linked to multiple incidents (which can then be categorized as “parent” and “child” incidents for reporting and management purposes).

Yes, absolutely. If a support engineer investigates an incident and determines that the issue is recurring or has a deeper underlying cause that needs to be investigated separately, they can create a problem record directly from that incident. This links the incident to the problem, initiating the problem management process.

Yes, we can. If resolving an incident requires a modification to the IT infrastructure or an application (e.g., deploying a patch, reconfiguring a server), a change request can be created directly from the incident. This ensures that necessary changes are properly planned, approved, and executed without introducing new risks.

Using GlideRecord on the incident table is the standard way to do this:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e05d94'; // Sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of a Configuration Item
gr.short_description = 'Antivirus definition update failed on user workstation';
gr.description = 'User reported that the antivirus definitions are not updating automatically.';
gr.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.reported_by = '86826bf03710200044e0bfc8be5d94'; // Sys_id of the reporter
gr.category = 'software';
gr.subcategory = 'application_error';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bebe5dc3'; // Sys_id of a Configuration Item
gr.short_description = 'Repeated application crashes on critical software';
gr.description = 'Multiple users are reporting frequent crashes of the financial reporting application.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
gr.insert();
        

Using GlideRecord on the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'software';
gr.subcategory = 'patch_management';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of a Configuration Item
gr.short_description = 'Deploy critical security patch for Application X';
gr.description = 'This change request is to deploy a recently released security patch for Application X to address vulnerability CVE-XXXX-XXXX.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
gr.type = 'normal'; // e.g., normal, standard, emergency
gr.insert();
        

This is a perfect use case for an After Business Rule on the incident table. It should trigger on update when the state changes to closed.

Business Rule Configuration:

• Table: Incident
• When to run: After update
• Filter Conditions: State changes to Closed (or your equivalent closed state value) AND Parent is empty

Script:

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

    // Check if the current incident is closed and it's a parent incident (no parent specified)
    if (current.state == 7 && current.parent == '') { // Assuming '7' is the value for 'Closed' state
        var grChildIncident = new GlideRecord('incident');
        grChildIncident.addQuery('parent', current.sys_id); // Find all incidents whose parent is the current incident
        grChildIncident.query();

        while (grChildIncident.next()) {
            // Only update if the child incident is not already closed
            if (grChildIncident.state != 7) {
                grChildIncident.state = 7; // Set the state to Closed
                grChildIncident.update(); // Update the child incident
            }
        }
    }

})(current, previous);
        

This requires a Before Business Rule on the incident table (and similar rules for problem and change_request) to abort the close action if open tasks exist.

Business Rule Configuration:

• Table: Incident
• When to run: Before update
• Filter Conditions: State changes to Closed (or your equivalent closed state value)

Script:

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

    // Check for open Incident Tasks if the incident is being closed
    if (current.state == 7) { // Assuming '7' is the value for 'Closed' state
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id);
        grTask.addEncodedQuery('state!=3^state!=7'); // Exclude states that are Closed or Canceled (assuming 3 and 7 are typical closed/canceled values)
        grTask.query();

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

})(current, previous);
        

For Problem and Change Request: You would create similar Before Business Rules on their respective tables, checking for open problem_task or change_task records.

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

Business Rule Configuration:

• Table: Problem
• When to run: Before update
• Filter Conditions: State changes to Closed

Script:

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

    // If the problem is being closed
    if (current.state == 7) { // Assuming '7' is the value for 'Closed' state
        var grIncident = new GlideRecord('incident');
        // Find all incidents linked to this problem, that are not already closed
        grIncident.addQuery('problem_id', current.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.update(); // Update the incident
        }
    }

})(current, previous);
        

These three processes are intrinsically linked in IT Service Management, forming a cycle of service restoration and improvement:

• Incident: When a service breaks or a user experiences an issue, an Incident is created to restore normal service operation as quickly as possible. The focus is on immediate resolution.
• Problem: If multiple incidents are occurring, or if an incident is complex and its root cause isn’t immediately obvious, a Problem record is created. The goal of Problem Management is to identify the root cause and prevent future incidents.
• Change: Once the root cause is identified, a solution might involve making a modification to the IT environment. This modification is then managed through a Change Request. The Change Management process ensures that these changes are planned, approved, tested, and implemented in a controlled manner to minimize disruption.

Essentially, incidents highlight issues, problems investigate their causes, and changes implement solutions.

Out-of-the-box tables are those that come pre-installed with ServiceNow. They don’t typically have custom prefixes like x_ or u_. Some common examples include:

• incident
• problem
• change_request
• sc_req_item (Requested Item)
• sc_cat_item (Catalog Item)
• cmdb_ci (Configuration Item)
• sys_user
• sys_user_group
• sys_audit
• sys_attachment

Base tables are core tables in ServiceNow that often serve as parent tables for many other tables. They are typically foundational to the platform’s architecture. Some prominent examples include:

• task: This is a fundamental base table. Many records in ServiceNow that represent work to be done, like Incidents, Problems, Changes, and Service Catalog Tasks, extend the task table.
• cmdb_ci: The base table for Configuration Items in the Configuration Management Database (CMDB). Various CI classes like servers, applications, and network devices extend this table.
• cmdb: The highest-level table for the CMDB.
• sys_security_acl: Base table for Access Control Lists.

As mentioned, the task table is a base table. Tables that extend task represent specific types of work or activities that need to be performed. Common examples of tables that extend task include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• planned_task (used for project management)
• knowledge (though it has unique aspects, it’s often associated with task-like workflows)

When you create a new table in ServiceNow, by default, four Access Control Lists (ACLs) are automatically generated if the “Create security rules” checkbox is selected during table creation. These ACLs typically cover:

• create operation (on the table itself)
• delete operation (on the table itself)
• write operation (on the table itself)
• read operation (on the table itself)

If you uncheck this box during table creation, no ACLs are automatically generated, and you’d have to create them manually.

To create an auto-numbered field (like INC0010001 for incidents), you don’t create a “number field type” directly. Instead, when you define a new table or modify an existing one, you go to the Control tab in the table definition. There, you’ll find an option for “Auto-numbering”. You enable this, specify a Prefix (e.g., ‘INC’), and the Number of digits (e.g., ‘0000001’). ServiceNow automatically handles the sequential numbering.

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

• Inheritance of Fields: All fields from the parent table are automatically available in the child table. You don’t need to recreate them.
• No Duplicate System Fields: System fields (like sys_id, sys_created_on, sys_updated_by, etc.) are not recreated in the child table. They reside in the parent table and are inherited.
• ‘Class’ Field: A field named sys_class_name is automatically added to the parent table. This field stores the actual type of record (e.g., ‘incident’, ‘problem’, ‘change_request’) for records that originate from child tables. This is crucial for querying across the parent table and filtering for specific child types.
• Single Class Field: Even if a table extends multiple other tables (which is generally discouraged and not directly supported through the UI for direct extension), it will only have one sys_class_name field in its ultimate parent.

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

1. Reference: Links to another record in a different table (e.g., a User field on an Incident).
2. String: For text input.
3. List: Allows selection of multiple records from another table (e.g., a list of affected CIs).
4. Choice: A dropdown list of predefined options.
5. Email: Specifically for email addresses, with validation.
6. Date/Time: For selecting both date and time.
7. Date: For selecting only the date.
8. Boolean: A true/false or checkbox field.
9. Integer: For whole numbers.
10. Journal: A multi-line text field that logs changes over time (e.g., Work Notes, Additional Comments).
11. Attachment: Allows users to attach files to records.

The key difference lies in data retention and purpose:

• Normal Tables: Store data permanently until it is explicitly deleted. These are your standard application tables (e.g., incident, problem).
• Temporary Tables: Designed for short-term data storage. Data in temporary tables typically persists for a limited period (often around 7 days) and then gets automatically purged. These tables often extend the import_set_row table and are commonly used for staging data during import processes before it’s transformed and loaded into permanent tables.

Yes, you can influence the retention period for data in temporary tables, although it’s managed indirectly. This is typically done using Archive Rules. While not directly extending the life of “temp” tables in their strictest sense, you can configure archiving to move data from tables that might otherwise be purged based on age, effectively preserving it for longer periods according to your retention policies.

The distinction is where the data resides:

• Normal Tables: The data is stored directly within your ServiceNow instance’s database.
• Remote Tables: These tables act as a proxy to data that resides outside your ServiceNow instance. ServiceNow connects to an external data source (e.g., another database, an API) to retrieve and display this data. When you query a remote table, ServiceNow is fetching live data from that external source, rather than querying its own internal database. This is often used for integrations where you want to display or interact with data from another system 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 multiple 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 be assigned to many Incidents (Table B). Each Incident, however, is typically assigned to only one User (the ‘assigned_to’ field). Here, User is the “one” side, and Incident is the “many” side.
• Many-to-Many Relationship: This occurs when one record in Table A can be related to multiple records in Table B, AND one record in Table B can be related to multiple records in Table A. These relationships are typically implemented using an intermediary table.
  
  Example: An Incident (Table A) can be affected by or resolved by multiple Groups (Table B), and a Group can be involved in resolving or affecting many Incidents. This is often managed via tables like task_ci (linking tasks to CIs) or a custom many-to-many table.
• One-to-One Relationship: Less common directly, but can be simulated. One record in Table A is related to exactly one record in Table B, and vice-versa. This is sometimes achieved using reference fields where a record can only reference one other record, and that referenced record might have a field pointing back uniquely. A common pattern is having a dedicated table to store specific extended attributes for a primary record, where a primary record always has one of these attribute records.

There are numerous ways to create records in ServiceNow tables, catering to different scenarios:

1. Forms: Manually filling out a form and submitting it.
2. List Views: Using the “New” button in a list view.
3. GlideRecord Scripting: Programmatically creating records in Business Rules, Script Includes, Workflows, etc.
4. Record Producers: User-facing forms (often on the Service Portal) that create backend records (e.g., creating an incident from a “Report an Issue” button).
5. Email: ServiceNow can be configured to create records (like incidents or requests) based on incoming emails.
6. Import Sets: Loading data from spreadsheets (Excel, CSV) or other external sources into temporary tables and then transforming and loading them into permanent tables.
7. REST/SOAP APIs: Creating records from external systems via integrations.
8. UI Actions: Custom buttons or links that can trigger record creation logic.

There are several ways to enforce mandatory and read-only fields, each with its own scope and priority:

• Dictionary Properties: Directly in the field’s Dictionary Entry, you can set “Mandatory” or “Read only” checkboxes. This is a fundamental, always-on setting.
• Dictionary Overrides: To change the mandatory/read-only status of a field specifically for a child table (e.g., making a field mandatory on incident but not on the parent task table).
• UI Policies: Client-side scripts that make fields mandatory, read-only, visible/hidden, or set their values based on conditions on the form. They run when the form loads and when fields change.
• Data Policies: Similar to UI Policies but can also run on the server-side. They enforce data consistency across all data sources (forms, APIs, imports). They are generally preferred for enforcing mandatory/read-only fields as they provide more robust data governance.
• Client Scripts (using g_form.setMandatory() or g_form.setReadOnly()): For more complex or dynamic client-side logic that UI Policies might not cover, you can write explicit JavaScript in Client Scripts.
• Access Control Lists (ACLs): While primarily for security, ACLs can also control read/write access (effectively making fields read-only or preventing writes) based on roles and conditions.

Technically, you can mark multiple fields as “Display” in a table’s dictionary definition. However, this is strongly discouraged and considered bad practice. ServiceNow uses the “Display” checkbox on a field to determine which field is used when a record is referenced in another table. For example, when you look up a User record on an Incident, the display value of the User record (usually ‘Name’) is what you see. Having multiple display fields leads to ambiguity and confusion, as ServiceNow wouldn’t know which one to prioritize as the primary display value when referencing the record elsewhere.

All table definitions in ServiceNow, including custom tables and out-of-the-box tables, are stored in the sys_db_object table. This table contains metadata about each database object defined within the instance.

There are several ways to set a default value for a field:

• Dictionary Entry: On the field’s Dictionary definition, you can specify a Default value. This value will be pre-populated when a new record is created on that table.
• UI Policies: You can configure a UI Policy to set a default value for a field when a form loads or when specific conditions are met.
• Client Scripts: Using g_form.setValue('field_name', 'default_value'); in an OnLoad Client Script.
• Business Rules: For server-side defaults, you can use a Before Insert Business Rule to set the default value if it’s not already populated. This is especially useful for defaults that depend on other server-side logic.

The current object is a server-side object available in server-side scripts (like Business Rules, Workflow Scripts, Script Includes when called server-side). It represents the record currently being processed by the script. You use it to get and set values on that specific record.

You use methods of the current object:

• current.setValue('field_name', value);: This is the primary method for setting a field’s value. For reference fields, you need to provide the sys_id of the referenced record.
• current.setDisplayValue('field_name', value);: This is useful for setting the display value of a reference field. For example, if you want to set a User field to “John Doe” without knowing his sys_id, you can use current.setDisplayValue('assigned_to', 'John Doe');. However, it’s generally more robust to use setValue with the sys_id when possible.

Example:

// Setting a string field
current.setValue('short_description', 'This is an updated description.');

// Setting a reference field (e.g., caller_id)
var userSysId = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
current.setValue('caller_id', userSysId);

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

Reference Qualifiers are crucial for controlling the data displayed in Reference fields and List fields. They act as filters, restricting the records that a user can select from the lookup list. This enhances user experience and data integrity.

Types of Reference Qualifiers:

1. Simple Reference Qualifier:
   • Description: This is the most straightforward type. You define a fixed query (similar to a WHERE clause in SQL) directly in the reference field’s dictionary entry.
   • Example: To show only active users, you’d set the qualifier to active=true. To show only active users in the ‘IT’ department, it would be active=true^department=IT.
   • Use Case: Static filtering where the criteria don’t change based on other fields on the form.
2. Dynamic Reference Qualifier:
   • Description: This type allows the query to be dynamically generated based on the context of the form. It leverages “Dynamic Filter Options” that you configure globally. These options can reference values from other fields on the current form.
   • Example: Displaying only users who are members of the same assignment group as the current record. You’d create a Dynamic Filter Option for this and then use it in the Reference Qualifier.
   • Use Case: Filtering based on values present in other fields of the current record.
3. Advanced Reference Qualifier (JavaScript Reference Qualifier):
   • Description: This is the most powerful and flexible type. It allows you to write custom JavaScript code directly in the reference field’s dictionary entry. This code can perform complex logic, interact with other fields, and even make GlideRecord queries to determine the filter criteria.
   • Example: Filtering incidents to show only those assigned to the current user’s department AND with a priority less than 3. The JavaScript would look something like: javascript: 'assignment_group.dept=\'' + gs.getUser().getDepartmentID() + '\'^priority<3'; (Note: this is a simplified conceptual example; actual JS might be more complex).
   • Use Case: Highly dynamic and complex filtering requirements that cannot be met by simple or dynamic qualifiers.

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic is context-aware based on other form fields via pre-defined options.
• Dynamic vs. Advanced: Dynamic uses predefined filters; Advanced allows custom JavaScript for maximum flexibility and complex logic.
• Simple vs. Advanced: Simple is for basic, fixed conditions; Advanced is for dynamic, complex, and programmatic filtering.

Dependent values in ServiceNow are used to create cascaded dropdowns. When you select a value in one field (the parent field), the choices available in another field (the dependent field) are dynamically filtered to show only relevant options. This significantly improves user experience by guiding them through selections and reducing errors.

How it works:

1. Parent Field: This field has a set of choices.
2. Dependent Field: This field’s choices are linked to the parent field.
3. Configuration: In the dictionary entry of the dependent field, you set the “Dependent Field” attribute to the name of the parent field. Then, within the choices for the dependent field, you define which choice(s) should appear when a specific parent choice is selected.

Example:

Parent Field: Category (e.g., Hardware, Software, Network)

Dependent Field: Subcategory (dependent on Category)

• If Category = Hardware, Subcategory choices could be: Laptop, Desktop, Printer.
• If Category = Software, Subcategory choices could be: Operating System, Application, Database.

This ensures that when a user selects “Hardware” for Category, only hardware-related subcategories are presented.

A calculated value is a field whose value is automatically determined by a formula or calculation based on other fields. This is configured in the field’s Dictionary Entry by setting the “Type” to “Calculated”. You then provide a JavaScript expression in the “Calculated value” field. When the record is displayed or updated, ServiceNow evaluates this script and populates the field with the result.

Example: A “Total Price” field that automatically sums “Quantity” and “Unit Price” would use a calculated value.

// Example script in the "Calculated value" field:
// current.quantity * current.unit_price
        

Attributes are essentially “tags” or metadata that you can add to field dictionary entries or table definitions to modify their behavior or appearance without writing custom scripts for every little thing. They provide a declarative way to customize ServiceNow elements.

Some commonly used attributes include:

• no_email: Prevents email notifications from being triggered for changes to this field.
• no_attachment: Disables the attachment icon for this field (often used on reference fields where attachments aren’t relevant).
• no_add_me: Hides the “Add me” button on list view columns.
• tree_picker: Changes a reference field to display a hierarchical tree structure for selection.
• ref_auto_completer=AJAXTableCompleter: Enables auto-completion for reference fields.
• readonly: Makes a field read-only (though typically achieved via UI/Data Policies or Dictionary Overrides).
• mandatory: Makes a field mandatory (also typically managed via other means for more dynamic control).
• display:true: Marks a field as the display value for a table (as discussed before, should only be one per table).

A “collection field” on a table definition refers to the entry in the dictionary that represents the table itself, rather than a specific field within the table. When you create a table, ServiceNow automatically creates a dictionary entry for that table. Changes made to this collection field entry affect the entire table. For instance, setting attributes like no_attachment on the collection field will disable attachments for all records in that table.

To enable or disable attachments for an entire form (i.e., for all records of a table), you use attributes on the collection field of that table.

• To disable attachments: Add the attribute no_attachment to the collection field’s Dictionary Entry.
• To enable attachments: Ensure the no_attachment attribute is *not* present on the collection field’s Dictionary Entry. By default, attachments are enabled unless this attribute is added.

You can find and edit this by going to System Definition > Tables, selecting your table, and then looking at the dictionary entry for the table itself (which is often the first entry and has no specific field name). Add or remove the no_attachment attribute there.

A Dictionary Override allows you to modify the definition of a field from a parent table specifically for a child table. This is incredibly useful for customizing inherited fields without altering the parent table’s definition, which would affect all its child tables.

For example, if the priority field on the base task table has a default value of ‘4’, you might want the priority field on the incident table to have a default of ‘3’. You would create a Dictionary Override for the priority field on the incident table.

You can override many properties of a field, including:

• Mandatory: Make a field mandatory in the child table even if it’s not in the parent.
• Read only: Make a field read-only in the child table.
• Default value: Set a different default value for the field.
• Max length: Change the maximum length allowed for a string field.
• Display: (Use with extreme caution, as per question 43)
• Reference Specification: Change reference qualifiers or target tables.
• Attributes: Add or remove attributes.
• Label: Change the display label of the field.
• Hint text: Add or change hint text.

Application Menus are the top-level navigation items you see in the ServiceNow left-hand navigation pane (the “All” menu). They group together related modules (which are links to forms, lists, or reports). For example, “Incident” is an Application Menu, and “Open”, “Assigned to Me”, and “All” are modules within that menu.

Creating an Application Menu (and its associated Modules) is how you make custom applications, forms, and lists accessible and organized for end-users within the ServiceNow interface.

A Process Flow (or Flow Designer flow, or Workflow visual editor) is a graphical representation that visualizes the steps and stages of a particular process or workflow within ServiceNow. It helps users understand where a record is in its lifecycle, what actions are available at each stage, and what the expected progression is. For example, an Incident might have a process flow showing states like New, In Progress, On Hold, and Resolved.

Data Lookups (more formally known as “Data Lookup Rules”) in ServiceNow allow you to automatically populate a field on a form with a value based on matching criteria from another table. Unlike dependent dropdowns which filter choices, Data Lookups automatically set a value based on a lookup table.

Example: You have a form where a user selects a “Region” and a “Product Category”. You can configure a Data Lookup to automatically populate a “Default Support Group” field by looking up a table that maps (Region + Product Category) to a specific Support Group.

This is configured via System Policy > Rules > Data Lookups.

UI Policies are client-side scripting mechanisms used to dynamically change the behavior of forms. They are an alternative to client-side scripting for certain tasks. They can make fields mandatory, read-only, or hidden, and control their visibility. They execute on the client when the form loads and when field values change, making the user experience more dynamic and guiding them through data entry.

When the “Global” checkbox is checked in a UI Policy, it means that the policy will apply to all views of the form. If it’s unchecked, you will need to specify which views the UI Policy should apply to. This allows for granular control, enabling different UI behaviors on different views (e.g., a simplified view for end-users and a detailed view for fulfillers).

The “Reverse if false” option in a UI Policy Action dictates what happens when the UI Policy’s conditions are not met. If checked:

• The actions defined in the UI Policy will be reversed when the conditions evaluate to false. For example, if a field was made mandatory when the condition was true, it will become optional again when the condition is false.
• If unchecked, the actions applied when the condition was true will simply be undone, and no further action is taken when the condition becomes false.

It’s crucial for resetting form elements to their default states.

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

• If checked: The UI Policy runs as soon as the form loads. All conditions are evaluated, and actions are applied based on the initial state of the form fields.
• If unchecked: The UI Policy does not run when the form initially loads. Its actions will only be triggered later when a user interacts with the form in a way that meets the UI Policy’s conditions (e.g., changing a field value).

This is useful for making UI changes that should only occur after a user has made some selections.

The “Inherit” checkbox on a UI Policy means that the UI Policy will automatically be applied to any tables that extend the table on which the UI Policy is defined. For instance, if you create a UI Policy on the task table and check “Inherit”, that UI Policy will also apply to incident, problem, change_request, and any other tables that extend task.

Yes, you can incorporate scripting into UI Policies. To do this, you need to enable the “Run scripts” checkbox within a UI Policy Action. Once enabled, you can write client-side JavaScript code that will execute when the UI Policy’s conditions are met and that specific UI Policy Action is triggered.

This allows for more complex actions than simply making a field mandatory or visible, such as dynamically setting field values based on intricate logic or performing calculations before setting them.

Yes, you can convert a UI Policy into a Data Policy. ServiceNow provides a convenient “Convert to Data Policy” feature. You open the UI Policy, and there will typically be a related link or button to perform this conversion. This is beneficial when you want to ensure that the same data enforcement logic (mandatory, read-only, etc.) applies not only on the form but also through other data entry methods like APIs or imports.

While most UI Policies can be converted, there are specific scenarios where direct conversion might not be fully equivalent or might lose some functionality:

• Controlling Data Visibility (Client-side only): UI Policies can hide fields from the user interface. While Data Policies can make fields read-only or mandatory, they don’t directly control UI visibility. If a UI Policy’s primary function is to hide/show fields, its conversion to a Data Policy won’t replicate the UI hiding aspect.
• Controlling Views: UI Policies can be configured to apply only to specific views, or their actions might be view-dependent. Data Policies operate at a more fundamental data level and don’t have a direct concept of “views.”
• Controlling Related Lists: UI Policies can sometimes be used to show/hide related lists. Data Policies do not have this capability as they operate on individual records.
• Complex Client-Side Scripting: If a UI Policy relies on very intricate client-side JavaScript within its actions that doesn’t translate directly to the declarative nature of Data Policies (e.g., complex DOM manipulation, or calling client-side GlideAjax specific to UI rendering), the conversion might require manual adjustments or might not be fully feasible without rewriting the logic as a server-side script in the Data Policy.

Data Policies are a powerful tool for enforcing data integrity and consistency across ServiceNow. They define rules that make fields mandatory, read-only, or hidden, and these rules apply regardless of how the data is being entered—whether through a form, an import set, or an API call. Data Policies can execute on both the client-side (for immediate feedback on forms) and the server-side (to ensure data integrity at the database level).

They offer a more robust and centralized approach to data governance compared to UI Policies, which are primarily focused on the user interface.

Business Rules are server-side scripts that run automatically when a record is displayed, inserted, updated, deleted, or queried. They are the workhorses for automating business logic within ServiceNow. You can use them to perform actions like:

• Setting field values based on other field changes.
• Validating data before it’s saved.
• Creating or updating related records.
• Sending notifications.
• Performing complex calculations.

They can run “before” or “after” a database operation, or “async” (asynchronously) for tasks that don’t need immediate execution.

The timing of when a Business Rule executes is critical:

• Before Business Rule: Executes before the database operation (insert, update, delete) is committed. This is ideal for data validation, modifying values before they are saved, or aborting the operation entirely (using current.setAbortAction(true);). You can modify the current object.
• After Business Rule: Executes after the database operation has been committed to the database. This is used for actions that need to occur once the record is successfully saved, such as creating related records, sending notifications, or updating other tables based on the committed changes. You cannot modify the current object in an After rule in the same transaction; you’d need to query the record again.
• Async Business Rule: Executes after the database operation is committed, but it runs in the background and is queued. This is used for long-running tasks or tasks that don’t require immediate feedback to the user, preventing delays in the user interface. Examples include sending email notifications, performing complex calculations that don’t need to be seen immediately, or interacting with external systems.

GlideRecord is ServiceNow’s server-side API for performing database operations. It allows you to query, insert, update, and delete records in ServiceNow tables using JavaScript. It’s the programmatic way to interact with your ServiceNow data from server-side scripts.

Key methods include:

• new GlideRecord('table_name');: Creates a new GlideRecord object for a specific table.
• initialize();: Resets the GlideRecord object for a new record.
• addQuery('field', 'value');: Adds a condition to the query.
• addEncodedQuery('encoded_query_string');: Adds a complex encoded query string.
• query();: Executes the query and retrieves matching records.
• next();: Iterates through the result set of a query.
• get('sys_id');: Retrieves a single record by its sys_id.
• setValue('field', value);: Sets the value of a field.
• insert();: Inserts a new record.
• update();: Updates the current record.
• deleteRecord();: Deletes the current record.

GlideSystem, accessible via the global gs object, is a server-side utility API in ServiceNow. It provides access to various system-level functions, including:

• User information (gs.getUserID(), gs.getUserName(), gs.getUser()).
• Logging (gs.info(), gs.warn(), gs.error()).
• Adding error messages to the user interface (gs.addErrorMessage()).
• Checking user roles (gs.hasRole()).
• Executing database queries (gs.getExecute() for specific scenarios).
• Accessing instance properties.
• And many more system-level operations.

It’s a fundamental object for server-side scripting.

GlideAjax is a client-side API used to make asynchronous calls to server-side scripts (Script Includes) from Client Scripts. It’s the modern and recommended way to perform server-side operations from the client without requiring a full page reload. This is essential for dynamic form interactions, fetching data, or performing server-side logic initiated from the client.

Key steps:

1. Create a Script Include: This Script Include must be defined with 'Use service side scope' checked (or `client callable = true` in older versions). It will have functions that can be called from the client.
2. Call from Client Script: Use GlideAjax in your Client Script to invoke a function in the Script Include.

Example:

// Client Script (e.g., OnChange on a field)
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
   if (isLoading || newValue === '') {
      return;
   }
   var ga = new GlideAjax('MyScriptInclude'); // Name of your Script Include
   ga.addParam('sysparm_name', 'myServerFunction'); // Name of the function in the Script Include
   ga.addParam('sysparm_field_value', newValue); // Pass a parameter
   ga.getXMLAnswer(function(answer) { // Callback function to handle the response
      g_form.setValue('another_field', answer); // Set a field on the form with the returned answer
   });
}

// Script Include (MyScriptInclude)
var MyScriptInclude = Class.create();
MyScriptInclude.prototype = Object.extendsObject(AbstractAjaxProcessor, {

    myServerFunction: function() {
        var fieldValue = this.getParameter('sysparm_field_value');
        // Perform server-side logic using fieldValue
        var result = 'Processed: ' + fieldValue;
        return result; // This will be the 'answer' in the client-side callback
    },

    type: 'MyScriptInclude'
});
        

Script Includes are reusable server-side JavaScript code modules in ServiceNow. They allow you to encapsulate logic into functions, making your code modular, organized, and maintainable. You can call Script Includes from Business Rules, other Script Includes, UI Actions, Workflows, and via GlideAjax from client-side scripts.

They are essential for promoting code reusability and adhering to best practices.

Both Client Scripts and UI Policies run on the client-side to control form behavior, but they differ in their approach and capabilities:

• UI Policies:
  • Declarative: You define conditions and actions without writing much (or any) explicit JavaScript. They are easier to create and manage for standard UI manipulations.
  • Order: Execute in a specific order.
  • Focus: Primarily on making fields mandatory, read-only, visible/hidden, or setting values.
  • “Reverse if false”: A key feature for resetting field states.
• Client Scripts:
  • Scripted: Require JavaScript coding.
  • Order: Can have their execution order controlled via the “Order” field, and can also interact with UI Policies (UI Policies run after Client Scripts with the same Order value).
  • Focus: Can perform any client-side logic, including complex calculations, making AJAX calls, interacting with DOM elements (though direct DOM manipulation is discouraged), and dynamic conditional logic.
  • Types: Have different execution triggers (onLoad, onChange, onSubmit).

When to use which:

• Use UI Policies for simple, declarative UI changes (making fields required, read-only, visible/hidden).
• Use Client Scripts for complex logic, when you need to interact with server-side via GlideAjax, or when the logic is too intricate for UI Policies.

This is a crucial distinction:

• UI Policy:
  • Scope: Runs exclusively on the client-side.
  • Purpose: Affects the user interface (form visibility, read-only, mandatory status).
  • Execution: Triggers when the form loads or when field values change on the form.
  • Limitations: Does not apply to data entered via APIs, import sets, or other non-UI methods.
• Data Policy:
  • Scope: Can run on both client-side and server-side.
  • Purpose: Enforces data integrity and consistency by making fields mandatory, read-only, or visible across all data entry points (forms, APIs, imports).
  • Execution: Server-side execution ensures data validity even if not entered via a form. Client-side execution provides immediate feedback on forms.
  • Advantages: Provides more robust data governance.

Key takeaway: UI Policies manage the user experience on forms; Data Policies manage data integrity across the entire platform.

The method current.setAbortAction(true); is used within Before Business Rules to prevent the database operation (insert, update, or delete) from completing. If this line of code is executed, the record will not be saved or modified in the database, and any subsequent database operations in the same transaction will also be aborted.

This is most commonly used for:

• Data Validation: If the data entered does not meet certain criteria, you can add an error message using gs.addErrorMessage() and then call setAbortAction(true) to stop the save.
• Conditional Logic: Preventing an update based on specific conditions that would violate business rules.

The gs.addErrorMessage('Your error message here'); function is used to display a user-friendly error message to the end-user. It’s typically used in conjunction with current.setAbortAction(true); within a Before Business Rule to inform the user why an operation was cancelled. The message will appear at the top of the form.

It can also be used in other server-side contexts (like Script Includes called by GlideAjax) to pass error feedback to the client.

GlideRecord query conditions are the filters you apply to retrieve specific records from a table. You build them using methods on the GlideRecord object before calling the query() method.

Common methods include:

• addQuery('field_name', operator, value);: The most flexible way to add conditions. Operators can be ‘=’, ‘!=’, ‘>’, ‘<', '>=’, ‘<=', 'STARTSWITH', 'ENDSWITH', 'CONTAINS', 'DOES NOT CONTAIN', 'IN', 'NOT IN'.
• addQuery('field_name', 'value');: A shorthand for ‘=’, e.g., addQuery('active', true);.
• addNotNullQuery('field_name');: Filters for records where a field is not empty.
• addEncodedQuery('encoded_query_string');: For complex queries, you can use an encoded query string (similar to how list filters are constructed, e.g., 'active=true^ORassigned_to=abc123xyz').

Combining Conditions:

• By default, multiple addQuery() calls are combined with an AND logical operator.
• To use an OR operator, you need to specify it explicitly: gr.addOrCondition('field_name', 'value');.
• For more complex AND/OR logic, addEncodedQuery() is often the best approach.

Example:

var gr = new GlideRecord('incident');
gr.addQuery('priority', 1); // Get incidents with priority 1
gr.addQuery('state', '!=', 7); // And state is not closed
gr.addOrCondition('assigned_to', gs.getUserID()); // OR assigned to the current user
gr.query(); // Execute the query
while (gr.next()) {
    gs.info("Found incident: " + gr.number);
}
        

When you create a Script Include and check the “Client callable” checkbox (or set `client callable = true` in older versions, or use `AbstractAjaxProcessor`), it means that the functions defined within that Script Include can be invoked from the client-side using the GlideAjax API. These Script Includes act as server-side endpoints for your client-side scripts, allowing you to fetch data, perform calculations, or trigger server-side logic without a full page refresh.

A Scheduled Job (or Scheduled Script Execution) in ServiceNow is a task that runs automatically at a predefined time or interval. They are used for a variety of automation purposes, such as:

• Running nightly data cleanup scripts.
• Sending out weekly reports.
• Performing regular data imports or integrations.
• Executing scheduled maintenance tasks.
• Triggering workflows or business logic on a schedule.

You can schedule jobs to run once, daily, weekly, monthly, or at specific intervals using a cron-like syntax.

REST (Representational State Transfer) APIs are a popular architectural style for building web services. In ServiceNow, REST APIs allow external applications to interact with your ServiceNow instance programmatically. You can use them to:

• Query data: Retrieve records from tables.
• Create data: Insert new records.
• Update data: Modify existing records.
• Delete data: Remove records.
• Invoke Scripted REST APIs: Execute custom server-side logic defined within ServiceNow.

ServiceNow provides a robust REST API framework, including OOTB APIs for tables and scripted APIs for custom integrations.

SOAP (Simple Object Access Protocol) is another protocol used for exchanging structured information in web services. ServiceNow supports SOAP APIs, which are typically used for more complex, stateful operations compared to REST. While REST is often favored for its simplicity and flexibility, SOAP is still relevant for legacy integrations or when specific SOAP features like WS-Security are required.

IntegrationHub is ServiceNow’s low-code/no-code platform for building integrations. It provides pre-built spokes (connectors) for common applications and services (like Microsoft Teams, Slack, Jira, SAP, etc.). You can use IntegrationHub to orchestrate complex workflows that span multiple applications, automating tasks and data synchronization without extensive custom coding. It’s part of the ITSM Pro suite.

A MID (Management, Instrumentation, and Discovery) Server is a Java application that runs on a server in your on-premises network or a different network. It acts as a secure proxy or intermediary between your ServiceNow instance (in the cloud) and your internal network resources. Its primary roles include:

• Discovery: Discovering IT infrastructure and applications within your network.
• Orchestration: Executing remote commands and workflows on internal servers.
• Data Collection: Gathering data from various systems that are not directly accessible from the ServiceNow cloud instance.
• Integrations: Facilitating integrations with internal applications.

It securely communicates with the ServiceNow instance, ensuring that sensitive internal data doesn’t need to be directly exposed to the internet.

CMDB stands for Configuration Management Database. In ServiceNow, it’s a database that stores information about all the IT assets (Configuration Items or CIs) and their relationships within an organization’s IT environment. A CI can be anything from a server, application, network device, or even a business service.

The CMDB is crucial for:

• Impact Analysis: Understanding how a change or incident might affect other components.
• Root Cause Analysis: Identifying dependencies and underlying causes of issues.
• Change Management: Planning and managing changes effectively.
• Service Mapping: Visualizing business services and their underlying infrastructure.
• Asset Management: Tracking IT assets.

A CI Class is a category or type of Configuration Item within the CMDB. ServiceNow organizes CIs into a class hierarchy. For example, you might have a top-level CI Class like “Server,” which then has child classes like “Windows Server,” “Linux Server,” “Application Server,” and so on. This hierarchical structure allows for detailed categorization, attribute management, and relationship definitions specific to each type of CI.

ServiceNow Service Mapping is a feature that builds on top of the CMDB to create dynamic, map-like visualizations of your business services. It shows how applications, servers, databases, and other CIs are interconnected to deliver specific business services. This gives IT teams a clear understanding of service dependencies and the potential impact of outages or changes on business operations.

Update Sets are ServiceNow’s mechanism for moving customizations from one instance to another. When you make changes to an instance (e.g., create a Business Rule, modify a form, build a UI Policy), these changes are captured in an Update Set. You then “commit” this Update Set to another instance (like from Development to Test, or Test to Production). They are essential for managing the promotion of customizations through your development lifecycle.

A scoped application is a self-contained set of application artifacts (tables, forms, scripts, UI pages, etc.) that exist within a defined namespace or “scope.” This provides a robust way to develop and deploy custom applications on the ServiceNow platform. Scoped applications enforce encapsulation, meaning they can only interact with other scopes or the global scope through defined APIs, preventing unintended modifications to other parts of the instance. This enhances maintainability, security, and reusability.

The key differences lie in their namespace, accessibility, and development approach:

• Global Scope:
  • Namespace: All customizations created in the global scope are, well, global. They are accessible by default to all other applications and scripts in the instance.
  • Accessibility: Can directly access and modify tables, scripts, and configurations from any other application.
  • Development: Historically, most customizations were done in the global scope. However, this can lead to naming conflicts and “spaghetti code” as the instance grows.
• Scoped Applications:
  • Namespace: Have their own unique application scope (e.g., x_mycompany_my_app). Artifacts within a scope are isolated.
  • Accessibility: Can only interact with global or other scoped applications through explicitly defined APIs or import sets. This prevents accidental overwrites or conflicts.
  • Development: The modern and recommended approach for building new applications. It promotes modularity, better governance, and cleaner code.

The sys_id is a unique 32-character hexadecimal identifier automatically assigned to every record in every table in ServiceNow. It’s the primary key for records and is used internally by ServiceNow to uniquely identify and reference records. You’ll see it frequently in URLs, in scripts (when referencing other records), and in system tables.

Transform Maps are used within ServiceNow’s Import Set functionality to define how data from a source table (staging table) is mapped to a target table. When you import data, it first lands in a staging table. The Transform Map then dictates which fields from the staging table correspond to which fields in your target table (e.g., incident, user), and it handles any necessary data transformations (like converting date formats or mapping choice lists).

An Access Control List (ACL) in ServiceNow defines the security rules for accessing records and fields. ACLs determine who can perform what actions (create, read, write, delete) on which data. They are the cornerstone of ServiceNow’s security model and are configured based on roles, conditions, and scripts. When a user attempts an action, ServiceNow checks the relevant ACLs to determine if the action is permitted.

ACLs are categorized based on what they secure and how they operate:

• Record ACLs: These secure specific records or fields within a table. They are the most common type.
  • Read ACLs: Control who can view records.
  • Write ACLs: Control who can modify fields on a record.
  • Create ACLs: Control who can create new records.
  • Delete ACLs: Control who can delete records.

  Record ACLs can have conditions, scripts, and roles associated with them.

• Field ACLs: A sub-type of Record ACLs that specifically targets a single field. For example, a Write ACL on the short_description field of an incident.
• Edge ACLs: These are special ACLs that secure table-level operations and can apply to the entire table, not just individual records. They are often used to control actions like list editing.
• UI ACLs: These control access to UI elements like buttons, form sections, or related lists. They don’t directly secure data but rather the interface components.

Operation Type: ACLs are also defined by the operation they permit: create, read, write, delete.

The fundamental difference is where they execute and what they are primarily used for:

• UI Action:
  • Scope: Primarily client-side, but can have server-side logic.
  • Purpose: Adds custom buttons, links, or context menu items to forms and lists. They are used to trigger actions directly from the user interface.
  • Execution: Runs when the user clicks the button/link. Can contain client-side scripts (for immediate UI feedback) and server-side scripts (for backend processing).
  • Examples: “Resolve Incident” button, “Create Problem” link.
• Business Rule:
  • Scope: Exclusively server-side.
  • Purpose: Automates backend processes based on database events (insert, update, delete, query).
  • Execution: Runs automatically in the background before, after, or asynchronously to database operations.
  • Examples: Setting a field value when a record is updated, sending an email when a new incident is created.

A UI Action might trigger a Business Rule, but they are distinct in their primary function.

Flow Designer is ServiceNow’s modern, low-code/no-code visual tool for creating automated workflows and integrations. It uses a graphical interface to design flows, making it easier to automate complex processes that might have previously required extensive scripting. Flow Designer leverages reusable components like Spikes (for integrations) and Actions to build out automation logic.

Both are tools for creating automated processes, but they have different philosophies and capabilities:

• Workflow Editor:
  • Paradigm: Traditional, visual scripting tool. Uses a canvas with activities and connectors.
  • Capabilities: More mature, with a wider range of activities and deeper integration with older ServiceNow features. Can be powerful for complex, long-running, and intricate sequential processes.
  • Complexity: Can become visually cluttered and harder to manage for very complex workflows.
• Flow Designer:
  • Paradigm: Low-code/no-code visual interface. Focuses on building reusable “flows” and “actions.”
  • Capabilities: More modern, user-friendly, and geared towards simpler, event-driven automations and integrations. Excellent for orchestrating actions across multiple applications using IntegrationHub spokes.
  • Complexity: Generally easier to learn and build automations quickly, especially for integrations.

When to use which:

• For new automations and integrations, especially those involving multiple applications, Flow Designer is generally preferred.
• For complex, legacy, or very intricate sequential processes that are already built in Workflow, it might still be maintained. ServiceNow encourages migrating complex Workflows to Flow Designer where feasible.

Tags are a feature in ServiceNow that allows users to categorize records by applying flexible, user-defined labels. Unlike choice lists, tags don’t require a predefined set of options. Users can create and apply tags on the fly to group related records for easier searching, filtering, and reporting. They are particularly useful for ad-hoc categorization and collaboration.

Performance Analytics (PA) is ServiceNow’s advanced analytics and reporting solution. It goes beyond standard reporting by collecting historical data, tracking trends, and providing dashboards with key performance indicators (KPIs) and metrics. PA allows you to measure service performance, identify bottlenecks, and make data-driven decisions for continuous improvement. It uses “indicators” to collect historical data and then displays them through “dashboards.”

Related Lists are components on a form that display records from another table that are linked to the current record. For example, on an Incident form, you might see related lists for “Incident Tasks,” “Incidents Affected CIs,” or “Problem Involved.” They provide quick access to associated information without having to navigate to separate forms.

My approach to troubleshooting in ServiceNow is systematic and multi-layered:

1. Understand the Problem: Clearly define the issue. What is happening? What is expected? Who is affected? When did it start?
2. Reproduce the Issue: If possible, try to replicate the problem consistently. This is key to testing fixes.
3. Gather Information:
   • Check user reports and error messages.
   • Review logs: System logs (syslog), transaction logs, browser console logs.
   • Examine Business Rules, UI Policies, Client Scripts, and ACLs that might affect the record or action.
   • Check the current record’s history and audit trail.
   • Inspect related records.
4. Isolate the Cause:
   • Client-side vs. Server-side: Is the issue visible on the form, or is it a backend process failing?
   • Specific Record vs. General: Does it affect one record, a few, or all records of a certain type?
   • Configuration vs. Data: Is it a configuration issue (script, ACL, UI policy) or an issue with the data itself?
   • Out-of-the-box vs. Custom: Is the issue in standard ServiceNow functionality or something that has been customized?
5. Test Potential Solutions:
   • Make small, incremental changes.
   • Test in a non-production instance first (Dev or Test).
   • Use impersonation to test as different users.
   • Temporarily disable scripts or policies (with caution) to see if the issue resolves.
6. Document and Deploy: Once a solution is found and tested, document the fix, update any affected code or configurations, and deploy it according to your change management process.