Restrict duplicate request to be created on the basis of catalog variable

[shrutikasin]

What is the recommended ServiceNow approach to prevent duplicate catalog item submissions when the duplicate check depends on a catalog variable (qr_value)?

Specifically:

1. How can I stop the submission before both REQ and RITM are created?
2. Is checking sc_item_option_mtom the correct approach for catalog variable duplicate validation?
3. Is there a better architectural solution than a BR on sc_req_item?
4. Has anyone implemented duplicate prevention for catalog variables in Service Portal successfully?

Any guidance, examples, or best practices would be greatly appreciated.

Thanks in advance!

[Rafael Batistot]

Hi @shrutikasin 

Combine an ⁠onSubmit⁠ Catalog Client Script with a ⁠GlideAjax⁠ Script Include to validate ⁠qr_value⁠ against active RITMs before allowing submission.

[Ankur Bawiskar]

@shrutikasin 

you can use onSubmit catalog client script + GlideAjax combination

what did you start with and where are you stuck?

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Deėpak Sharma]

hi @shrutikasin 

1. How can I stop the submission before both REQ and RITM are created?
   You must validate the duplicate at the clientside UI layer using a catalog clientscript. Serverside aborts trigger during or after the checkout process.
2. Is checking sc_item_option_mtom the correct approach for catalog variable duplicate validation?
   - it is highly inefficient because servicenow allows you to dot walk variables directly on the sc_req_item table.
3. If you abort the RITM insert via a BusinessRule, the service catalog cart API will have already created the REQ record, leaving an empty, orphaned request in your system.

Note : The best is to allow the REQ and RITM to generate, then use a flowdesigner to trigger on the RITM to instantly check for duplicates and If a duplicate is found, the flow should automatically change the RITM and REQ State to "Closed Incomplete" with a work note explaining the rejection.

Happy to help! If this resolved your issue, kindly mark it as the Correct answer ✅ and Helpful and close the thread 🔒 so others can benefit too.

Warm Regards,

Deepak Sharma

Community Rising Star 2025

[Shahjay]

Hi @shrutikasin ,

The short version: you can’t reliably stop this with a Business Rule on sc_req_item. By the time a before-insert BR on the RITM runs, checkout has already progressed far enough that aborting the RITM often leaves you with an empty or orphaned REQ. The fix has to happen client-side, before checkout runs at all.

1. How to stop the submission before REQ and RITM are created

Use an onSubmit Catalog Client Script paired with a GlideAjax Script Include. The Script Include checks whether an active RITM already exists for the same catalog item and the same qr_value. Since this runs before checkout, nothing gets created if the check fails.

2. Is sc_item_option_mtom the right table to check?

No — avoid walking sc_item_option_mtom / question_answer for this; it’s an unnecessary join. sc_req_item supports reading catalog variables directly, so query sc_req_item and filter on variables.qr_value. That’s the documented, supported way to read variable values off the RITM without the extra hop through the mtom table.

3. Is there a better architecture than a BR on sc_req_item?

Yes — client-side prevention plus a server-side safety net:

-Client-side (primary):  the onSubmit Catalog Client Script above. GlideAjax is asynchronous, so a return false placed inside the callback won’t stop the submission — by the time the callback fires, onSubmit has already returned. The correct pattern is to return false immediately, run the async check, and only trigger the form submission from inside the callback once the result comes back clean.

- Server-side (safety net): client scripts can be bypassed via REST, mobile, or Import Sets, so back this up with a Flow (or a scripted REST check, or an after-insert Business Rule) that catches the duplicate once the RITM/REQ do exist and closes the pair as Closed Incomplete with a work note explaining why. This covers anything that skips the UI entirely.

4. Has this been done successfully in Service Portal?

Yes — the usual miss isn’t the logic, it’s the **UI Type** field on the Catalog Client Script. If it’s set to Desktop only, it silently won’t fire in Service Portal. Set it to All (or explicitly include Service Portal) so the same validation runs there too.

If this helped, please mark it Helpful / Accept as Solution.
Thanks