GlideForm.setMandatory() — ServiceNow API

g_form.setMandatory(fieldName, mandatory)→ void

beginnerTested on Xanadu

What It Does

The setMandatory method dynamically controls whether a form field is required on the client-side. When you set a field to mandatory (true), ServiceNow adds a red asterisk next to the field label and prevents form submission if the field is empty. Setting it to optional (false) removes the asterisk and allows the form to be submitted with an empty value.

Internally, ServiceNow updates the field's client-side properties and modifies the form's validation behavior. The platform adds or removes the mandatory CSS class from the field's label element and updates the form's validation registry. This change is immediate and visible to the user without requiring a page refresh or server round-trip.

The method returns void and provides no feedback about success or failure. If you specify a field name that doesn't exist on the current form, the method fails silently without throwing an error or logging a warning. This can make debugging field name typos challenging, especially when the method call appears to work but has no visible effect.

The mandatory state change only persists for the current browser session. If the user refreshes the page or navigates away and returns, the field reverts to its original mandatory state as defined in the dictionary or UI policy. This client-only behavior means setMandatory cannot override server-side validation rules — a field that's mandatory at the dictionary level will still be enforced on the server even if you set it to optional on the client.

This method works closely with isMandatory, which checks the current mandatory state, and clearValue or setValue which modify field values. When building dynamic forms, you'll typically use these methods together to create conditional validation based on user selections or field values.

When to Use This

Use setMandatory when you need conditional field requirements based on user input or dynamic form behavior. Common scenarios include making fields required when a specific category is selected, requiring approval justification when certain conditions are met, or creating stepped forms where different sections become required as the user progresses. This method is perfect for improving user experience by showing requirements contextually rather than overwhelming users with all mandatory fields upfront.

For permanent field requirements that apply to all records, use dictionary mandatory settings or data policies instead of client scripts. If you need server-side enforcement of dynamic requirements, implement the logic in a Business Rule rather than relying solely on setMandatory. For complex conditional requirements that involve multiple fields or business logic, consider using UI Policies which provide a more maintainable declarative approach than multiple client scripts.

Return Value

The method returns void (undefined) in all cases, whether the operation succeeds or fails. There is no return value to check for success, and no exception is thrown for invalid field names or parameters. The only way to verify the method worked is to visually inspect the form or use g_form.isMandatory(fieldName) to check the resulting state.

Since there's no failure indication, always double-check field names for typos and test thoroughly in your target environment. The silent failure behavior means a misspelled field name will result in no visual change to the form, which can be mistaken for the method not working properly when the issue is actually an incorrect parameter.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

Platform Behavior & Side Effects

No server-side Business Rules, workflows, or notifications are triggered by this method since it only affects client-side display and validation
No database writes occur — the mandatory state change exists only in browser memory until the page is refreshed or the user navigates away
Executes immediately with no network latency — performance impact is negligible since it only manipulates DOM elements and client-side validation arrays
Changes are immediately visible to the user and affect form submission validation, but do not override server-side mandatory field validation configured in the dictionary
Multiple calls to the same field will overwrite previous settings — the last call determines the final mandatory state
UI Policies that run after your client script can override the mandatory state set by this method, creating potential conflicts in complex forms
Form submission will be blocked if any fields set to mandatory via this method are empty, displaying the standard "The following mandatory fields are not filled in" error message

Parameters

Name	Type	Required	Description
fieldName	string	Yes	The name of the field to make mandatory or optional. Must match the exact field name from the table dictionary. Case-sensitive and will fail silently if the field doesn't exist on the current form.
mandatory	boolean	Yes	Whether the field should be mandatory (true) or optional (false). When true, adds a red asterisk and prevents form submission if empty. When false, removes mandatory indication and allows empty 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

Code Examples

Basic usage — conditional requirement based on categorybasic

function onChange(control, oldValue, newValue, isLoading) {
    // Skip processing during form load
    if (isLoading) return;
    
    // Make assignment_group mandatory for hardware requests
    if (newValue == 'hardware') {
        g_form.setMandatory('assignment_group', true);
        g_form.showFieldMsg('assignment_group', 'Required for hardware requests', 'info');
    } else {
        g_form.setMandatory('assignment_group', false);
        g_form.hideFieldMsg('assignment_group');
    }
    
    // Make justification mandatory for high-priority requests
    var priority = g_form.getValue('priority');
    if (newValue == 'emergency' || priority == '1') {
        g_form.setMandatory('justification', true);
    }
}

This onChange client script makes fields conditionally mandatory based on category selection. Notice the isLoading check to prevent unnecessary processing during form initialization.

Intermediate — stepped form with progressive requirementsintermediate

function onLoad() {
    // Initially hide and make optional all step 2 fields
    var step2Fields = ['business_justification', 'cost_center', 'expected_delivery'];
    
    step2Fields.forEach(function(field) {
        g_form.setVisible(field, false);
        g_form.setMandatory(field, false);
    });
    
    // Check if we should show step 2 based on current values
    checkStep2Visibility();
}

function checkStep2Visibility() {
    var requestType = g_form.getValue('request_type');
    var estimatedCost = parseFloat(g_form.getValue('estimated_cost')) || 0;
    
    // Show step 2 for high-value or consulting requests
    if (requestType == 'consulting' || estimatedCost > 5000) {
        var step2Fields = ['business_justification', 'cost_center', 'expected_delivery'];
        
        step2Fields.forEach(function(field) {
            g_form.setVisible(field, true);
            g_form.setMandatory(field, true);
        });
        
        g_form.showFieldMsg('business_justification', 'Additional approval required', 'info');
    }
}

This pattern creates a stepped form experience where additional required fields appear based on user selections. Combining visibility and mandatory state creates a cleaner user experience.

Advanced — avoiding conflicts with UI policiesadvanced

// WRONG: This can create conflicts with UI policies
function onChange(control, oldValue, newValue, isLoading) {
    if (newValue == 'vip') {
        g_form.setMandatory('approval_reason', true);
        // Problem: UI policy might override this setting
    }
}

// RIGHT: Check for existing UI policy settings first
function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading) return;
    
    // Use setTimeout to run after UI policies
    setTimeout(function() {
        if (newValue == 'vip') {
            // Check if UI policy already handles this
            if (!g_form.isMandatory('approval_reason')) {
                g_form.setMandatory('approval_reason', true);
            }
            
            // Always verify the final state
            if (g_form.isMandatory('approval_reason')) {
                g_form.addInfoMessage('VIP requests require approval reason');
            }
        }
    }, 100);
}

This example shows how UI policies can conflict with setMandatory calls and demonstrates using setTimeout to ensure client scripts run after UI policies complete. Always verify the final state when conflicts are possible.

Gotchas

The method fails silently with no error if the field name doesn't exist on the form — always double-check field names for typos.

UI policies that execute after your client script can override the mandatory state you set, creating unexpected behavior in complex forms.

Client-side mandatory settings don't affect server-side validation — dictionary mandatory fields will still be enforced regardless of setMandatory(false).

The mandatory state resets to the original dictionary or UI policy setting when the user refreshes the page or navigates away and returns.

Calling setMandatory on fields that are hidden or read-only has no visible effect but still affects form validation, potentially confusing users with invisible validation errors.

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