What We Did

We built a ServiceNow catalog item that users could fill out and submit. The form appeared to submit successfully—no error messages, no validation failures. But no RITM (Request Item) was ever created in the backend. This is a dangerous failure mode because it looks successful to the user but nothing actually happens.

We traced the root cause to an onSubmit client script that was silently blocking submissions.

How We Did It

Identifying the Issue

When a catalog item doesn't create an RITM:

1. Check if there are form validation errors (usually caught at submit)

2. Check if there are server-side workflow issues (look at workflow logs)

3. Check if client script onSubmit is returning false (silently blocks submit)

The first two are obvious. The third is invisible—no error, no warning, just nothing.

The Culprit

In the onSubmit client script, we had:


// BAD: Blocks submission
function onSubmit() {
  // ... some logic ...
  return false;
}

This returns false, which tells the form "don't submit." The browser stops the request before it even reaches the server. No error, no message—just a silent failure.

The Fix

ServiceNow's onSubmit contract is:

  • Return `true` (or nothing) → submit normally
  • Return `false` → block submission
  • Call `g_form.addErrorMessage()` → show error and block submission

Our fix:


// GOOD: Allows submission
function onSubmit() {
  // ... some logic ...
  return true;  // Explicitly allow
}

Or if you need to block conditionally:


function onSubmit() {
  if (someConditionIsFalse) {
    g_form.addErrorMessage("Please fix this field");
    return false;  // Block with user-visible error
  }
  return true;  // Allow normal submit
}

Debugging Pattern

When catalog items vanish without error:

1. Check browser console for JavaScript errors (F12)

2. Check the onSubmit client script—does it return false?

3. Check workflow logs (might reveal server-side blocks)

4. Create a test RITM as admin to ensure the table itself works

The browser console is your friend—it shows what the client script is doing before the server ever sees the request.

Why It Matters

This is a subtle but critical issue in ServiceNow form development. Client-side blocking looks like success to the user, which creates support tickets like "my request went through but nothing happened."

The solution is simple once you know to check it: never return false from onSubmit unless you're also showing an error message. If your script needs to run async logic, use g_form.validateFields() or server-side validation instead.

For teams building catalog-driven service portals or self-service workflows, this is a must-know pattern.