In .NET, you validate user input with Data Annotations, FluentValidation, and client-side jQuery validation.

The Real Question

This tests whether you understand ServiceNow's two-layer client-side validation model and can map it to the validation patterns you've used in .NET. The core distinction: UI Policies are declarative (no-code), Client Scripts are imperative (code). Like Data Annotations vs FluentValidation.

The Direct Mapping

// .NET Validation Approaches (what you know)
// 1. Data Annotations: [Required], [MaxLength(100)]
//    → Declarative, on the model, auto-enforced
//
// 2. FluentValidation: RuleFor(x => x.Name).NotEmpty()
//    → Code-based, flexible, conditional
//
// 3. jQuery Validation: Client-side, instant feedback
//
// ServiceNow Equivalents:
// 1. UI Policy = Data Annotations
//    → Declarative, no-code, configured via UI
//    → Make fields mandatory, read-only, visible/hidden
//
// 2. Client Script = FluentValidation + jQuery
//    → Code-based JavaScript, runs in browser
//    → Complex conditional logic, API calls, custom alerts

UI Policy — The No-Code Path

• Set field mandatory, read-only, or visible based on conditions
• Configured entirely through the UI — no code written
• Condition builder: 'When Priority is Critical → Make Assignment Group Mandatory'
• Like decorating a property with [Required] and having the framework auto-enforce it

Client Script — The Code Path

// onChange Client Script
// Like an event handler: $("#priority").change(function() { ... })
function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading) return; // Don't run on form load
  
  if (newValue == '1') { // Priority = Critical
    g_form.setMandatory('assignment_group', true);
    g_form.setValue('notify', 'Do Not Notify');
    // Show an alert — like a toast notification
    g_form.addInfoMessage('P1 escalation: Assignment group is now required');
  } else {
    g_form.setMandatory('assignment_group', false);
  }
}

// onSubmit Client Script
// Like form.addEventListener('submit', function(e) { ... })
function onSubmit() {
  if (g_form.getValue('state') == '6' && !g_form.getValue('close_notes')) {
    g_form.addErrorMessage('Close notes are required when resolving');
    return false; // Prevent submission — like e.preventDefault()
  }
  return true;
}

Where .NET Developers Trip Up

• UI Policies override Client Scripts: If both try to control the same field, UI Policies run after Client Scripts and win. It's like having two middleware components fighting — order matters. The fix: use one or the other per field, not both.
• Client-side only: Neither UI Policies nor Client Scripts enforce on the server. A REST API call bypasses them entirely. You MUST duplicate critical validation in a Business Rule — like how .NET always validates server-side even if client validation exists.
• g_form is not DOM manipulation: Don't try document.getElementById(). ServiceNow provides g_form as the only supported API for form manipulation. Directly touching the DOM will break in future upgrades.
• Four types of Client Scripts: onLoad (page ready), onChange (field changed), onSubmit (form submit), onCellEdit (list editing). Map these to DOM events you already know.