Top 10 ServiceNow Discovery Scenarios: A Deep Dive for IT Professionals

In the dynamic world of IT Service Management (ITSM), ServiceNow has become an indispensable tool for streamlining operations. At its core, efficient IT asset management relies heavily on accurate and comprehensive data. This is where ServiceNow Discovery shines. But beyond its fundamental capabilities, understanding how to leverage Discovery in specific, real-world scenarios can unlock significant value for your organization. This article delves into ten crucial ServiceNow Discovery scenarios, offering practical insights and technical details to help you navigate complex IT environments.

We’ll be drawing upon insights from experienced ServiceNow professionals, covering everything from understanding current platform versions to mastering scripting for advanced use cases. Let’s get started!

Understanding Your ServiceNow Environment

Before diving into Discovery specifics, it’s crucial to have a clear understanding of your ServiceNow instance and its history. This foundational knowledge is key for effective problem-solving and implementation.

1. Current ServiceNow Version and History

Knowing which version of ServiceNow you’re operating on is paramount for leveraging the latest features and ensuring compatibility. As of my last update, I’m working with the Washington DC release, which is the latest and greatest.

My journey with ServiceNow began with the Rome release. Since then, I’ve had the opportunity to work with and upgrade through several significant versions, including San Diego, Tokyo, Utah, Vancouver, and now Washington DC. This progression highlights the continuous innovation and evolution within the platform.

User and Group Management: The Foundation of Access Control

Effective access control is critical for security and operational efficiency. ServiceNow provides robust tools for managing users and groups, and understanding these mechanics is vital for administrators and developers alike.

2. User and Group Permissions: Best Practices

Absolutely! We can indeed add permissions (roles) to users and groups. The most recommended and best practice is to manage permissions through groups. Here’s why:

• Scalability: When an employee joins or leaves the organization, managing their access becomes a matter of adding or removing them from the relevant groups.
• Consistency: This ensures that roles are applied consistently across users who share similar responsibilities.
• Automation: If a user is removed from a group due to a role change or departure, their associated permissions are automatically revoked. This significantly reduces the risk of orphaned access.

While you can assign roles directly to users (which creates a record in the sys_user_has_role table), or script this process using GlideRecord, the group-based approach is far more maintainable.

3. User Table Name

The primary table for user information in ServiceNow is sys_user.

4. Group Member Table Name

The table that links users to groups is sys_user_grmember. It represents the membership relationship.

Wait, the reference actually says sys_user_group for group members. Let’s clarify: sys_user_group stores information about the groups themselves (like name, description), while sys_user_grmember is the table that actually defines which users belong to which groups. The question likely intended to ask about the table storing group members, which is sys_user_grmember. For clarity, I’ll proceed with sys_user_grmember for group membership operations.

5. Creating User Accounts via Script

You can programmatically create user accounts using the GlideRecord API. Here’s a typical example:

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

This script initializes a new record in the sys_user table and populates essential fields before saving it.

6. Creating Groups via Script

Similarly, you can create new groups programmatically:

    var newGr = new GlideRecord('sys_user_group');
    newGr.initialize();
    newGr.name = 'IT Support Team';
    // Note: The manager field expects a sys_id of a user.
    // Replace '62826bf03710200044e0bfc8bcbe5df1' with an actual sys_id.
    newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
    newGr.email = 'itsupport@example.com';
    newGr.description = 'Team responsible for Tier 1 IT support.';
    newGr.insert();
    

Remember to replace the placeholder sys_id for the manager with a valid user record in your instance.

7. Adding Permissions (Roles) to User/Group Accounts via Script

As mentioned, permissions are managed via roles. When you assign a role, a record is created in either sys_user_has_role (for users) or sys_group_has_role (for groups).

For Users:

    var userRole = new GlideRecord('sys_user_has_role');
    userRole.setValue('user', 'USER_SYS_ID'); // sys_id of the user
    userRole.setValue('role', 'ROLE_SYS_ID'); // sys_id of the role
    userRole.insert();
    

For Groups:

    var grpRole = new GlideRecord('sys_group_has_role');
    grpRole.setValue('group', 'GROUP_SYS_ID'); // sys_id of the group
    grpRole.setValue('role', 'ROLE_SYS_ID'); // sys_id of the role
    grpRole.insert();
    

Always use the actual sys_ids for users, groups, and roles. Using names directly will not work.

8. User Delegation in ServiceNow

User delegation is a powerful feature allowing one user to perform tasks on behalf of another. This is incredibly useful when a user is on leave, vacation, or otherwise unavailable, ensuring critical workflows like approvals continue uninterrupted.

How it works: The original user can configure their delegates. They specify:

• Delegate: The user who will perform the tasks.
• Start Date & End Date: The period for which the delegation is active.
• Permissions: What actions the delegate can perform (e.g., assignments, notifications, approvals).

Accessing this is straightforward: navigate to the original user’s record, scroll down to the ‘Delegates’ related list, and click ‘New’ to set up the delegation.

9. Adding and Removing Group Members via Script

Managing group membership programmatically is a common requirement, especially during automated onboarding or deprovisioning processes.

Adding a Group Member:

    var grMem = new GlideRecord('sys_user_grmember');
    grMem.user = 'USER_SYS_ID'; // sys_id of the user to add
    grMem.group = 'GROUP_SYS_ID'; // sys_id of the group
    grMem.insert();
    

Removing a Group Member:

    var grMem = new GlideRecord('sys_user_grmember');
    grMem.addQuery('user', 'USER_SYS_ID'); // sys_id of the user to remove
    grMem.addQuery('group', 'GROUP_SYS_ID'); // sys_id of the group
    grMem.query();
    if (grMem.next()) {
        grMem.deleteRecord();
    }
    

These scripts are fundamental for any automation involving user access to ServiceNow groups.

Navigating ServiceNow User Interfaces

ServiceNow has evolved its user interface over time. Understanding these different interfaces is important for training and troubleshooting.

10. ServiceNow User Interfaces

ServiceNow has offered several user interfaces over the years. The most prominent ones include:

• UI15: An older, but still sometimes encountered, interface.
• UI16: The more widely adopted and feature-rich interface that preceded the current generation.
• Next Experience: This is the modern, revitalized user interface, designed for enhanced usability and a streamlined user experience.

11. Web Services User Account

A web services user is specifically designed for programmatic access to ServiceNow by third-party applications. This user account is granted permission to interact with ServiceNow via its APIs (e.g., REST, SOAP) but cannot log in to the ServiceNow graphical user interface (GUI) as a regular end-user. This is a crucial security measure to ensure that integrations only have the necessary access without posing a risk of manual user interaction.

12. Getting Current Logged-In User System ID (Client-Side)

On the client-side (within client scripts, UI policies, etc.), you can easily access the current logged-in user’s sys_id using:

    g_user.userID;
    

13. Getting Current Logged-In User System ID (Server-Side)

On the server-side (within Business Rules, Script Includes, etc.), the gs object provides:

    gs.getUserID();
    

14. Checking Group Membership

A very common requirement is to check if the current user belongs to a specific group. This is easily done server-side:

    gs.getUser().isMemberOf('group_name'); // Returns true or false
    

You can also use the group’s sys_id for more precision: gs.getUser().isMemberOf('GROUP_SYS_ID').

Security and Access Control

ServiceNow’s security model is built around Access Control Lists (ACLs). Understanding how to manage and apply these is fundamental.

15. Role for Access Control (ACL) Management

To work with Access Controls (ACLs) in ServiceNow, you need the security_admin role. This is a powerful role that should be granted judiciously.

16. What is Impersonation?

Impersonation is a feature that allows an administrator (or a user with the appropriate role) to temporarily log in and act as another user. This is invaluable for testing user experiences, troubleshooting issues reported by a specific user, or verifying that roles and permissions are configured correctly. It provides a true view of what another user sees and can do within the platform.

17. User Preferences

User preferences are settings that an individual user can customize to tailor their ServiceNow experience. These preferences are specific to that user and do not affect other users or the global configuration. Examples include personalizing list layouts, setting default search values, or choosing notification preferences. They are stored in the sys_user_preference table.

Incident, Problem, and Change Management: The Core ITSM Processes

These three processes are the bedrock of IT Service Management. Understanding their definitions, relationships, and how they interact is crucial for any ServiceNow professional.

18. What is an Incident?

An incident represents a disruption to an IT service that impacts a user’s ability to work. When something stops functioning as expected, and a user needs immediate assistance to restore normal service operations, they typically create an incident. The primary goal is to restore service as quickly as possible.

19. What is a Problem?

A problem is the underlying cause of one or more incidents. If the same issue occurs repeatedly, or if a single incident is particularly complex and potentially has multiple underlying causes, it may be elevated to a problem. The goal of problem management is to identify the root cause of incidents and prevent them from recurring. When multiple similar incidents occur simultaneously, they are often linked to a single parent problem.

20. Can we create a Problem Record from an Incident?

Yes, absolutely. If an incident is reported and the support team identifies that this issue is recurring or potentially has a deeper root cause, they can create a Problem record directly from the Incident form. This is a standard workflow in ServiceNow for initiating problem investigations.

21. Can we create a Change Request from an Incident?

Yes. If resolving an incident requires making a modification to the IT infrastructure or applications (e.g., a patch, a configuration update), a Change Request can be created from the incident. This ensures that any changes made to the production environment are properly managed, assessed, and authorized to minimize risk.

22. Creating Incident, Problem, and Change Request Records via Script

These core records can be created programmatically, which is essential for automation and integration.

Creating an Incident:

    var gr = new GlideRecord('incident');
    gr.initialize();
    // Note: Caller ID and Assignment Group expect sys_ids.
    gr.caller_id = 'CALLER_SYS_ID';
    gr.category = 'inquiry';
    gr.subcategory = 'antivirus';
    // Note: CI expects sys_id.
    gr.cmdb_ci = 'CI_SYS_ID';
    gr.short_description = 'User reporting slow system performance.';
    gr.description = 'The user is experiencing significant slowdowns when opening applications.';
    // Note: Assignment Group expects sys_id.
    gr.assignment_group = 'ASSIGNMENT_GROUP_SYS_ID';
    gr.insert();
    

Creating a Problem:

    var gr = new GlideRecord('problem');
    gr.initialize();
    gr.caller_id = 'CALLER_SYS_ID'; // Often the reporter of the initial incident
    gr.category = 'application';
    gr.subcategory = 'database';
    gr.cmdb_ci = 'CI_SYS_ID'; // The affected configuration item
    gr.short_description = 'Intermittent database connectivity issues.';
    gr.description = 'Users are reporting intermittent failures to connect to the main database.';
    gr.assignment_group = 'ASSIGNMENT_GROUP_SYS_ID';
    gr.insert();
    

Creating a Change Request:

    var gr = new GlideRecord('change_request');
    gr.initialize();
    gr.category = 'normal'; // or 'standard', 'emergency'
    gr.subcategory = 'software';
    gr.cmdb_ci = 'CI_SYS_ID'; // The CI being changed
    gr.short_description = 'Apply security patch to web server.';
    gr.description = 'Applying the latest security patch to address CVE-XXXX-XXXX.';
    gr.assignment_group = 'ASSIGNMENT_GROUP_SYS_ID';
    gr.insert();
    

Remember to replace placeholder sys_ids with actual values from your instance.

23. Business Rule: Auto-Closing Child Incidents on Parent Closure

A common requirement is that when a parent incident is closed, all its child incidents should also be automatically closed. This can be achieved with an “after update” business rule on the incident table.

Trigger: After Update

Condition: current.state.changesTo(7) && current.parent == '' (Assuming state 7 is ‘Closed’. Adjust if your workflow uses a different state value for closure.)

    // Business Rule: Auto-Close Child Incidents
    if (current.state == 7) { // Check if the current incident is being set to Closed
        // Query for child incidents linked to this parent
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id);
        grChild.query();

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

This script ensures that when a parent incident is marked as closed, its children are also updated to the closed state, maintaining data integrity.

24. Preventing Incident Closure with Open Tasks

You cannot close an incident if there are still open incident tasks associated with it. This prevents premature closure and ensures all associated work is completed.

This logic is typically implemented using an “before insert” or “before update” business rule on the incident table.

    // Business Rule: Prevent Incident Closure with Open Tasks
    // Trigger: Before Update
    // Condition: current.state.changesTo(7) // Assuming 7 is the state value for 'Closed'

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

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

This script stops the closure process with an error message if any incident tasks are still open. Similar logic can be applied to Problem and Change Request tables by querying their respective task tables (e.g., problem_task, change_task).

25. Business Rule: Auto-Closing Incidents on Problem Closure

When a problem is resolved, its associated incidents should also be closed, as the root cause has been addressed. This can be implemented with an “after update” business rule on the problem table.

Trigger: After Update

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

    // Business Rule: Auto-Close Incidents on Problem Closure
    if (current.state == 7) { // Check if the problem is being set to Closed
        // GlideRecord to find incidents associated with this problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id);
        grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed' in incident
        grIncident.query();

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

This ensures that once a problem is fixed, all incidents linked to it are also resolved.

26. The Relationship Between Incident, Problem, and Change Management

These three processes form a crucial ITSM triad:

• Incident Management: Focuses on restoring normal service operation as quickly as possible. Think of it as firefighting.
• Problem Management: Aims to identify and eliminate the root cause of incidents, and to prevent their recurrence. This is the detective work behind the firefighting.
• Change Management: Manages the lifecycle of all changes to IT services and their underlying infrastructure. This is about safely implementing solutions and improvements, often driven by problem management findings or proactive service enhancements.

The flow is often: an incident occurs -> if it’s recurring or complex, it becomes a problem -> solving the problem may require a change -> implementing the change resolves the incidents and prevents future problems.

ServiceNow Table and Field Fundamentals

A deep understanding of ServiceNow’s data model is essential for customization and development.

27. Out-of-the-Box (OOTB) Tables

Out-of-the-box tables are those provided by ServiceNow itself. They typically do not have prefixes like x_ (scoped applications) or u_ (global applications created by users). Examples include:

• incident
• problem
• change_request
• cmdb_ci (Configuration Item base table)
• task (Base table for many task-like records)
• sys_user
• sys_user_group

28. Base Tables

Base tables are tables that are not extended by other tables but are designed to be extended by many. They serve as foundational structures. Examples include:

• task: Extended by incident, problem, change_request, sc_req_item, sc_task, etc.
• cmdb_ci: Extended by various CI classes like cmdb_ci_computer, cmdb_ci_server, cmdb_ci_application, etc.

29. Examples of Task Tables

As mentioned, tables extending the task base table are considered task tables. They inherit common fields like short_description, description, state, assigned_to, and assignment_group. Common examples include:

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

30. Access Controls (ACLs) Created by Default

When you create a new table in ServiceNow, by default, four Access Control Lists (ACLs) are created automatically if the “Create application scope” or similar option that includes ACL generation is checked. These typically include ACLs for:

• Read (*)
• Write (*)
• Create (*)
• Delete (*)

These default ACLs grant broad access, which you would then refine based on your security requirements.

31. Creating a Number Field (like Incident Number)

To create an auto-numbering field, similar to the incident number, you need to configure it during table creation or when defining a field on an existing table. This is done under the Control tab of the dictionary entry. You specify:

• Number: This checkbox must be enabled.
• Prefix: The starting characters for the number (e.g., “INC” for incidents).
• Number of digits: The total number of digits the number will have (e.g., 7 for INC0000001).

ServiceNow then automatically generates unique, sequential numbers based on these settings.

32. Extending Tables

When you extend a table (i.e., create a child table that inherits from a parent table), the child table does not duplicate the System fields (like sys_id, sys_created_on, etc.) that are already present in the parent. These fields are inherited. A special field called class is added to the parent table to track the actual type of record (e.g., ‘incident’ for an incident record, which extends ‘task’). If a table extends multiple tables (which is less common in ServiceNow’s direct inheritance model, but possible through relationships), it will still only have one class field in its primary parent to denote its specific type.

33. Ten Field Types in ServiceNow

ServiceNow offers a wide variety of field types to accommodate different data structures. Here are ten common ones:

1. Reference: Links to a record in another table (e.g., Caller in Incident points to sys_user).
2. String: For text input (short or long).
3. List: Allows selection of multiple records from another table (e.g., Watch list).
4. Choice: A predefined list of options for a field (e.g., State, Priority).
5. Email: Specifically formatted for email addresses.
6. Date/Time: For storing date and time values.
7. Date: For storing just date values.
8. Boolean: A true/false or checkbox field.
9. Integer: For whole numbers.
10. Journal: For storing multiple entries of text over time, often used for work notes or comments.
11. Attachment: Allows users to attach files to records.

34. Temporary vs. Normal Tables

The key difference lies in data retention:

• Temporary Tables: These tables are designed for short-term data storage, typically for import sets. Data in temporary tables is automatically deleted after a set period (usually 7 days) to manage storage. They usually extend the import_set_row table.
• Normal Tables: Data in these tables is stored permanently until it’s explicitly deleted. This includes most OOTB tables like incident, problem, and custom application tables.

35. Increasing Retention Period in Temporary Tables

Yes, the retention period for data in temporary tables can be extended. This is typically managed using Archive Rules, which can be configured to move older data to archive tables rather than deleting it immediately, or to adjust the automatic cleanup schedule.

36. Remote Tables vs. Normal Tables

This distinction relates to how data is accessed:

• Normal Tables: Store data directly within your ServiceNow instance’s database. You are querying and manipulating local data.
• Remote Tables: These are not physical tables in your ServiceNow instance. Instead, they represent data residing in an external system that is accessible via web services (e.g., REST or SOAP). When you query a remote table, ServiceNow fetches the data live from the external source.

37. One-to-One and One-to-Many Table Relationships

In ServiceNow, these relationships are defined primarily through reference fields:

• One-to-Many Relationship: The most common type. One record in Table A can be related to multiple records in Table B. For example, one sys_user can have many incident records. The reference field (e.g., caller_id on incident) points from the ‘many’ side to the ‘one’ side.
• One-to-One Relationship: Less common. One record in Table A is related to exactly one record in Table B, and vice-versa. This might be used for storing specific extended profile information for a user where you don’t want it cluttering the main sys_user table. A common way to achieve this is by having a reference field in both tables pointing to each other, often with a reference qualifier to ensure uniqueness.
• Many-to-Many Relationship: This is implemented using a many-to-many table (also known as a join table or bridge table). For example, Incidents and Groups. An incident can be worked by multiple groups, and a group can work on multiple incidents. This is achieved by creating a table like incident_group_assignment which has reference fields to both incident and sys_user_group.

38. Ways to Create a Record in a ServiceNow Table

There are numerous methods to insert records:

1. Form: The most common interactive method, filling out fields on a form.
2. GlideRecord (Server-Side Scripting): Programmatically creating records within Business Rules, Script Includes, etc.
3. Record Producer: A form on the portal that creates a record in a backend table (e.g., creating an incident from the service portal).
4. Email: Inbound email actions can create records like incidents or requests.
5. Excel Sheet (Import Set): Using the import functionality to load data from CSV or Excel files.
6. External System (Integration): Via APIs (REST, SOAP) from other applications.

39. Making Fields Mandatory, Read-Only, or Visible

There are several ways to control field behavior:

• Dictionary Properties: The ‘Mandatory’ and ‘Read only’ checkboxes directly on the field’s dictionary entry.
• Dictionary Overrides: To change these properties for a field in a child table.
• UI Policies: Client-side scripts that dynamically change field visibility, mandatory status, and read-only status based on conditions.
• Data Policies: Similar to UI Policies but work on both client and server sides, ensuring data integrity regardless of the data source.
• Client Scripts (e.g., g_form.setMandatory(), g_form.setReadOnly(), g_form.setVisible()): Direct scripting in client scripts for dynamic control.

40. Display Fields in a Table

You should generally have only one field designated as the “Display” field on a table. This field is used in search results, lists, and reference field lookups to show a user-friendly representation of the record. Having multiple display fields would lead to ambiguity and confusion. The primary key display field is usually the name or identifier of the record.

41. Where All Tables are Stored

All table definitions in ServiceNow are stored in the sys_db_object table. This table contains metadata about each table, including its name, label, columns, and other structural information.

42. Setting a Default Value on a Field

To pre-populate a field with a value when a new record is created, you can set a default value directly in the field’s dictionary entry. When a user opens a form for a new record, this default value will be automatically populated in the field.

43. The `current` Object

The current object is a powerful server-side object available within Business Rules, Workflow activities, and other server-side scripts. It represents the record that is currently being processed (e.g., the incident being updated, the problem being inserted). You use it to get and set field values on that specific record.

44. Setting Field Values on the `current` Form

Using the current object:

• To set a value:

  
              current.setValue('field_name', 'new_value');
              

  For reference fields, ‘new_value’ should be the sys_id of the referenced record.

• To set a display value (useful for reference fields if you don’t have the sys_id):

  
              current.setDisplayValue('reference_field_name', 'Display Name');
              

  This will find the correct sys_id based on the display name provided.

Advanced Reference Qualifiers and Relationships

Reference qualifiers are essential for making reference fields more dynamic and user-friendly.

45. Reference Qualifiers and Their Types

Reference qualifiers are used to filter the records that appear in a reference or list field’s dropdown. They ensure users select relevant data, improving data quality and user experience.

Types of Reference Qualifiers:

• Simple Reference Qualifier:

  Description: The most basic type. You define a static query directly in the reference field’s dictionary entry. It’s good for filters that don’t change based on form context.

  Example: To show only active users in a Caller field: `active=true`.

  How to Use: In the dictionary entry for the reference field, enter your query string in the ‘Reference qualifier’ field.

• Dynamic Reference Qualifier:

  Description: Uses a “Dynamic Filter Option” defined globally (System Definition > Dynamic Filter Options). This allows for more dynamic filtering that can adapt based on predefined rules but is not directly tied to form field values.

  Example: Showing all users who are members of a specific group that’s configured in the dynamic filter option.

  How to Use: Create a Dynamic Filter Option first. Then, in the reference field’s dictionary entry, select ‘Dynamic’ and choose your created option.

• Advanced Reference Qualifier (JavaScript Reference Qualifier):

  Description: The most powerful type. It uses a JavaScript function to dynamically build the query. This allows for complex filtering based on the current form’s context, user roles, or any other server-side logic.

  Example: Filtering available assignment groups to only show those that the current user is a member of.

  How to Use: In the reference field’s dictionary entry, select ‘Advanced’ and provide a JavaScript function that returns a query string. For example: javascript: getUserAssignmentGroups() where getUserAssignmentGroups() is a Script Include function.

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic uses pre-configured global options.
• Dynamic vs. Advanced: Dynamic is pre-configured and less flexible than Advanced, which allows custom server-side scripting for maximum flexibility.
• Simple vs. Advanced: Simple uses static queries; Advanced uses dynamic JavaScript for complex, context-aware filtering.

46. Dependent Values

Dependent values (or dependent fields) create cascaded dropdowns. When a user selects a value in one field (the parent), the choices available in another field (the dependent) are filtered accordingly.

Example: If you select “Hardware” as the Category for an incident, the Subcategory dropdown might show “Laptop,” “Printer,” “Monitor.” If you select “Software,” it might show “Operating System,” “Application.”

Configuration: This is set in the dictionary entry of the dependent field. You specify the ‘Dependent field’ and then define the choices for the dependent field, linking them to the specific parent values.

47. Calculated Value

When you need a field’s value to be automatically computed based on other fields on the record, you use a ‘Calculated’ field type. The calculation logic is defined using the current object in the dictionary entry’s ‘Calculation’ tab. For example, a ‘Total Price’ field might be calculated by multiplying ‘Quantity’ by ‘Unit Price’.

48. Attributes

Attributes are special directives applied to dictionary entries (fields or tables) to modify their behavior or appearance. They are string values added to the ‘Attributes’ field in the dictionary entry.

Examples of Attributes:

• no_email: Prevents email notifications from being sent for changes to this field.
• no_attachment: Disables the attachment icon for a specific field (though more commonly applied to the table itself).
• ref_auto_completer: Enables auto-completion for reference fields.
• tree_picker: Enables a tree-like selection for reference fields.
• no_change: Makes a field read-only after the record is inserted.

49. Enabling/Disabling Attachments via Attributes

To disable the attachment functionality for a particular record form, you add the no_attachment attribute to the Collection field (which represents the table itself) in the dictionary entry for that table.

50. Dictionary Overrides

Dictionary overrides allow you to extend or modify the behavior of a field defined in a parent table for a specific child table. For instance, if the ‘Priority’ field on the ‘Task’ table has a default value of 4, you can create a dictionary override on the ‘Incident’ table to change that default to 5 for incidents specifically.

You can override properties like:

• Default value
• Mandatory status
• Read-only status
• Max length
• Reference qualifiers
• And more…

UI and Data Policies

These are crucial for controlling user interactions and ensuring data integrity on forms.

51. Application Menus

Application Menus are the top-level entries in ServiceNow’s navigation menu (left-hand navigator). They organize modules (which link to forms, lists, etc.) into logical groupings. For example, “Incident” is an Application Menu, and under it, you might find modules like “Open,” “All,” “Assigned to Me.”

52. Process Flow

Process Flow is a visual representation of the stages or steps in a workflow. It’s often displayed on a record form (like Incident, Problem, Change) and shows the current status of the record within its lifecycle. For example, a Change Request process flow might show stages like “New,” “Assess,” “Authorize,” “Scheduled,” “Implement,” “Review,” “Closed.”

53. Data Lookup Rules

Data Lookup Rules are used to automatically populate field values on a form based on the values entered in other fields on the same form. Unlike UI Policies that control visibility or mandatory status, Data Lookup Rules populate data. For example, if you select a specific Item and Catalog, a Data Lookup Rule could automatically populate the ‘Assignment Group’ based on predefined mappings.

54. UI Policies

UI Policies are client-side scripts used to dynamically change form behavior based on conditions. They can:

• Make fields mandatory.
• Make fields read-only.
• Show or hide fields.
• Set default values.
• Set field visibility.

They are an alternative to client scripts for many common form manipulations.

Key UI Policy Attributes:

• Global: If checked, the UI Policy applies to all views of the table. If unchecked, you can specify views.
• Reverse if false: When checked, the UI Policy’s actions are reversed when the condition evaluates to false. For example, if a field is made mandatory when the condition is true, it becomes optional when the condition is false.
• On Load: When checked, the UI Policy runs automatically when the form is loaded. If unchecked, it runs only when conditions change on the form (e.g., a field value is updated).
• Inherit: When checked, the UI Policy will also apply to tables that extend the current table.

Can you write a script in a UI policy? Yes. If you enable the “Run scripts” checkbox on a UI Policy Action, you can write specific client-side scripts that execute when the UI Policy conditions are met for that action.

55. Data Policies

Data Policies are similar to UI Policies but operate on both the client and server sides. This means they enforce data rules regardless of how the record is accessed (e.g., form, import, integration). They are primarily used to make fields mandatory or read-only based on conditions.

56. Converting UI Policy to Data Policy

You can convert a UI Policy to a Data Policy. ServiceNow provides a “Convert this as Data Policy” button on the UI Policy form. This is useful when you want to ensure a rule is enforced not just on the form but also from other data sources.

57. Cases Where UI Policy Cannot Be Converted to Data Policy

Certain UI Policy actions cannot be directly converted to Data Policies because Data Policies are focused on data integrity (mandatory, read-only) and do not control presentation aspects like:

• Controlling the visibility of fields (UI Policies can hide/show fields; Data Policies cannot).
• Controlling views.
• Controlling related lists.
• Executing complex client-side scripts that manipulate the UI directly.

For these scenarios, you’d still need UI Policies or Client Scripts.

This comprehensive look at ServiceNow Discovery scenarios, coupled with a deep dive into user management, ITSM processes, and platform fundamentals, should equip you with the knowledge needed to excel in your ServiceNow journey. Keep exploring, keep learning!