GlideRecord.setValue()

What It Does

The setValue() method modifies a field's value in memory within a GlideRecord object. It operates on the internal field representation, not the database directly. This means your changes exist only in the current script execution context until you explicitly save them.

ServiceNow performs automatic type conversion based on the target field's dictionary definition. When you pass a string to a boolean field, the platform converts it according to its internal rules. For reference fields, the platform expects the sys_id of the referenced record as a string, then resolves the display value automatically.

The method returns void and provides no indication of success or failure. Invalid field names are silently ignored - the method won't throw an error if you specify a field that doesn't exist. This can lead to subtle bugs where you think you're setting a value but nothing happens.

Field validation and business rules don't execute during setValue() calls. The platform defers all validation until you call update() or insert(). This allows you to set multiple related fields without triggering intermediate validation failures.

Unlike direct property assignment (gr.field_name = value), setValue() works with dynamic field names stored in variables. It also provides consistent behavior across different field types, especially for complex fields like journals and reference fields where direct assignment can be unpredictable.

When to Use This

Use setValue() when you need to set field values dynamically based on variables, especially in loops or when the field name is determined at runtime. It's essential for reference fields where you have the sys_id but need the platform to handle the relationship properly. The method is also preferred when setting multiple fields that might have interdependent validation rules.

Avoid setValue() when you know the field name at development time and can use direct assignment instead. For display value assignment on reference fields, use setDisplayValue() rather than trying to pass display values to setValue(). Don't use this method for journal fields where you want to append entries - use setWorkNotes() instead.

Common misuse includes trying to set values on fields that don't exist (silently ignored), passing display values instead of sys_ids for reference fields, and assuming that setting a value immediately validates it. These patterns lead to data inconsistency and debugging headaches.

Return Value

The method returns void (undefined in JavaScript). No return value indicates success or failure, making error detection impossible at the method level. You can't chain setValue() calls or use the result in conditional statements.

To verify that a value was set correctly, retrieve the field value after calling setValue() using getValue() or direct property access. Failed assignments due to invalid field names leave the original value unchanged.

Platform Behavior & Side Effects

• No business rules, ACLs, or field validation execute during the setValue() call - all deferred until update() or insert()
• Database remains unchanged until you explicitly call a save method - changes exist only in memory
• Performance is fast since no database operations or complex validation occurs during the method call
• Works identically in before/after business rules, script includes, and background scripts - no behavioral differences
• Invalid field names are silently ignored with no error logging - the operation appears successful but does nothing
• Audit records capture the final field state after update(), not the individual setValue() operations
• Reference field resolution happens immediately - the platform validates sys_id existence and caches display values