Mastering the MID Server: Your Essential ServiceNow Guide

In the dynamic world of IT Service Management (ITSM), ServiceNow stands as a titan. But to truly leverage its power, especially when integrating with your on-premises infrastructure, understanding and mastering the MID Server is paramount. This isn’t just another tool; it’s the bridge that connects your ServiceNow instance to your internal systems, enabling seamless data exchange, automation, and robust management of your IT landscape. This article delves into the most pressing questions about the MID Server, offering practical insights and best practices to elevate your ServiceNow expertise.

Whether you’re a seasoned ServiceNow administrator, a new entrant to the platform, or an IT professional looking to optimize your ServiceNow deployment, this comprehensive guide will equip you with the knowledge you need to navigate the complexities of the MID Server.

Understanding Your ServiceNow Environment

Before we dive deep into MID Server specifics, it’s crucial to establish context. Knowing your ServiceNow version is fundamental for understanding feature availability and best practices.

Current ServiceNow Version

As of this writing, many organizations are working with the latest releases, such as Washington DC. Staying current ensures you have access to the newest features, security patches, and performance enhancements.

Journey Through ServiceNow Versions

My personal journey with ServiceNow has spanned several significant versions, including Rome, San Diego, Tokyo, Utah, Vancouver, and now Washington DC. This experience has provided a broad perspective on the platform’s evolution and the consistent importance of core components like the MID Server.

User and Group Management: The Foundation of Access Control

Effective access control is the bedrock of any secure IT system. In ServiceNow, managing users and groups is critical for defining who can do what. Let’s explore the common questions surrounding this area.

Permissions and Best Practices for Users and Groups

Can we add permissions to users and groups? Absolutely. ServiceNow provides robust mechanisms for assigning roles and permissions to both individual users and groups. This is typically managed through the concept of “roles.”

Best Practice: Group-Based Permissions. The most recommended approach is to assign roles to groups rather than directly to individual users. Why? Imagine an employee leaving the organization. If their permissions were directly assigned, you’d have to manually revoke them from that user’s record. However, if their permissions were inherited through group membership, simply removing them from the relevant group automatically revokes all associated roles. This significantly simplifies user lifecycle management and reduces the risk of lingering access.

You can achieve this through scripting using GlideRecord or via the platform’s user interface.

Core User and Group Table Names

Understanding the underlying tables is essential for scripting and advanced administration:

• User Table Name: sys_user
• Group Member Table Name: sys_user_group (This table defines the groups themselves. The actual membership linking users to groups is in the sys_user_grmember table.)

Scripting User and Group Account Creation

Leveraging scripts can automate repetitive tasks:

Creating a User Account with Script

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

Creating a Group with Script

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the manager
newGr.email = 'testing@tcs.com';
newGr.description = 'A group for testing purposes';
newGr.insert();
        

Assigning Permissions via Script

Adding roles programmatically requires interacting with specific tables:

Adding Permissions to a User Account (Script)

When you assign a role to a user, a record is created in the sys_user_has_role table.

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

Adding Permissions to a Group Account (Script)

Similarly, roles assigned to groups are stored in the sys_group_has_role table.

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

Understanding User Delegation

What exactly does user delegation mean in ServiceNow? User delegation allows one user to act on behalf of another. This is incredibly useful for scenarios where the primary user is unavailable – think vacations, sick leave, or extended absences. The delegated user gains the necessary permissions to perform tasks, access resources, and even handle approvals that the original user would normally manage.

Real-world example: If an employee is going on vacation, they can delegate their approval tasks to a colleague. This ensures that critical workflows and approvals continue uninterrupted.

How to configure: Navigate to the original user’s account record, scroll down to the “Delegates” related list, and add the delegate’s name, specifying start and end dates. You can also define the scope of delegation, including permissions for assignments, notifications, and approvals.

Managing Group Members via Script

Directly manipulating group memberships is often done through scripts for automation:

Adding a Group Member (Script)

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

Removing a Group Member (Script)

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();
}
        

Navigating the ServiceNow User Interface and Core Concepts

ServiceNow’s interface has evolved, and understanding its core concepts is key to efficient use.

User Interface Evolution

ServiceNow has offered several user interfaces over time, with the most prominent being UI15, UI16, and the modern Next Experience UI. Each iteration brings design improvements and enhanced usability.

Web Services User Accounts

What is a web services user in ServiceNow? A web services user account is specifically designed for non-interactive access by third-party applications to integrate with ServiceNow. These users are not intended to log into the ServiceNow UI directly; their purpose is solely to facilitate API-driven data exchange.

Retrieving Current User Information

Accessing the currently logged-in user’s details is a common requirement for scripting:

• Client-side: Use g_user.userID (returns the sys_id).
• Server-side: Use gs.getUserID() (returns the sys_id).

Checking Group Membership

A frequent need is to determine if a user belongs to a specific group:

// Server-side check
gs.getUser().isMemberOf('group_name'); // Returns true if part of the group, false otherwise
        

Replace 'group_name' with the actual name or sys_id of the group.

Security Admin Role

Which role is required to work on Access Control (ACLs)? The security_admin role is essential for managing and creating Access Control Lists (ACLs), which govern record-level security.

Impersonation for Testing

What is impersonation? Impersonation is a powerful feature that allows administrators or users with specific roles (like impersonator) to temporarily log in as another user. This is invaluable for testing functionality from a specific user’s perspective, troubleshooting access issues, and ensuring roles and permissions behave as expected.

User Preferences

What is a user preference? User preferences allow individuals to customize certain aspects of their ServiceNow experience, such as the theme, list layouts, or notification settings. Importantly, these changes are personal and only impact the individual user, not the global platform configuration.

Incident, Problem, and Change Management: The ITIL Core

These three pillars of ITIL are fundamental to how ServiceNow manages service disruptions and improvements.

Incident Management

What is an incident? An incident is defined as any unplanned interruption to an IT service or reduction in the quality of an IT service. When an employee experiences an issue that prevents them from performing their work, they typically report it as an incident, seeking support from the service desk.

Problem Management

What is a problem? A problem arises when the same incident (or a set of similar incidents) occurs repeatedly. The goal of problem management is to identify the root cause of these recurring issues and implement a permanent solution or workaround, thereby preventing future incidents. If a single issue affects multiple users simultaneously, it’s often classified as a major incident, with a parent incident and several child incidents linked to it.

Change Management

What is a change request? A change request is initiated when a modification to the IT infrastructure is needed to improve a service, fix a problem, or implement a new feature. This could involve software updates, hardware replacements, or configuration adjustments.

Interrelationships and Workflows

• Can we create a problem record from an incident? Yes. If an incident is a recurring issue, the support engineer can directly create a problem record from the incident to investigate the root cause.
• Can we create a change request from an incident? Yes. If resolving an incident requires a modification to the IT environment, a change request can be initiated from the incident.

Scripting Incident, Problem, and Change Creation

Automating the creation of these records is a common scripting task:

Creating an Incident Record with Script

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bc5d94'; // sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the Configuration Item
gr.short_description = 'Test incident created via script';
gr.description = 'Detailed description of the test incident';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();
        

Creating a Problem Record with Script

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bc5d94';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test problem created via script';
gr.description = 'Detailed description of the test problem';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
        

Creating a Change Request with Script

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test change request created via script';
gr.description = 'Detailed description of the test change request';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
        

Automating Workflow Logic

ServiceNow’s business rules are powerful for automating processes:

Closing Child Incidents When Parent is Closed

Logic: When a parent incident is closed, all associated child incidents should also be closed.

Implementation: Use an After Business Rule on the Incident table.

// Business Rule: Close Child Incidents
// Table: Incident
// When: After
// Update: true
// Condition: current.state.changesTo(7) && current.parent == '' // Assuming state 7 is 'Closed'

if (current.state == 7 && current.parent == '') {
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();
    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident
    }
}
        

Preventing Incident Closure with Open Tasks

Requirement: An incident cannot be closed if it has any open incident tasks.

Implementation: Use a Before Business Rule on the Incident table.

// Business Rule: Prevent Incident Closure with Open Tasks
// Table: Incident
// When: Before
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

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

Troubleshooting Tip: Ensure you’re using the correct state values for ‘Closed’ in both the incident and incident task tables. These can vary based on your instance’s configuration.

Closing Incidents Associated with a Closed Problem

Requirement: When a problem is closed, all associated incidents should also be closed.

Implementation: Use an After Business Rule on the Problem table.

// Business Rule: Close Associated Incidents on Problem Closure
// Table: Problem
// When: After
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

if (current.state == 7) {
    // GlideRecord to find incidents associated with the 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'
    grIncident.query();
    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
    }
}
        

Interview Relevance: This demonstrates a solid understanding of how ITIL processes integrate within ServiceNow and your ability to automate inter-record relationships.

The Relationship Between Incident, Problem, and Change Management

Relationship Overview: Think of it as a cascade of service management. A user experiences an issue (Incident). If this issue is recurring, it’s investigated as a Problem to find the root cause. Once the root cause is identified, a permanent fix or improvement might require a change to the IT environment, leading to a Change Request.

ServiceNow Data Model and Table Management

Understanding ServiceNow’s underlying data structure is crucial for effective customization and development.

Out-of-the-Box (OOTB) Tables

Definition: OOTB tables are those provided by ServiceNow as part of its core platform. They are typically named without prefixes like x_ or u_.

Examples: incident, problem, change_request, sys_user, cmdb_ci.

Base Tables

Definition: Base tables are tables that are not extended by any other table but serve as a foundation for many others. They often contain common fields shared across multiple record types.

Examples: task (extended by incident, problem, change request, etc.), cmdb_ci (extended by various CI classes).

Examples of Task Tables

These tables extend the task base table and inherit its common fields like short description, state, assignment group, etc.:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)

Table Creation and Access Controls (ACLs)

Default ACLs: When you create a new table in ServiceNow, four Access Control Lists (ACLs) are generated by default if the “Create ACLs” checkbox is selected during table creation. These typically cover read, write, create, and delete operations.

Creating Number Fields

How to create a number field like incident number? To create auto-numbered fields, you typically define this at the table level. During table creation or via the table’s configuration, you can specify a prefix (e.g., “INC”) and the number of digits. The system automatically generates sequential numbers.

Table Extension: Inheriting Functionality

What happens when you extend a table? When a table (child) extends another table (parent), it inherits all the fields and configurations from the parent. This means you don’t need to recreate common fields in the child table. A special field called class is created in the parent table to track which child table the record originates from. A table can only directly extend one parent table.

Field Types in ServiceNow

A diverse range of field types allows for flexible data modeling:

1. Reference
2. String
3. List (Multi-select)
4. Choice
5. Email
6. Date/Time
7. Date
8. Boolean (True/False)
9. Integer
10. Journal (for notes/comments)
11. Attachment
12. URL
13. HTML

Temporary vs. Normal Tables

Difference:

• Temporary Tables: These tables (often extending import_set_row) store data temporarily, typically for a retention period of 7 days. They are commonly used for import set staging.
• Normal Tables: These tables store data permanently until explicitly deleted.

Retention Period: Yes, you can increase the retention period for temporary tables using archive rules, though their primary purpose is transient.

Remote Tables vs. Normal Tables

Difference:

• Remote Tables: These tables provide a view of live data from an external data source, often via REST APIs. The data is not stored directly within ServiceNow but is queried on demand.
• Normal Tables: These tables store data directly within the ServiceNow database.

One-to-One and One-to-Many Relationships

Understanding relationships is key to designing efficient databases:

• One-to-Many: A single record in one table can be related to multiple records in another. Example: One user can have many incidents. (sys_user to incident where caller_id links them).
• Many-to-Many: Multiple records in one table can be related to multiple records in another. Example: An incident can be assigned to multiple groups, and a group can have multiple incidents assigned to it. This is typically achieved through a linking table (e.g., task_group).

Ways to Create Records in ServiceNow

ServiceNow offers multiple avenues for data entry:

1. Forms: Direct manual entry via the user interface.
2. Record Producers: Catalog items that generate records in a specific table.
3. Email: Inbound email actions can create records.
4. GlideRecord: Server-side scripting for programmatic record creation.
5. Import Sets/Data Sources: Bulk data import from files (Excel, CSV) or external systems.
6. External Systems: Via REST APIs or other integration methods.

Field Configuration and Control

Mastering field properties is essential for tailoring forms and data validation.

Making Fields Mandatory or Read-Only

You have several options to control field behavior:

1. Dictionary Properties: Directly on the field’s dictionary entry.
2. Dictionary Overrides: To modify field behavior in extended tables.
3. UI Policies: Client-side scripting to dynamically change field attributes.
4. Data Policies: Server-side (and client-side) data validation and field manipulation.
5. Client-side Script (g_form.setMandatory()): Programmatic control within client scripts.

Display Fields

Can we make 2 fields display in one table? No, you should not make more than one field as a “Display” field on a table. ServiceNow uses the display field (usually a name or identifier) for searching and in reference lookups. Having multiple display fields can lead to confusion and unexpected behavior.

Storing Table Definitions

All table definitions in ServiceNow are stored in the sys_db_object table.

Setting Default Field Values

How to set a default value on a field? You can set default values in the field’s dictionary entry. This populates the field with a pre-defined value when a new record is created, saving users time and ensuring consistency.

Server-Side Scripting and Core Objects

Understanding server-side objects is critical for advanced customization.

The current Object

What is the current object? The current object is a server-side GlideRecord object representing the record that is currently being processed by a server-side script (like a Business Rule or Workflow script). It allows you to get and set values on that record.

Setting Field Values with current

• current.setValue('field_name', value);: Use this to set the actual value of a field. For reference fields, you’ll provide the sys_id of the referenced record.
• current.setDisplayValue('field_name', value);: This method is useful for setting the display value of a field, especially for reference fields where you might provide the human-readable name instead of the sys_id.

Example:

// Set a string field
current.setValue('short_description', 'Urgent Incident - System Down');

// Set a reference field
current.setValue('caller_id', 'user_sys_id_here');

// Set a reference field using display value (if the field is editable from UI)
current.setDisplayValue('assignment_group', 'IT Support');
        

Reference Qualifiers and Dependent Values

These features are vital for creating intelligent and user-friendly forms.

Reference Qualifiers

What are reference qualifiers? Reference qualifiers are used to filter the records that appear in a reference or list field’s selection. They ensure that users can only select relevant options, improving data accuracy and usability.

Types:

1. Simple Reference Qualifier:

   Description: The most basic type, allowing you to specify a fixed query directly in the dictionary entry. It’s like a mini-addQuery().

   Example: To show only active users in a user reference field: active=true.

   Interview Relevance: Demonstrates foundational knowledge of filtering reference fields.

2. Dynamic Reference Qualifier:

   Description: This type uses pre-defined “Dynamic Filter Options” which are essentially reusable query snippets that can be context-aware. They offer more flexibility than simple qualifiers.

   Example: Displaying only users who are members of the same department as the caller of the incident.

   How to Use: Create a Dynamic Filter Option under System Definition > Dynamic Filter Options. Then, select this option in the reference field’s dictionary entry.

3. Advanced Reference Qualifier (JavaScript):

   Description: This is the most powerful type, allowing you to write custom JavaScript code to define complex filtering logic. It can access other fields on the form and perform intricate calculations.

   Example: Filtering a list of CIs to show only those related to a specific manufacturer and currently in production.

   How to Use: In the reference field’s dictionary entry, select “Advanced” and write your JavaScript query. For instance: javascript: 'manufacturer=' + current.manufacturer + '^state=production'.

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic uses pre-configured, context-aware filters.
• Dynamic vs. Advanced: Dynamic uses predefined filters; Advanced allows custom JavaScript for maximum flexibility.
• Simple vs. Advanced: Simple is for basic, fixed conditions; Advanced is for complex, dynamic, or context-dependent filtering using JavaScript.

Dependent Values

What is a dependent value? Dependent values are used to create cascaded dropdowns. The choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field).

Example: In Incident Management, when you select “Hardware” as the Category, the Subcategory field should only show hardware-related options like “Laptop,” “Desktop,” or “Printer.”

Configuration: This is set in the dictionary entry of the dependent field by linking it to the parent field and defining choices for each parent value.

Attributes and Dictionary Overrides

These tools allow for fine-grained control over field and table behavior.

Attributes

What are attributes? Attributes are special properties you can add to fields (in their dictionary entries) to modify their behavior or appearance. They provide a declarative way to customize fields without extensive scripting.

Examples:

• no_email: Prevents emails from being sent when this field is updated.
• no_attachment: Disables attachments for this field.
• tree_picker: Renders the field as a tree-like picker.
• mandatory: Makes the field mandatory (though this is often managed via UI/Data Policies).

Collection Field on Table

What is a collection field on a table? When you create a table, ServiceNow automatically generates an entry in the sys_dictionary table for the table itself. This entry has the “Collection” checkbox ticked and represents the table as a whole, not a specific field. Attributes or properties set on this “collection field” apply to the entire table (e.g., enabling/disabling attachments for all records of that table).

Enabling/Disabling Attachments via Attributes

To enable or disable attachments for an entire table, you can add the no_attachment attribute to the collection field entry for that table in the sys_dictionary table.

Dictionary Overrides

What are dictionary overrides? Dictionary overrides allow you to modify the attributes or properties of a field in a child table without altering the original field in the parent table. This is crucial for extending tables while customizing specific fields for the child table’s context.

Properties you can override: Almost any property from the original dictionary entry can be overridden, including default values, display settings, mandatory status, choice lists, and attributes.

Example: The priority field might have a default value of 4 in the task table, but you can override it to 5 in the incident table using a dictionary override.

Application Menus, Process Flow, and Data Lookups

These components help organize and guide users through ServiceNow.

Application Menus and Modules

What are application menus? Application menus are the top-level navigation items in the ServiceNow application navigator (e.g., “Incident,” “Problem,” “Self-Service”). They organize modules, which are links to specific lists, forms, or reports within an application.

Purpose: They make forms, lists, and other functionalities easily accessible to end-users.

Process Flow

What is process flow? Process flow is a visual indicator, often displayed at the top of a form, showing the current stage or state of a record within a workflow. It helps users understand where they are in a process and what steps are next.

Data Lookup Roles

What are data lookup roles? Data lookups (and related features like “Data Lookup Rules”) are mechanisms used to automatically populate field values based on the values of other fields on the form. They are configured in a separate table and help streamline data entry by pre-filling relevant information.

UI Policies and Data Policies: Client and Server Logic

These are fundamental tools for controlling form behavior and data integrity.

UI Policies

What are UI policies? UI policies are client-side scripts that dynamically change the behavior of form fields. They can make fields mandatory, read-only, visible/hidden, or set their values based on specific conditions. They are a low-code alternative to client scripts for common form manipulations.

Global Checkbox: If checked, the UI Policy applies to all views. If unchecked, you specify which view(s) it should apply to.

Reverse if False: If checked, the actions defined in the UI Policy are reversed when the conditions are no longer met. For example, if a field is made mandatory when a condition is true, it becomes optional again when the condition is false.

Onload Checkbox: If checked, the UI Policy runs when the form initially loads. If unchecked, it runs only when specific field values change.

Inherit Checkbox: If checked, the UI Policy will also apply to tables that extend the table the UI Policy is defined on.

Can you write script in UI Policy? Yes. You can enable the “Run scripts” checkbox in the UI Policy Actions to execute JavaScript code when the UI Policy’s conditions are met. This allows for more complex client-side manipulations.

Data Policies

What are data policies? Data policies are server-side (and client-side) rules that enforce data integrity. Like UI policies, they can make fields mandatory, read-only, or visible based on conditions. Their primary advantage is that they apply regardless of the data source (form, inbound email, API), ensuring consistent data validation.

Converting UI Policies to Data Policies

Can we convert a UI Policy as a Data Policy? Yes, ServiceNow provides a feature to convert UI Policies into Data Policies. This is often done to enforce data consistency across different interaction methods.

Cases where conversion is NOT possible:

• When controlling data visibility (e.g., hiding fields). Data Policies primarily focus on mandatory/read-only status.
• When controlling views.
• When controlling related lists.
• When the UI Policy’s core logic relies heavily on client-side interaction that cannot be replicated server-side.

Conclusion

Mastering the MID Server and understanding the core components of ServiceNow, from user management and ITIL processes to data modeling and policy enforcement, is crucial for any ServiceNow professional. The questions and answers provided here cover a significant portion of common inquiries and practical considerations. By internalizing these concepts and leveraging the power of scripting and platform features, you can significantly enhance your ability to manage, configure, and optimize your ServiceNow instance, ensuring it delivers maximum value to your organization.