Field messages are persistent UI elements that survive form refreshes, section reloads, and even browser back/forward navigation. Unlike alert() or g_form.addInfoMessage(), these messages stick to their field until explicitly cleared. This persistence is both the power and the trap—developers forget to clear messages and create confusing user experiences where outdated warnings appear on unrelated records.
When to use field messages
- Field-specific validation errors that shouldn't block form submission
- Contextual warnings about field values based on other field combinations
- Dynamic help text that changes based on current form state
- Real-time feedback during field value changes in onChange scripts
When NOT to use field messages
- Hard validation that should prevent form submission—use
onSubmit()return false instead - General form-level messages—use
g_form.addInfoMessage()for broader notifications - Static help text that never changes—use field help text configuration instead
- Messages on list views or related lists—this only works on forms
Key behaviors and gotchas
- Messages persist across form refreshes, section reloads, and browser navigation—always clear them explicitly
- Message types are
'info'(blue),'warning'(yellow),'error'(red)—no other values work - Only one message per field—calling
showFieldMsg()twice on the same field replaces the first message - Messages appear on hidden fields but aren't visible until the field is shown
- Field messages don't prevent form submission—they're purely informational
- Messages work on reference fields, choice fields, and all standard field types
⚠️
Field messages created in onChange scripts during isLoading will appear on every form load, even for different records. Always check isLoading and return early to avoid this.
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.