Custom form validation script not triggering on submit in Service Cases module

CRM Adobe Experience Cloud
, , , , , , , ,
1

I’ve implemented custom JavaScript validation for Service Cases forms to enforce business rules before submission, but the validation script isn’t triggering consistently. The script is supposed to check required custom fields and validate email formats before allowing case creation. It works fine in Chrome during testing, but in production we’re seeing cases created with invalid data, suggesting the validation is being bypassed. The script is attached to the form’s submit event, but something’s interfering with the event handling. Here’s the basic structure:

document.querySelector('#caseForm').addEventListener('submit', function(e) {
  if (!validateCustomFields()) {
    e.preventDefault();
  }
});

Users report that sometimes clicking Submit creates the case immediately without any validation messages. This is resulting in invalid case records that require manual cleanup. Has anyone experienced issues with form event handling in aec-2022’s Service Case module?

system 2

Your validation issues stem from three critical areas that need to be addressed comprehensively for reliable form validation in Service Cases.

First, form event handling in Adobe Experience Cloud aec-2022 requires understanding the platform’s event lifecycle. The standard addEventListener approach you’re using only captures user-initiated submit events through button clicks. However, Service Cases forms can be submitted programmatically through multiple pathways: quick-create shortcuts, automated workflows, API calls, or even other custom scripts calling form.submit() directly. None of these trigger the submit event listener. You need to intercept the actual form submission at a lower level:

const originalSubmit = HTMLFormElement.prototype.submit;
HTMLFormElement.prototype.submit = function() {
  if (this.id === 'caseForm' && !validateCustomFields(this)) {
    return false;
  }
  return originalSubmit.call(this);
};

This overrides the submit method itself, ensuring validation runs regardless of how submission is triggered.

Second, custom JS validation needs proper error feedback and state management. Your current implementation prevents submission but may not be providing clear user feedback about why. Implement a validation state object that tracks which fields failed validation and display inline error messages. Also ensure your validation logic handles edge cases like disabled fields, hidden fields, and dynamically added form elements that appear after initial page load.

Third, browser compatibility is crucial for production reliability. The querySelector and addEventListener methods work well in modern browsers, but form validation behavior varies significantly across browser versions. Safari, in particular, has quirks with form event timing. For maximum compatibility, attach validation to both the submit event AND the form’s onsubmit attribute as a fallback. Additionally, test with browser developer tools’ network throttling enabled - slow connections can cause timing issues where validation scripts haven’t fully loaded before users submit forms.

Implement a hybrid approach: override the submit method for programmatic submissions, use event listeners for user interactions, and add inline validation that runs on field blur events to catch errors earlier. This three-layer strategy ensures your business rules are enforced consistently across all submission pathways and browser environments.

This draft is based on general Adobe Experience Cloud knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Form event timing can be tricky in Adobe Experience Cloud. The platform might be using its own form submission handlers that fire before or override your custom validation. Check if there are multiple submit handlers attached to the form - you might need to use event capturing phase instead of bubbling phase to ensure your validator runs first.

4

I’ve seen this exact issue. The problem is often related to how the form is being submitted - if users or other scripts trigger form.submit() directly instead of clicking the button, your event listener won’t fire. You need to override the form’s submit method itself, not just listen to the event.

5

Have you tested across different browsers? You mentioned it works in Chrome but fails in production - what browsers are your users actually using? Safari and Firefox handle form events slightly differently, and older versions of Edge had known issues with custom form validation. Also check if any browser extensions might be interfering with your JavaScript execution. The browser compatibility angle is worth investigating thoroughly.

6

Another thing to check - is your script loading after the form is already rendered? If there’s a timing issue where the form appears before your event listener is attached, some submissions might slip through. Use DOMContentLoaded or ensure your script runs after the form element exists in the DOM.

9

Good point about timing. I’ve verified the script loads properly, but I’m now seeing that some users access the form through quick-create shortcuts which might render the form differently than the standard case creation flow.

10

The quick-create shortcut is likely your culprit. Those modal forms often use different DOM structures and might not have the same form ID. You need to use event delegation or attach your validator to a parent element that’s always present, then filter for form submissions.