Dynamic Default Value Pattern in…

beginnerTested on Xanadu

The Dynamic Default Value Pattern enables you to automatically populate form fields with contextually relevant data when users create or access records in ServiceNow. Unlike static default values defined in dictionary entries, this pattern calculates defaults based on current user properties, related record data, business logic, or external system information.

This pattern addresses the common need to reduce manual data entry while ensuring data consistency across your ServiceNow instance. For example, automatically setting a user's department, location, or manager when they submit a catalog request, or pre-populating incident fields based on the affected configuration item's attributes.

The pattern works through multiple mechanisms including onLoad client scripts for form fields, variable default values for catalog items, and dictionary-level defaults. Understanding the order of precedence between these mechanisms is crucial - dictionary defaults execute first during record initialization, followed by catalog variable defaults, and finally client-side onLoad scripts that can override previous values.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Use This When

Use this pattern when you need to reduce user input effort by intelligently pre-filling form fields based on context, user attributes, or related data. It's particularly valuable in catalog items, incident forms, and any scenario where default values depend on dynamic conditions rather than static business rules.

Avoid When

Avoid this pattern for simple static defaults that never change, as dictionary default values are more efficient. Don't use it when the default calculation is expensive or relies on large dataset queries that could impact form load performance, and avoid overusing client-side defaults that could conflict with business rules or cause confusion.

Implementation

Server-side

// Business Rule: Before Insert - Set Dynamic Defaults
// Table: incident, When: before, Insert: true
(function executeRule(current, previous) {
    // Set priority based on caller's VIP status and category
    if (current.caller_id && !current.priority) {
        var caller = new GlideRecord('sys_user');
        if (caller.get(current.caller_id)) {
            if (caller.vip == 'true' || current.category == 'hardware') {
                current.priority = '2'; // High priority
            } else {
                current.priority = '3'; // Moderate priority
            }
        }
    }
    
    // Auto-assign to caller's location support group
    if (current.caller_id && !current.assignment_group) {
        var userLocation = new GlideRecord('sys_user');
        if (userLocation.get(current.caller_id) && userLocation.location) {
            var supportGroup = new GlideRecord('sys_user_group');
            supportGroup.addQuery('u_location', userLocation.location);
            supportGroup.addQuery('name', 'CONTAINS', 'Support');
            supportGroup.query();
            if (supportGroup.next()) {
                current.assignment_group = supportGroup.sys_id;
            }
        }
    }
    
    // Set default description template based on category
    if (current.category && !current.description) {
        var templates = {
            'hardware': 'Hardware Issue - Device: \nProblem Description: \nSteps Taken: ',
            'software': 'Software Issue - Application: \nError Message: \nBrowser/Version: ',
            'network': 'Network Issue - Location: \nAffected Services: \nTime Started: '
        };
        current.description = templates[current.category] || '';
    }
})(current, previous);

Client-side

// Client Script: onLoad - Incident Form Dynamic Defaults
function onLoad() {
    // Only set defaults for new records
    if (!g_form.isNewRecord()) {
        return;
    }
    
    // Get current user info via GlideAjax
    var ga = new GlideAjax('DynamicDefaultsUtil');
    ga.addParam('sysparm_name', 'getUserDefaults');
    ga.addParam('sysparm_user_id', g_user.userID);
    ga.getXMLAnswer(function(response) {
        var userDefaults = JSON.parse(response);
        
        // Set caller to current user if empty
        if (g_form.getValue('caller_id') == '') {
            g_form.setValue('caller_id', g_user.userID);
        }
        
        // Set location based on user's default location
        if (userDefaults.location && g_form.getValue('location') == '') {
            g_form.setValue('location', userDefaults.location);
        }
        
        // Set company from user's company
        if (userDefaults.company && g_form.getValue('company') == '') {
            g_form.setValue('company', userDefaults.company);
        }
        
        // Set contact type based on user's preferred method
        if (userDefaults.preferred_contact && g_form.getValue('contact_type') == '') {
            g_form.setValue('contact_type', userDefaults.preferred_contact);
        }
    });
    
    // Set current date/time for opened field
    if (g_form.getValue('opened_at') == '') {
        var now = new GlideDateTime();
        g_form.setValue('opened_at', now.getDisplayValue());
    }
}

The server-side business rule demonstrates setting dynamic defaults during record creation using database lookups and conditional logic based on related records like caller information. The client script shows how to use GlideAjax to fetch user context and populate form fields on load, with proper checks to only apply defaults to new records and empty fields to avoid overwriting existing data.

Alternatives

Dictionary Default Values with JavaScript

More performant for simple defaults since they execute during record initialization without additional client-server round trips, but limited to server-side context and cannot access current form state or user session information.

UI Policies with Default Value Actions

Excellent for conditional defaults that depend on other field values and provide better user experience with immediate visual feedback, but limited to simple value assignments and cannot perform complex calculations or external data lookups.

Transform Maps for Imported Data

Perfect for setting defaults during data imports or integrations where you can apply business logic during the transformation process, but only applicable to automated data creation scenarios rather than interactive form submissions.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue