GlideForm.save()

What It Does

The save() method commits all form field changes to the database while keeping the user on the current record. This is fundamentally different from g_form.submit() which saves then navigates away from the form.

Internally, ServiceNow serializes all modified form fields, validates them through ACLs and Data Policies, then executes the complete save workflow. This includes before Business Rules, database write operations, after Business Rules, and any configured notifications. The form then refreshes with updated field values and system fields like sys_updated_on and sys_mod_count.

The method returns void and provides no indication of save success or failure. If validation errors occur or Business Rules prevent the save, the form will display error messages but the method itself gives no programmatic feedback. This makes error handling challenging compared to server-side GlideRecord.update() operations.

Edge cases include calling save() on new records (works but creates the record), calling it multiple times rapidly (can cause race conditions), and using it in onChange scripts where the save might interfere with user input. The method also behaves differently in Service Portal versus Platform UI, with Service Portal having additional client-side validation steps.

Related methods include g_form.submit() for save-and-navigate, g_form.addInfoMessage() for user feedback after saves, and g_form.clearMessages() for managing form messages. The save() method is often used with these to create seamless user experiences.

When to Use This

Use save() when you need to persist form changes while keeping users in their current context. This is ideal for auto-save functionality, saving draft states, or when additional form interaction is required after the save. Common scenarios include multi-step wizards, forms with dependent field calculations that need persistence, and workflows where saving triggers server-side processing that updates additional form fields.

Avoid save() when users expect to navigate away after saving—use g_form.submit() instead. Don't use it in field onChange scripts unless absolutely necessary, as it can interrupt user typing and create confusing UX. Never use save() as a replacement for proper field validation—use Data Policies or UI Policies instead. The most common misuse is calling it repeatedly in loops or timer functions, which can overwhelm the database and create lock conflicts.

Return Value

The method returns void (undefined in JavaScript terms). No success indicators, error codes, or record sys_ids are returned. This is a fire-and-forget operation from the script perspective, though the platform will display form messages for validation errors or Business Rule issues.

Since there's no return value to check, implement success detection through alternative means: monitor form field updates, use g_form.getReference() callbacks, or leverage Business Rules to set confirmation flags. Never assume the save succeeded without verification, especially for critical business processes.

Platform Behavior & Side Effects

• Executes all before and after Business Rules for insert/update operations in the same order as standard form submissions
• Triggers workflow transitions if the record is part of an active workflow and field changes meet transition conditions
• Updates audit records and field history if auditing is enabled on the table—generates same audit trail as manual saves
• Performance is similar to manual form submission but can be slower if multiple rapid calls create database contention
• Sends configured notifications and events just like standard saves—email notifications fire normally
• Refreshes form with server-computed field values from Business Rules, making calculated fields immediately visible to users
• Respects ACL restrictions and Data Policy validations—save will fail silently if user lacks write access to modified fields