The g_form.setReadOnly() method provides client-side field protection that's visually obvious to users but fundamentally incomplete for data integrity. Unlike server-side enforcement, this creates a UX convenience layer that can be bypassed by anyone who understands how to manipulate form submissions. The most common mistake developers make is treating this as actual security β it's presentation logic that must be backed by Data Policies or Business Rules to prevent circumvention through direct API calls, mobile apps, or browser developer tools.
When to use this
- Preventing accidental edits to calculated or system-managed fields like
total_costorapproval_history - Conditional field locking based on user roles or record state where the business logic allows exceptions
- Workflow-based form states where fields should be locked during specific approval stages
- Creating dependent field relationships where one field controls the editability of another
When NOT to use this
- Enforcing security policies or compliance requirements β use ACLs and Data Policies instead
- Fields that should never be editable after record creation β use
read_only=truedictionary attribute - Mobile or Service Portal forms where client scripts don't execute β use UI Policies instead
- Performance-critical forms with many conditional fields β UI Policies are more efficient
Key behaviors and gotchas
- Client-side enforcement only β values can still be modified through REST API, Import Sets, or Business Rules
- Read-only fields are excluded from form submission payload, so server-side scripts won't see attempted changes
- Reference fields made read-only will disable both the lookup icon and autocomplete functionality
- Choice fields become unclickable dropdowns but retain their visual styling unlike disabled fields
- Always check
isLoadingandisTemplatein onChange to prevent conflicts with form initialization - Setting
setReadOnly(field, false)won't override dictionary-level read-only attributes or ACL restrictions
Read-only enforcement disappears completely in mobile apps and Service Portal unless you implement parallel server-side validation. A field locked by client script can be freely edited in the mobile app's native forms.
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros β scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.