What It Does

The setReadOnly() method modifies the DOM properties of a form field to prevent user input. When set to read-only, the field displays a gray background, the cursor changes to indicate non-editable content, and keyboard/mouse input is blocked. The field value remains accessible for reading and the field participates normally in form submission.

Internally, ServiceNow manipulates the HTML input element's readonly attribute and applies CSS classes for visual styling. For reference fields, both the reference value field and the display value field are affected. Choice fields become non-interactive dropdowns, and date fields disable the calendar picker.

This method returns void and executes immediately when called. No confirmation or status indication is provided. If the field name doesn't exist on the current form, the method fails silently without throwing an error or logging a warning.

⚠️

This method provides client-side visual feedback only. Malicious users can bypass this restriction through browser developer tools or direct API calls. Always implement server-side security through ACLs.

The method works with most field types including strings, integers, references, choice lists, and dates. Journal fields and HTML fields have limited support - the content becomes non-editable but formatting controls may remain active. Calling setReadOnly(fieldName, false) removes client-side restrictions but cannot override server-enforced read-only states from ACLs, UI policies, or field definitions.

When to Use This

Use setReadOnly() for conditional field protection based on user input or record state. Common scenarios include locking approval fields after submission, preventing edits to calculated values, or restricting access based on user roles determined at runtime. This method excels when read-only status depends on complex business logic that UI policies cannot easily express.

For simple role-based or state-based restrictions, use UI policies instead of client scripts. UI policies provide better performance and automatically handle the server-side enforcement that setReadOnly() lacks. Avoid using this method for security-critical fields where unauthorized changes could cause business or compliance issues - implement proper ACLs for those scenarios.

Return Value

This method returns void and provides no indication of success or failure. The method executes synchronously and any visual changes appear immediately in the browser. Since there's no return value to check, verify field state changes through visual inspection or by calling g_form.isReadOnly(fieldName) if programmatic verification is needed.

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.

No spam · Unsubscribe anytime

Platform Behavior & Side Effects

  • No server-side events fire - this is purely a client-side DOM manipulation that doesn't trigger Business Rules, ACLs, or audit logging
  • Field values remain in the form submission payload regardless of read-only status - the restriction is visual/interactive only
  • Executes instantly with no performance impact - simply adds HTML attributes and CSS classes to existing DOM elements
  • State persists only for the current form view - refreshing the form or navigating away resets all fields to their original read-only configuration
  • Works identically in onLoad, onChange, and onClick client script contexts - no timing or sequencing restrictions
  • Multiple calls to the same field are safe - the last call determines the final state with no cumulative effects or conflicts
  • Mobile and Service Portal compatibility varies - test thoroughly in target environments as touch interfaces may handle read-only fields differently