Update multiple records in a GlideRecord loop

The critical insight developers miss: each update() call inside the loop commits changes for that specific record immediately. Without it, your setValue() calls exist only in memory and vanish when next() moves to the next record. This isn't like updating an array where you batch commit at the end — GlideRecord requires explicit persistence per record. Beginners often assume the loop automatically saves changes, then spend hours debugging why their updates disappeared.

When to use this pattern

• When you need different field values per record based on existing data or calculations
• When processing a bounded result set (under 1000 records) where you control the query filters
• When you need to trigger business rules, workflows, or audit history on each updated record
• When the update logic requires reading multiple field values from the current record

When NOT to use this pattern

• Don't use this for bulk updates of the same value across all records — use updateMultiple() instead for better performance
• Don't use this on large datasets (1000+ records) — you'll hit transaction timeouts and performance issues
• Don't nest this inside another GlideRecord loop — you'll create N+1 database queries that will destroy performance
• Don't use this when you only need to check if records exist — use hasNext() without the loop

Key behaviors and gotchas

• Each update() call triggers business rules, ACL checks, and field validation for that record individually
• The GlideRecord object maintains state between next() iterations — field values persist until explicitly changed or next record loads
• Always check hasNext() before entering the loop to avoid executing business logic on empty result sets
• Use continue statements to skip records that don't need updates — avoid unnecessary database writes
• Domain separation applies to each record individually — you might skip records the current user can't update