Update a field on the current record in a Business Rule

The fundamental rule: in Before Business Rules, direct assignment to current.field_name modifies the record before it's saved to the database. This is the most efficient way to update fields because it piggybacks on the existing database transaction. Never call current.update() in a Before rule — it triggers an immediate database write that will re-fire your Business Rule, creating infinite loops and performance disasters.

When to use this

• Setting calculated fields, timestamps, or derived values on the current record
• Auto-populating empty required fields based on business logic
• Normalizing or formatting field values before they reach the database
• Cross-field validation where you need to modify the record to make it valid

When NOT to use this

• Don't use in After Business Rules — field changes won't persist without calling current.update()
• Don't update other records here — use Script Includes or separate GlideRecord queries
• Don't perform expensive operations that might fail — Before rules can't be easily rolled back
• Don't use for audit trails or notifications — use After rules for post-save actions

Key behaviors and gotchas

• Field changes in Before rules don't trigger display business rules or UI policies
• Journal fields (work_notes, comments) append to existing content, they don't overwrite
• Setting current.sys_id only works on insert operations, not updates
• Reference fields accept sys_id strings — ServiceNow automatically validates the reference exists
• Choice field values are case-sensitive strings, not display values
• Multiple Before rules on the same table see each other's changes within the same transaction