Feature/email validation

[Dhruvyadav2000]

PR Description:

Add on Submission Email Validation for Catalog Items

Summary

Implements onSubmit email validation client script that prevents incorrect email entries from being submitted when a user submits a catalog item.

Changes

• onSubmit Validation Script: Email format validated during catalog item submission.
• Dedicated README: Implementation guide for catalog form submission validation.

Features

• Prevents form submission if email format is invalid
• Dynamic error messages
• Uses regex pattern for standard email format
• Lightweight and fully client-side — no server calls

User Experience

• Invalid email: Red error message with example format
• Valid email: Form submission proceeds normally
• Empty field: No validation triggered
• Reduces user frustration on submission

Benefits

• Ensures only valid email addresses are submitted
• Errors corrected before form submission
• Better data quality in catalog requests
• Reduces form abandonment rates

Testing Checklist

• Valid email formats proceed with form submission normally
• Invalid formats display error message
• Messages clear dynamically on input change
• No validation during form load
• Empty fields handled correctly

Setup

Replace 'email_field_name' with actual variable name in script before deployment.

Pull Request Checklist

Overview

• Put an x inside of the square brackets to check each item.
• I have read and understood the CONTRIBUTING.md guidelines
• My pull request has a descriptive title that accurately reflects the changes and the description has been filled in above.
• I've included only files relevant to the changes described in the PR title and description
• I've created a new branch in my forked repository for this contribution

Code Quality

• My code is relevant to ServiceNow developers
• My code snippets expand meaningfully on official ServiceNow documentation (if applicable)
• I've disclosed use of ES2021 features (if applicable)
• I've tested my code snippets in a ServiceNow environment (where possible)

Repository Structure Compliance

• I've placed my code snippet(s) in one of the required top-level categories:
  • Core ServiceNow APIs/
  • Server-Side Components/
  • Client-Side Components/
  • Modern Development/
  • Integration/
  • Specialized Areas/
• I've used appropriate sub-categories within the top-level categories
• Each code snippet has its own folder with a descriptive name

Documentation

• I've included a README.md file for each code snippet
• The README.md includes:
  • Description of the code snippet functionality
  • Usage instructions or examples
  • Any prerequisites or dependencies
  • (Optional) Screenshots or diagrams if helpful

Restrictions

• My PR does not include XML exports of ServiceNow records
• My PR does not contain sensitive information (passwords, API keys, tokens)
• My PR does not include changes that fall outside the described scope

[ravichandra1998g]

Hello @Dhruvyadav2000

Thank you for your contribution.

This cannot be merged as this repo already has email regex code (#683), so it might be worth checking for duplicates or similar codes before submitting to keep the repo clean.

[Dhruvyadav2000]

Hello @Dhruvyadav2000

Thank you for your contribution.

This cannot be merged as this repo already has email regex code (#683), so it might be worth checking for duplicates or similar codes before submitting to keep the repo clean.

Hi @ravichandra1998g , Thank you for your feedback. I understand the concern about duplicating existing email regex code.
However, my implementation is tailored specifically for validating an email variable within a catalog item form, which addresses a unique use case not fully covered by the existing code.

[Dhruvyadav2000]

Hi @ravichandra1998g , also I would appreciate having a discussion before closing any issue directly.

[ravichandra1998g]

You can always reopen a closed PR.

That said., we also have email validation regex for catalog forms too (#2052)

The first PR you have submitted was an incorrect code submitted without testing. I have mentioned in that revert PR itself that we already have existing code for that.(#2399)