Allowing Catalog Task Save Without Filling All Mandatory Variables

In ServiceNow, catalog tasks often include mandatory variables that must be completed before a record can be saved or closed. This form validation ensures important information is collected, but it can sometimes hinder workflows. For example, an IT technician might need to assign a catalog task or add initial notes before all required fields are known.

By default, ServiceNow’s form validation will block the save and display an error (e.g., “The following mandatory fields are not filled in…”) until every mandatory field or variable is populated. This can frustrate users and delay task hand-offs. In practice, users may need to save a partially completed form as a draft—especially when a request form has many required fields that users may not have information for in one session.

The ability to save without filling everything allows work to continue and prevents losing progress due to session timeouts or missing data. In this article, we’ll explain the problem with Catalog Task mandatory fields and walk through a custom ServiceNow UI Action solution to bypass mandatory field validation. We’ll also discuss edge cases (like tasks with no variables) and alternative approaches to handle ServiceNow form validation more flexibly.

The Problem: Mandatory Variables Blocking Saves

ServiceNow treats any field or catalog variable marked as mandatory as required input – you cannot save or update the record until those fields are filled. On Catalog Task (sc_task) forms, this means if the associated request item has mandatory variables (for example, information the fulfiller must provide), the platform will prevent saving the task mid-process. The form will throw a validation message and refuse to update if even one required variable is empty. This default behavior is by design: “Mandatory fields are marked with a field status indicator and must contain a value before the record can be saved”. In many cases, the variables are made mandatory to ensure that fulfillers eventually provide that data (such as closure information or approvals) before the task is completed.

However, there are scenarios where this strict validation isn’t ideal. Consider a workflow where a catalog task is generated with several required input variables, but the task is meant to be assigned to another team for completion. The first agent receiving the task might only fill in a couple of fields (like setting the Assignment Group or a short description) and want to save or reassign the task, leaving the remaining variables for the assignee to fill later. Out of the box, ServiceNow would block this update because not all mandatory variables are filled. The result is that users either resort to dummy data (which is bad practice) or cannot progress the task at all. In one community scenario, an administrator described wanting to disable mandatory variables on a catalog task only for interim saves (e.g., editing the short description) while still keeping those variables mandatory for final task closure. This highlights a common requirement: the need for a “Save as Draft” capability on task forms that bypasses certain mandatory field requirements.

Solution: Custom UI Action to Bypass Mandatory Field Validation

The most straightforward solution is to create a custom UI Action (a form button) on the Catalog Task table that allows saving the record without enforcing mandatory fields. This UI Action will act as a "Save Draft" or "Save (Ignore Mandatory)" button, enabling users to update the task record even if required variables are not yet filled in.

Below is a step-by-step guide to implement this solution:

1. Create a New UI Action on the sc_task Table: In ServiceNow, navigate to System Definition > UI Actions and click New. Configure the UI Action as follows:

   • Table: Catalog Task [sc_task].

   • Title: Save (Ignore Mandatory) – (This will be the label on the form button; you can choose an appropriate name like "Save Draft").

   • Action name: (Leave blank or set a unique name like save_draft. If you use a custom action name, we'll handle it in script.)

   • Show insert and update: Ensure it’s set to display on the form (you can choose to show it on Form buttons section).

   • Condition: (Optional) You can restrict when this button appears. For example, you might only show it to certain roles (like ITIL or task assignees) or only when the task is not closed. You could also add a condition to show it only if there are mandatory fields empty (though this is optional; showing it always for in-progress tasks is usually fine).

   • Client: Check this box, because we need client-side logic to bypass the validation.

   • Onclick: (If available) You can specify a client-side function to call. Alternatively, we will write the client script in the Script field and mark it as client-executed.

     
     

2. Client-Side Script to Bypass Mandatory Check: The key to this solution is to override or disable the normal mandatory field check that runs on form submit. ServiceNow’s client API includes the method g_form.checkMandatory() which returns false if any mandatory field is empty, preventing the save. We can short-circuit this by temporarily overriding this method or forcing it to return true. In the UI Action’s script (with client enabled), add code like the following:

// Client-side script for the Save (Ignore Mandatory) UI Action 
if (typeof g_form !== 'undefined') { 
	// Override the mandatory check to always succeed 
	g_form.checkMandatory = function() {
		return true; 
	}; 
	// Submit the form (update the record) without mandatory validation
	g_form.submit(); 
}

Let’s break down what this does.

First, we confirm g_form is available (ensuring the script is running on the client where the form object exists). Then we override g_form.checkMandatory with a custom function that simply returns true. Normally, g_form.checkMandatory() goes through all mandatory fields and returns false if it finds any unfilled ones, which blocks the submission. By replacing it with a function that returns true, we’re telling the form “everything is filled out, proceed” – effectively bypassing the validation.

Immediately after, we call g_form.submit(), which triggers the form submission just as if the user clicked the standard Save/Update button. Because we altered the check, the submission will go through even if some required fields or variables are empty. In other words, this UI action bypasses mandatory variables in ServiceNow by tricking the client-side form validation into allowing the save.

Important: Make sure the UI Action’s "Client" checkbox is checked and the "Isolate Script" option (if present) is false. If Isolate Script is true, the script runs in a sandbox and might not be able to modify g_form. We want it to access the global g_form object to override the check. By keeping it non-isolated, the code above can successfully override the form’s checkMandatory function.

3. Test the UI Action: Impersonate a typical fulfiller user and open a Catalog Task that has mandatory variables. Leave one or more required variables blank and click the new Save (Ignore Mandatory) button. The expected result is that the record saves successfully (changes are stored) and no error about mandatory fields appears. The mandatory variables will still be empty (and marked with the red asterisk on the form), but your updates (like work notes, assignment, etc.) should be saved. Essentially, you've saved the record as a draft despite missing required info. If no variables were present or nothing was missing, the button’s behavior is just like a normal save – it will update the record with no issues.

   
   

By following the above steps, we implemented a custom ServiceNow UI Action that bypasses the usual form validation. Under the hood, we manipulated g_form.checkMandatory on the client side, which is a supported client-side approach to skip mandatory checks. This approach works for catalog task variables as well as regular fields, because it overrides the check for the whole form. (If you wanted to be more granular—say, bypass only variable checks but still enforce certain fields—you would need a more complex script to target just those fields. For most cases, overriding the whole check is acceptable for a draft save action.)

Edge Cases and Considerations

Before rolling this out, consider a few edge cases and best practices:

• Tasks with No Variables: If a catalog task has no variables (or no mandatory ones), the custom Save action isn’t really needed. You might still show the button for consistency, but it will just perform a normal save (since g_form.checkMandatory would return true anyway if nothing’s required). It won’t harm anything to use it. If you prefer, you can add a UI action condition to hide the button when g_form.getMissingFields().length == 0 (no missing mandatory fields) so it only appears when there’s something to bypass. This is optional and up to your UI preference.

  
  

• Mix of Mandatory Fields and Variables: If your form has both standard fields and variables that are mandatory, our UI action as written will bypass all of them. This means if, for example, Assignment Group (a normal field) and a couple of variables are mandatory and blank, clicking the custom Save will save without requiring any of them. Make sure this is what you want. In some cases, you may only want to ignore variable requirements but still enforce certain core fields. Achieving that would require identifying variable elements specifically (perhaps by name prefix like variables.<name> and toggling their mandatory status off). The out-of-the-box mandatory check doesn’t distinguish field types – it’s all or nothing when using checkMandatory. So design your process accordingly. It may be acceptable that any required field can be skipped on draft save as long as the expectation is to fill them later.

  
  

• Server-Side Mandatory Enforcement: Our solution works at the client/UI level. It effectively tricks the form into submitting despite empty required fields. It’s worth noting that if there are server-side mechanisms enforcing mandatory data (like a Business Rule or Data Policy), those will still trigger. For example, if a Data Policy is set to require that a field is not empty on update, the server will refuse to save even if the client bypassed the UI check. In ServiceNow, dictionary-level mandatory (not null) constraints could also block inserts of truly empty values. Generally, catalog variables aren’t enforced at the database level, so this isn’t an issue for them. Just be aware: this UI action does not bypass any server-side validation or business logic – it only bypasses the client-side form validation. In testing, ensure no Business Rule or Flow will reject the update due to missing info. If there is, you might need to adjust those or use a different approach (like a field that marks the record as a draft to skip certain rules).

  
  

• User Guidance: It’s a good idea to inform users that using this button means the task is in a draft or incomplete state. If you didn’t add a server-side message, consider adding a client-side notification. For instance, after g_form.submit() you could potentially set a cookie or session value to show a message on reload. A simpler method is to rename the button label to something descriptive like "Save as Draft (ignore required fields)" so users understand its purpose. Another approach is to set a field (perhaps a custom boolean like Draft on the task) when this UI action is used. That could be done in the server script and would let you visually flag the task as a draft in lists, etc., until all mandatory fields are completed. These additions ensure that while we bypass mandatory field validation, everyone is aware that more work is needed on that task.

  
  

• Alternate Solutions: The UI Action method is a direct workaround, but consider if the requirement can be met with a process change. One alternative is to use conditional mandatory logic. For example, you could make those variables mandatory only when the task moves to a certain state (like “Ready for Closure”). This can be done with a Catalog UI Policy or client script that makes variables mandatory at certain stages, but not when the task is initially created or in a “Open/Draft” state. In fact, one common approach is to have a Draft state for tasks or requests where fields are not mandatory, and only enforce them when transitioning to an active or closed state. By using UI Policies or Data Policies tied to state, you ensure the fields eventually get filled but allow intermediate saves. The downside is complexity in managing states and ensuring users don’t forget to fill the fields later. Another alternative (less elegant) is instructing users to use the built-in Insert or Cancel actions: for instance, some have discovered that using the Cancel action name can bypass mandatory checks, essentially tricking the system. However, relying on such hacks is not recommended for a clean solution, as it may have unintended side effects and isn’t obvious to users. The custom UI Action approach described here is a supported and clearer solution to implement a “save without mandatory” feature.

Handling mandatory variables on Catalog Task forms requires a balance between enforcing data collection and providing flexibility in workflow. In this article, we explored how ServiceNow’s default form validation can impede progress when Catalog Task mandatory fields are not yet filled, and we provided a step-by-step solution to bypass that restriction using a custom ServiceNow UI Action. By overriding the g_form.checkMandatory check on the client side, we allow records to be saved as drafts without all required fields, giving users the freedom to update tasks incrementally. We also discussed edge cases such as tasks with no variables (where this isn’t needed) and pointed out that server-side rules still apply for data integrity.

In practice, this solution acts as a safety net for scenarios where users need to save their work in progress. It’s important to ensure that incomplete tasks are eventually completed – you might enforce mandatory fields at a later stage or at least communicate to users that those fields remain required. As a next step, you should thoroughly test this UI action in your environment: create a task with various required variables and verify you can save using the new button, then later fill in the remaining fields and complete the task. Additionally, review your process to decide if a draft state or conditional mandatory logic might complement this solution.

By implementing a bypass for mandatory variables in ServiceNow, you improve user experience for fulfillers handling catalog tasks, without permanently sacrificing the data requirements. The key is to use this capability judiciously – it should streamline workflows, not encourage leaving required information blank. With the custom UI action in place, ServiceNow administrators can ensure that workflows continue smoothly, and technicians can save their updates at any point in the task lifecycle. This approach provides the best of both worlds: flexibility in form usage and the ability to enforce data completion when truly needed, keeping your Catalog Task process both user-friendly and compliant with data requirements.