GlideForm.submit()

What It Does

The g_form.submit() method programmatically submits the current form and triggers the same sequence of events as clicking the Save button in the form header. ServiceNow processes all client-side validations first, then submits the form data to the server where Business Rules, ACLs, and other server-side logic execute.

The internal mechanism follows this sequence: client scripts with onSubmit triggers execute first and can halt the submission by returning false. If validation passes, ServiceNow serializes the form data and sends it to the server. Server-side processing includes before Business Rules, database write operations, after Business Rules, and finally the navigation response back to the client.

This method returns void immediately after initiating the submission process, not after the server completes processing. You cannot determine success or failure from the return value because the method is asynchronous. The browser will navigate away from the current form if the submission succeeds, or remain on the form if validation fails or an error occurs.

An important edge case occurs when onSubmit client scripts return false - the form submission halts completely and the user stays on the current form. This is the primary mechanism for client-side validation that prevents form submission. Server-side validation failures also prevent navigation but allow the submission attempt to complete, often displaying error messages on the form.

The relationship to g_form.save() is crucial: both save the record, but only submit() navigates away afterward. Use save() when you want to persist changes but keep the user on the current form for additional work. Both methods trigger the same server-side processing, but the user experience differs significantly in the navigation behavior.

When to Use This

Use g_form.submit() when building custom UI Actions, client scripts, or UI Policies that need to replicate the standard Save button behavior. Common scenarios include conditional submission logic where you want to submit the form only after performing additional client-side processing, or when creating custom workflow buttons that should save and navigate away. This method is also appropriate for automated form submissions triggered by timer events or external API calls within catalog items or custom applications.

Choose g_form.save() instead when you need to persist data but keep the user on the form for continued editing. Use g_form.saveRecord() when you need a callback function to handle post-save logic while remaining on the form. Avoid submit() in scenarios where you need to perform additional client-side operations after saving, since the navigation will interrupt your script execution.

Common misuse patterns include calling submit() inside onChange client scripts without user confirmation - this creates a jarring experience where users lose their current context unexpectedly. Another mistake is using submit() in mobile applications without considering the different navigation patterns, which can break the mobile user experience flow.

Return Value

The method returns void (undefined in JavaScript) immediately when called, before any server processing occurs. This return behavior means you cannot use the return value to determine whether the submission succeeded or failed. The method initiates the submission process asynchronously and returns control to the calling script immediately, while the actual form processing happens in the background.

Since there is no return value to check, you cannot safely chain operations after calling submit() - the browser will navigate away if the submission succeeds, terminating any subsequent JavaScript execution. If you need to handle post-submission logic, implement it in server-side Business Rules or use g_form.saveRecord() with a callback function instead.

Platform Behavior & Side Effects

• Triggers all onSubmit client scripts first, which can prevent submission by returning false
• Executes before Business Rules, writes to database, then executes after Business Rules in sequence
• Respects ACLs on the table and individual fields, potentially blocking the submission silently
• Sends notifications configured on the table and triggers workflow activities if the record participates in active workflows
• Updates audit history for audited fields and creates journal entries for work notes or comments
• Performance is equivalent to manual form submission - not cached and requires full server round-trip processing
• Navigation occurs after successful server processing, typically returning to the list view or previous page in browser history