How to Create Records in ServiceNow: Explore All Methods

By /

Mastering Record Creation in ServiceNow: Your Essential Guide

Hey there, ServiceNow enthusiasts! Ever found yourself wondering about the myriad ways to bring a new record to life within the platform? Whether you’re a seasoned admin, a budding developer, or just someone trying to get a handle on the powerful capabilities of ServiceNow, understanding how to create records is absolutely fundamental. It’s not just about clicking a “New” button; it’s about leveraging the platform’s full potential for automation, integration, and seamless data management.

From a simple user profile to a complex incident, problem, or change request, every piece of information in ServiceNow lives as a record in a table. In this comprehensive guide, we’re going to dive deep into the various methods for creating these records, exploring the underlying concepts, practical applications, and even some scripting magic. We’ll make sure to keep it human, sprinkle in real-world examples, and arm you with insights that are not just useful for your daily work but also for acing those all-important interviews. So, grab a coffee, and let’s unravel the art of record creation!

The Foundation: Core Concepts & ServiceNow’s Data Structure

Before we start creating records willy-nilly, it’s crucial to understand the bedrock of ServiceNow’s data model: tables and fields. Think of ServiceNow as a giant, incredibly organized database. Every piece of information—a user, an incident, a configuration item—is stored in a table, much like a spreadsheet, with specific data points stored in fields (columns).

Understanding ServiceNow Tables

Tables are the containers for your records. Here are some key types and concepts you’ll encounter:

  • User Table (`sys_user`): This is your directory for all individuals interacting with the system. Every employee, contractor, or external stakeholder typically has a record here.
  • Group Table (`sys_user_group`): Groups are collections of users, essential for managing permissions, assignments, and notifications efficiently. While `sys_user_group` defines the group itself, the actual memberships are stored in a junction table called `sys_user_grmember`. We’ll touch on this later!
  • Out-of-the-Box (OOTB) Tables: These are the tables ServiceNow provides by default, like `incident`, `problem`, `change_request`, `sc_req_item`, etc. You can easily spot them because their names don’t start with `x_` or `u_`. These tables are robust, well-integrated, and often form the backbone of your ITSM, HRSD, or CSM processes.
  • Scoped Application Tables (`x_` prefix): If you’re building a custom application within a specific scope in ServiceNow, any tables you create will typically be prefixed with `x_` followed by your scope ID, like `x_cust_myapp_my_table`. This ensures isolation and prevents naming conflicts.
  • Custom Global Tables (`u_` prefix): Historically, custom tables created in the global scope would get a `u_` prefix (e.g., `u_my_custom_table`). While you generally want to build in a scoped application today, you might still encounter these in older instances.
  • Base Tables: These are the grandfathers of many tables, acting as foundational structures that other tables extend. Key examples include `task` and `cmdb_ci`. They don’t extend any other table themselves but provide common fields and behaviors to their children.
  • Task Tables (e.g., `incident`, `problem`, `change_request`): These are specific examples of tables that extend the mighty `task` table. This inheritance brings a wealth of shared fields (like Short Description, State, Assignment Group) and functionalities, ensuring consistency across different types of work items.

The Power of Table Extension

When you extend a table in ServiceNow, you’re essentially saying, “I want all the fields and some of the functionalities from this parent table, plus my own unique additions.” This is a cornerstone of ServiceNow’s architecture and offers immense benefits:

  • Field Inheritance: All fields from the parent table are automatically available in the child table. This includes all the system (`sys`) fields (like `sys_id`, `sys_created_on`, `sys_updated_by`), which means these don’t need to be recreated in the child. Smart, right?
  • The `class` Field: Whenever a table extends another, a special field called `class` is automatically created in the parent table. This field stores the name of the child table that the record actually belongs to. So, a record in the `task` table could have its `class` field set to `incident`, `problem`, or `change_request`. If a table extends multiple parents (a less common but possible scenario), it still only gets one `class` field, efficiently tracking its most specific type.

Understanding Field Types

Fields are where the actual data resides. Choosing the right field type is crucial for data integrity and user experience. ServiceNow offers a rich variety, including:

  • Reference: Links to a record in another table (e.g., “Caller” field on an Incident references a `sys_user` record).
  • String: Plain text (e.g., Short Description).
  • List: Allows selection of multiple records from another table (e.g., “Watch list”).
  • Choice: A dropdown list of predefined options (e.g., “Category”).
  • Email: Formatted for email addresses.
  • Date/Time & Date: For capturing specific dates and times.
  • Boolean: A simple true/false checkbox.
  • Integer: Whole numbers.
  • Journal: Appends new text to existing text, maintaining a history (e.g., “Work notes”).
  • Attachment: Allows files to be attached to a record.

Temporary vs. Normal Tables

Most tables in ServiceNow store data permanently. However, there’s a special category:

  • Temporary Tables: These tables are designed for transient data, often used during data imports or integrations. They typically extend the `import_set_row` table and, by default, their data is purged after about 7 days. Think of them as staging areas where data lives just long enough to be processed before being moved or deleted.
  • Normal Tables: These are your everyday tables where data is meant to persist indefinitely until explicitly deleted. Incident, Problem, User – these are all normal tables.

The Many Ways to Create a Record in ServiceNow

ServiceNow is all about flexibility, and creating records is no exception. You’re not limited to a single method; the platform offers a diverse toolkit to fit various scenarios. Let’s explore the primary avenues:

1. The Classic: Manual Form Creation

This is probably the most straightforward method. Navigate to an application menu (e.g., “Incident > Create New”), fill out the form, and hit “Submit.” ServiceNow even allows you to create custom application menus and modules to make forms and lists easily accessible to end-users.

2. Streamlining Requests: Record Producers

Ever used the Service Portal to request a new laptop or report an issue? You were likely interacting with a Record Producer. These are catalog items that generate records (e.g., Incidents, Requests, Custom Table records) based on user input from a user-friendly form in the Service Portal. They abstract away the complexity of the underlying table, making record creation simple for end-users.

3. Email Ingestions

ServiceNow can monitor incoming emails and automatically create records based on their content. For instance, if a user sends an email to your support address, an Incident can be automatically created, with fields populated from the email subject, body, and sender. This is incredibly powerful for passive support channels.

4. Bulk Operations: Excel Sheets & External Systems

Need to onboard a hundred new users or import a list of configuration items? ServiceNow’s Import Sets allow you to import data from Excel sheets or CSV files, mapping columns to target table fields to create multiple records at once. Beyond simple file imports, ServiceNow’s robust API capabilities allow for creating records directly from external systems through integrations, enabling seamless data flow between platforms.

5. The Developer’s Playground: Scripting with GlideRecord

Ah, GlideRecord. This is where the real power and automation come into play for developers and administrators. GlideRecord is a JavaScript object that allows you to interact with the ServiceNow database programmatically. You can create, read, update, and delete records with precision and control. Let’s get into some practical examples.

Creating Records Using Script (GlideRecord)

GlideRecord is your go-to for server-side scripting when you need to create, query, update, or delete records. It’s incredibly versatile and fundamental for automation, integrations, and complex data manipulations.

The Basic Workflow for Creating a Record:

  1. Instantiate GlideRecord: `var gr = new GlideRecord(‘table_name’);`
  2. Initialize New Record: `gr.initialize();` (This prepares an empty new record).
  3. Set Field Values: `gr.field_name = ‘value’;` or `gr.setValue(‘field_name’, ‘value’);`
  4. Insert Record: `gr.insert();` (This saves the new record to the database).

Practical GlideRecord Examples:

Creating a User Account:

Let’s onboard a new employee, John Doe, using a script. This is common for HR integrations or bulk user provisioning.

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Corrected field name
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
// Best practice: Set a default password if creating interactive users
// userGr.user_password.setDisplayValue('Welcome1!'); // Use setDisplayValue for password fields
var userSysId = userGr.insert(); // insert() returns the sys_id of the new record
if (userSysId) {
    gs.info('User jdoe created with sys_id: ' + userSysId);
} else {
    gs.error('Failed to create user jdoe.');
}

Creating a Group:

You might need to create new assignment groups dynamically, perhaps when a new department is established.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'testing';
// For reference fields like 'manager', use the sys_id of the user record
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of an existing user
newGr.email = 'testing@tcs.com';
newGr.description = 'Test group for demonstration purposes';
var groupSysId = newGr.insert();
if (groupSysId) {
    gs.info('Group "testing" created with sys_id: ' + groupSysId);
} else {
    gs.error('Failed to create group "testing".');
}

Adding Permissions (Roles) to Users and Groups:

Permissions are managed through roles. When you grant a role to a user or group, a record is created in a junction table.

  • Adding a role to a User: A record in `sys_user_has_role` is created.
    • var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
// 'user' and 'role' are reference fields, so use sys_ids
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys_id of the role (e.g., 'itil')
var userRoleSysId = userRole.insert();
if (userRoleSysId) {
    gs.info('Role assigned to user. Record sys_id: ' + userRoleSysId);
} else {
    gs.error('Failed to assign role to user.');
}
  • Adding a role to a Group: A record in `sys_group_has_role` is created.
    • var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
// 'group' and 'role' are reference fields, so use sys_ids
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys_id of the role
var grpRoleSysId = grpRole.insert();
if (grpRoleSysId) {
    gs.info('Role assigned to group. Record sys_id: ' + grpRoleSysId);
} else {
    gs.error('Failed to assign role to group.');
}

Adding and Removing Group Members:

Managing who belongs to which group is handled in the `sys_user_grmember` junction table.

  • Adding a Group Member:
    • var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
// 'user' and 'group' are reference fields
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group
var memberSysId = grMem.insert();
if (memberSysId) {
    gs.info('User added to group. Membership sys_id: ' + memberSysId);
} else {
    gs.error('Failed to add user to group.');
}
  • Removing a Group Member: This involves querying for the specific membership record and then deleting it.
    • var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // User's sys_id
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Group's sys_id
grMem.query();
if (grMem.next()) { // Check if a matching record exists
    grMem.deleteRecord(); // Delete the found record
    gs.info('User successfully removed from group.');
} else {
    gs.warn('User not found in specified group.');
}

Creating ITSM Records (Incident, Problem, Change):

These follow the same GlideRecord pattern, but target specific tables and fields relevant to IT Service Management.

  • Creating an Incident Record:
    • var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the user reporting
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the Configuration Item
gr.short_description = 'User reported slow PC performance';
gr.description = 'The user\'s machine is running unusually slow, possibly due to a virus scan.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
var incSysId = gr.insert();
if (incSysId) {
    gs.info('Incident ' + gr.number + ' created with sys_id: ' + incSysId);
} else {
    gs.error('Failed to create incident.');
}
  • Creating a Problem Record:
    • var gr = new GlideRecord('problem');
gr.initialize();
// For problems, 'reported_by' is often used instead of caller_id
gr.reported_by = '86826bf03710200044e0bfc8bcbe5d94'; 
gr.category = 'software';
gr.subcategory = 'operating_system';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Repeated VPN connection failures across multiple users';
gr.description = 'Multiple users are reporting intermittent VPN connectivity issues, indicating a potential underlying problem with the VPN service or infrastructure.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
var probSysId = gr.insert();
if (probSysId) {
    gs.info('Problem ' + gr.number + ' created with sys_id: ' + probSysId);
} else {
    gs.error('Failed to create problem.');
}
  • Creating a Change Request:
    • var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'network'; // Example category
gr.type = 'normal'; // Standard change type
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // The CI being changed
gr.short_description = 'Upgrade network router firmware in Datacenter A';
gr.description = 'Planned firmware upgrade for Cisco router in Datacenter A to address security vulnerabilities and improve performance.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.requested_by = '86826bf03710200044e0bfc8bcbe5d94'; // User requesting the change
var changeSysId = gr.insert();
if (changeSysId) {
    gs.info('Change Request ' + gr.number + ' created with sys_id: ' + changeSysId);
} else {
    gs.error('Failed to create change request.');
}

Understanding the `current` Object

When you’re writing server-side scripts like Business Rules or Script Includes that run in the context of an existing record (e.g., when an incident is updated), the `current` object is your best friend. It represents the record currently being processed. You use it to:

  • Get Values: `var shortDesc = current.short_description;`
  • Set Values: `current.state = 2;` (setting a choice value)
  • Set Reference Field Values:
    • `current.setValue(‘caller_id’, ‘sys_id_of_user’);` (Recommended for setting reference fields, ensuring you pass the correct `sys_id`).
    • `current.setDisplayValue(‘caller_id’, ‘John Doe’);` (This attempts to find the `sys_id` based on the display value you provide. It’s often used when you have the display value but not the `sys_id`, but be cautious as it relies on display value uniqueness and can be less performant).

Automated Record Management and Inter-Record Relationships

ServiceNow truly shines when records aren’t isolated entities but part of an interconnected ecosystem, automatically triggering actions and updates. This is where Business Rules and other automation tools come into play, making your processes efficient and consistent.

Best Practice for Managing User Permissions

You *can* add roles (permissions) directly to individual user accounts, and you *can* do it via script. However, the best practice, hands down, is to assign roles to groups, and then add users to those groups. Why?

  • Scalability: Managing roles for hundreds or thousands of users individually is a nightmare. Groups simplify this.
  • Consistency: All members of a group automatically get the same roles.
  • Offboarding Efficiency: When an employee leaves, simply removing them from their groups automatically revokes all associated roles. No need to hunt down individual role assignments.

What is User Delegation?

User delegation in ServiceNow means granting another user the authority to act on your behalf for specific tasks. This is invaluable for business continuity when someone is unavailable (e.g., on vacation, leave). The delegated user can perform approvals, receive notifications, and even take on assignments that would normally go to the original user.

You can configure this by navigating to the original user’s profile, scrolling down, and clicking “Delegates.” Here, you specify the delegate’s name, start/end dates, and select permissions like assignments, notifications, and approvals. It’s a lifesaver for keeping workflows moving smoothly!

Understanding ITSM Record Relationships: Incident, Problem, Change

These three core ITSM processes are deeply interconnected, forming a logical flow for managing service disruptions and improvements:

  • Incident: A sudden, unplanned interruption to an IT service, or a reduction in the quality of an IT service. “My laptop crashed unexpectedly!” is an incident. The goal is to restore service as quickly as possible.
  • Problem: If the *same issue* keeps happening repeatedly to the *same user*, or if a single incident points to an unknown *underlying cause*, it becomes a problem. “This laptop keeps crashing every day.” A problem aims to identify and address the root cause to prevent future incidents. Multiple individual incidents might be linked to one problem if they share a common root cause.
  • Change Request: If fixing a problem or implementing an improvement requires modifications to IT infrastructure, applications, or services, a change request is raised. “We need to upgrade the operating system to fix these recurring crashes.” Change Management aims to ensure these modifications are carried out safely and effectively, minimizing disruption.

The beauty is, these records can transition seamlessly: you can create a problem record directly from an incident, or initiate a change request from either an incident or a problem, ensuring a complete audit trail and process flow.

Automating Inter-Record Closure Logic

Closing Child Incidents when Parent Closes:

This is a common requirement to maintain data consistency. If you have a major outage (parent incident) and many affected users (child incidents), closing the parent should ideally close the children. This is typically done with an “After” Business Rule:

// Business Rule: After Update
// Table: Incident
// Condition: current.state.changesTo(7) && current.parent.nil() // Assuming 7 is 'Closed' and it's a parent incident
// Script:
if (current.state == 7 && current.parent.nil()) { // Check if state is Closed and it's a top-level parent
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find all children of this parent
    grChild.addQuery('state', '!=', 7); // Only close if not already closed
    grChild.query();
    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident record
        gs.info('Child incident ' + grChild.number + ' closed due to parent incident ' + current.number + ' closure.');
    }
}

Preventing Incident/Problem/Change Closure with Open Tasks:

It’s often bad practice to close a parent record if associated tasks (like incident tasks, problem tasks, or change tasks) are still open. This ensures all work is completed. This logic is implemented using a “Before” Business Rule:

// Business Rule: Before Update
// Table: Incident (similar for Problem, Change Request with respective task tables)
// Condition: current.state.changesTo(7) // If the incident is being set to Closed
// Script:
if (current.state == 7) { // Check if the incident is being closed
    var grTask = new GlideRecord('incident_task'); // Target the associated task table
    grTask.addQuery('incident', current.sys_id);
    grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
    grTask.query();
    if (grTask.hasNext()) { // If any open tasks are found
        gs.addErrorMessage('Cannot close the incident because there are ' + grTask.getRowCount() + ' open tasks associated with it. Please close all tasks first.');
        current.setAbortAction(true); // Prevent the current update from saving
    }
}

Closing Associated Incidents when a Problem is Closed:

Once the root cause of a problem is fixed, all associated incidents should ideally be closed as well. This is another “After” Business Rule scenario:

// Business Rule: After Update
// Table: Problem
// Condition: current.state.changesTo(7) // If the problem is being set to Closed
// Script:
if (current.state == 7) {
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Find incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Only update incidents not already closed
    grIncident.query();
    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.close_code = 'Solved by Problem Resolution'; // Set closure details
        grIncident.close_notes = 'This incident was resolved as part of Problem ' + current.number + ' resolution.';
        grIncident.update(); // Update the incident
        gs.info('Incident ' + grIncident.number + ' closed due to problem ' + current.number + ' resolution.');
    }
}

Configuring Fields & Forms for Better Record Creation

Beyond simply creating records, you often need to control *how* users create them, what data they see, and what data they can enter. This involves configuring fields and forms.

Auto-Numbering Fields (Like Incident Numbers)

Every incident, problem, or change request typically gets a unique, sequential number (e.g., INC0001234). To achieve this, when defining your table, navigate to the “Control” tab in the table dictionary. Here, you can check the “Auto-number” field, define a prefix (e.g., INC, PRB, CHG), and specify the number of digits.

Access Control Lists (ACLs) on Table Creation

Security is paramount. When you create a new table, ServiceNow, by default, creates four fundamental ACLs (Access Control Lists) for it: `read`, `write`, `create`, and `delete`. These ACLs typically grant access to users with the `admin` role or a custom role you define during table creation. You can uncheck a box during creation if you prefer to build your ACLs from scratch, but having defaults is often a good starting point.

Field Types Revisited (Quick Glance)

Just a reminder of the versatility: Reference, String, List, Choice, Email, Date/Time, Date, Boolean, Integer, Journal, Attachment are some of the most common types you’ll work with to capture diverse data during record creation.

Understanding Table Relationships (One-to-Many, Many-to-Many)

Data rarely exists in isolation. Relationships define how records in different tables connect:

  • One-to-Many: A single record in one table can be associated with multiple records in another, but each of those multiple records is linked to only one of the first. Example: One User can have Many Incidents, but each Incident is assigned to only One User.
  • Many-to-Many: Records in both tables can be associated with multiple records in the other. Example: One Incident can be associated with Multiple Groups (e.g., a Watch List), and one Group can be associated with Multiple Incidents. These often involve a “junction” table (like `sys_user_grmember` for Users and Groups).

Making Fields Mandatory or Read-Only

Controlling user input is critical. You have several tools to make fields mandatory, read-only, or hidden:

  1. Dictionary Properties: The most basic. Set “Mandatory” or “Read only” directly on the field’s dictionary entry. This applies universally unless overridden.
  2. Dictionary Overrides: Allows you to change the behavior of an inherited field for a specific child table (e.g., making the “Priority” field mandatory for Incidents but not for Problems, even though both inherit from `task`).
  3. UI Policies: Client-side logic to dynamically control field behavior (mandatory, read-only, visible) based on conditions on the form.
  4. Data Policies: Similar to UI Policies but enforce rules at the database level, from all data sources (form, import, web service). They work client-side (if UI-enabled) and server-side.
  5. Client Scripts (`g_form`): For highly dynamic, complex client-side interactions, you can use `g_form.setMandatory(‘field_name’, true);` or `g_form.setReadOnly(‘field_name’, true);`.

Display Fields

A “Display” field in a table’s dictionary indicates which field’s value should be used as the primary identifier or “name” for records in that table when referenced elsewhere (e.g., in a reference field, a list view). While technically you can mark more than one field as display, it’s generally considered bad practice and can lead to confusion and unpredictable behavior. One display field per table is the recommended approach.

Setting Default Values on Fields

To pre-populate fields when a form loads, you can set default values in the field’s dictionary entry. This saves users time and ensures consistency. For example, setting “State” to “New” or “Category” to “Inquiry” on a new incident form.

Reference Qualifiers: Filtering Choices

Reference qualifiers are powerful tools used to restrict the records available in Reference or List type fields, ensuring users select only relevant options.

  1. Simple Reference Qualifiers:

    Description: The easiest type, where you define a static query string. It’s like a WHERE clause in SQL.

    Example: Display only active users in a Caller field on the Incident form.

    How to Use: In the reference field’s dictionary entry, simply type the query in the “Reference qual” field.

    Syntax: active=true^roles=itil

  2. Dynamic Reference Qualifiers:

    Description: Uses a pre-defined “Dynamic Filter Option” that can involve more complex logic or user-specific context without writing JavaScript directly in the field.

    Example: Show only CIs that belong to the current user’s company, or only incidents assigned to the user’s groups.

    How to Use: First, create a “Dynamic Filter Option” (System Definition > Dynamic Filter Options). Then, in the reference field’s dictionary entry, choose “Dynamic” and select your defined option.

    Advantage: Reusable and no scripting needed in the dictionary entry itself.

  3. Advanced Reference Qualifiers (JavaScript):

    Description: For the most complex filtering scenarios, you can write custom JavaScript that returns a query string. This gives you full control and allows for logic based on other field values, user roles, etc.

    Example: Filter users to show only those who are members of the assignment group selected on the form, and whose active status is true.

    How to Use: In the reference field’s dictionary entry, choose “Advanced” for the “Reference qual” and enter your JavaScript code. The script must return a query string.

    Syntax: javascript: 'assignment_group=' + current.assignment_group + '^active=true';

Differences:

  • Simple vs. Dynamic: Simple is static; Dynamic uses reusable, pre-configured logic.
  • Dynamic vs. Advanced: Dynamic is about reusable components; Advanced is direct, custom scripting for unique, complex scenarios.
  • Simple vs. Advanced: Simple is a fixed string; Advanced is dynamic JavaScript code that generates a string.

Dependent Values in Dictionary

Dependent values create a cascading effect between Choice fields. The choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field).

Configuration Steps:

  1. Identify your Parent (e.g., Category) and Dependent (e.g., Subcategory) fields.
  2. For the Dependent field’s dictionary entry, set the “Dependent field” attribute to your Parent field.
  3. When defining the choices for the Dependent field, specify which Parent field value each choice belongs to.

Example:

  • If “Category” is “Hardware”, “Subcategory” choices could be “Laptop”, “Desktop”, “Printer”.
  • If “Category” is “Software”, “Subcategory” choices could be “Operating System”, “Application”.

Calculated Value Fields

A calculated value field’s content is derived from other field values on the same record using a script. This is configured in the field’s dictionary entry by checking the “Calculated” box and providing a calculation script. The script should return the value for the field. For example, calculating a “Full Name” field from “First Name” and “Last Name”.

Attributes: Fine-Tuning Field Behavior

Attributes are key-value pairs added to a field’s dictionary entry that modify its behavior or appearance. They offer granular control without requiring extensive scripting.

Examples:

  • no_email: Prevents the field’s content from being included in email notifications.
  • no_attachment: Disables attachments specifically for a given field (though typically controlled at the table level).
  • no_add_me: For List fields, prevents the “Add Me” button from appearing.
  • tree_picker=true: Displays a reference field with a hierarchical tree picker (useful for things like CI classes).

Collection Field on Table

Every table in ServiceNow has a special dictionary entry called the “Collection” entry. It doesn’t represent a field; instead, it represents the *table itself*. Attributes applied to this “Collection” entry affect the entire table. For instance, to disable attachments for an entire table’s forms, you’d add the `no_attachments` attribute to its Collection dictionary entry.

Dictionary Overrides

We touched on this briefly, but it’s vital for extended tables. A dictionary override allows a field inherited from a parent table to behave differently in a specific child table. For example, if “Short Description” is a string field on the `task` table, you could use a dictionary override to make it mandatory specifically for `incident` records, but optional for `change_request` records.

You can override properties like:

  • Default value
  • Mandatory, Read-only, Display
  • Reference qualifier
  • Choices (for Choice fields)
  • Max length

Data Lookup Rules

Data Lookup Rules are a powerful, code-free way to automatically populate field values on a form based on the values in other fields. They use a separate table (`dl_definition`) to define mappings. For example, you could configure a rule that automatically sets the “Priority” of an incident based on the selected “Impact” and “Urgency” values, or assigns it to a specific “Assignment Group” based on “Category” and “Subcategory.”

UI Policies: Client-Side Form Behavior

UI Policies are client-side scripts (though they don’t require you to write JavaScript unless you check the “Run scripts” box) that dynamically control form behavior. They can make fields:

  • Mandatory
  • Read-only
  • Visible/Hidden (Display)

They also control the visibility of Related Lists. UI Policies are triggered when conditions on the form are met.

Key UI Policy Checkboxes:

  • Global: If checked, the UI Policy applies to all views of the form. Unchecking it allows you to specify particular views.
  • Reverse if false: If checked, when the UI Policy’s conditions are no longer met, the actions are reversed (e.g., a mandatory field becomes optional again). This is almost always desired.
  • On Load: If checked, the UI Policy’s conditions and actions are evaluated and applied when the form initially loads. If unchecked, it only applies when field values change.
  • Inherit: If checked, the UI Policy also applies to tables that extend the current table.
  • Run scripts: Enables the “Execute if true” and “Execute if false” script fields, allowing you to add custom JavaScript logic for advanced scenarios.

Data Policies: Enforcing Data Integrity

Data Policies are similar to UI Policies but operate at a deeper level. They ensure data integrity from *all* data input sources (forms, import sets, web services, scripts) by making fields mandatory or read-only based on conditions. They work both client-side (if configured to apply to UI) and server-side.

Converting UI Policy to Data Policy: Yes, you can convert a UI Policy into a Data Policy by opening the UI Policy record and clicking “Convert this as Data Policy.” This is useful if you realize a UI-only rule needs server-side enforcement.

Limitations of Conversion: Not all UI Policies can be converted to Data Policies. Specifically, UI Policies that control:

  • Data visibility (hiding/showing fields)
  • Form views
  • Related lists
  • Custom client-side scripts

These client-side specific actions cannot be replicated by a Data Policy, which is focused purely on mandatory/read-only enforcement.

Troubleshooting Common Record Creation Issues

Even with all these methods, sometimes things don’t go as planned. Here are some common hiccups and how to troubleshoot them:

  • Missing Mandatory Fields: If a record creation fails (especially via script or import), check if you’re populating all mandatory fields. ServiceNow won’t let you create an incomplete record.
  • ACL Denied: If you get an “Access Denied” error, or fields aren’t showing up as expected, verify your ACLs (read, write, create). Make sure the user or role attempting the creation has the necessary permissions.
  • Incorrect Sys_IDs: When using GlideRecord for reference fields, ensure you’re providing the correct `sys_id`s. A common mistake is using a display name instead of the `sys_id` for reference fields.
  • Business Rule/Validation Interference: Sometimes, another Business Rule or a Data Policy might be preventing a record from being created or a field from being set. Check the logs and debug the relevant Business Rules.
  • UI Policy Conflicts: If fields aren’t behaving as expected on the form, check for conflicting UI Policies or Client Scripts that might be overriding each other.
  • Import Set Transform Map Errors: For bulk imports, carefully review your transform map field mappings and coalesce fields. Errors here can lead to duplicate records or failed imports.

Interview Relevance: Key Takeaways

This entire article is a goldmine for interviews, but here are some top questions you’ll likely encounter:

  • “Name three ways to create a record in ServiceNow.” (Form, Record Producer, Email, GlideRecord, Import Set, Integration)
  • “Explain the difference between a UI Policy and a Data Policy.”
  • “How do you make a field mandatory?” (Dictionary, UI Policy, Data Policy, Client Script)
  • “What is a GlideRecord and how do you use it to create a record?” (Explain `initialize()`, `setValue()`, `insert()`)
  • “What is the significance of the `task` table?” (Base table, field inheritance, `class` field)
  • “When would you use a Reference Qualifier, and what are the types?”
  • “What’s the best practice for assigning roles to users?” (Via groups)
  • “Explain the relationship between Incident, Problem, and Change Management.”

Wrapping Up: Your Toolkit for ServiceNow Record Creation

Phew! We’ve covered a lot of ground, haven’t we? From the foundational concepts of tables and fields to the nitty-gritty of scripting with GlideRecord and configuring forms with policies, you now have a comprehensive understanding of how records come to life in ServiceNow. Whether you’re building a new application, automating a complex workflow, or simply ensuring your service desk runs smoothly, mastering these record creation methods is absolutely essential.

Remember, ServiceNow is designed to be flexible. Choose the right method for the right job, leverage automation wherever possible, and always keep data integrity and user experience in mind. Happy record creating!

Scroll to Top