What It Does

The update() method commits changes made to GlideRecord field values to the database. It performs a SQL UPDATE operation on the table row identified by the current record's sys_id. The method validates field values, applies field-level security, and executes the database transaction within ServiceNow's change management framework.

Internally, ServiceNow builds a SQL UPDATE statement containing only the fields that changed since the record was loaded or last saved. The platform compares current field values against the original values stored in the GlideRecord's internal state. Fields with identical values are excluded from the UPDATE statement, which improves performance and reduces unnecessary audit entries.

The method returns the record's sys_id as a string when the update succeeds. It returns null if the update fails due to validation errors, ACL restrictions, or Business Rule exceptions. Unlike insert(), the method never returns an empty string—it's either a valid 32-character sys_id or null.

The record must exist in the database and have a valid sys_id for the update to proceed. Calling update() on a GlideRecord without a sys_id throws a runtime error. If no fields have changed since the record was loaded, the method still returns the sys_id but skips the database operation entirely—a performance optimization that also prevents unnecessary Business Rule execution.

This method differs from updateMultiple() which operates on query result sets, and updateWithReferences() which handles reference field updates differently. The update() method works only on the single record currently loaded in the GlideRecord instance.

When to Use This

Use update() when you need to modify an existing record and want all Business Rules, notifications, and audit mechanisms to fire normally. This is the standard approach for programmatic updates in Business Rules, Script Includes, and scheduled jobs where you want the change to behave exactly like a manual user update through the form interface.

Avoid this method when you need to bypass Business Rules or when updating large numbers of records. Use autoSysFields(false) combined with update() to prevent automatic updates to sys_updated_by and sys_updated_on. For bulk operations, updateMultiple() performs better since it processes multiple records in a single database round trip.

The most common misuse involves calling update() inside a loop without considering the performance impact of individual database transactions. Each call triggers a complete Business Rule evaluation cycle, making this pattern extremely slow for batch operations. Another frequent mistake is calling update() on a GlideRecord that was instantiated but never loaded with get() or queried.

Return Value

Returns a string containing the record's 32-character sys_id when the update succeeds, formatted as a standard GUID (e.g., "a1b2c3d4e5f6789012345678901234ab"). The return value is always either this valid sys_id string or null if the update failed due to validation errors, security restrictions, or exceptions thrown by Business Rules.

Always check for null before using the return value, especially when field validation or ACL enforcement might prevent the update. The sys_id remains unchanged whether the update succeeds or fails—the return value simply indicates success or failure of the operation. Use if (gr.update()) { } to branch on success since any non-null string evaluates to true in JavaScript.

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

  • Triggers all "before update" Business Rules, then "after update" Business Rules if the database operation succeeds
  • Evaluates ACL rules for the current user's update permissions on each modified field
  • Writes audit history entries to sys_audit table for tracked fields, plus sys_audit_relation if reason parameter provided
  • Updates sys_updated_on timestamp and sys_updated_by user reference automatically unless autoSysFields(false) was called
  • Fires notifications, workflows, and SLA processing based on field changes and condition matching
  • Performance varies by Business Rule complexity—simple updates execute in milliseconds, complex rule chains can take seconds
  • Commits immediately as a single database transaction—no rollback available once the method returns successfully
⚠️

Calling update() inside an update Business Rule on the same table creates infinite recursion unless properly guarded with condition checks.