Restrict shopping cart to a single Customer/Account or split checkout into multiple REQs

[SuhejlA]

I have a question regarding the shopping cart behavior in the Customer Service Portal.

From the documentation and several Community posts, I understand that ServiceNow's standard behavior is:

• A single checkout creates one REQ with multiple RITMs.
• Different Requested For users can exist within the same REQ.
• Multiple REQs are not created automatically from a single shopping cart.

However, our business requirement is based on the Customer/Account, not on the Requested For user.

Example:

• Item 1 → Customer A
• Item 2 → Customer A
• Item 3 → Customer B

We want to ensure that all RITMs within a single REQ belong to the same Customer/Account. If items for multiple Customers are added to the cart, we are considering two possible approaches:

1. Prevent adding items for a different Customer to the existing cart (one Customer per cart).
2. Allow the cart to contain multiple Customers, but split the checkout into separate REQs (and Cases) per Customer.

Has anyone implemented a similar requirement?

[Vikram Reddy]

Hello @SuhejlA,

Before you build either option, get a real business justification pinned down first: why does a REQ boundary need to track Customer/Account at all, when Requested For already scopes ownership and approvals per item?

Blocking a user mid-cart because item three belongs to a different account is a rough shopping experience, and a table-level restriction on sc_cart_item has a much bigger blast radius than this one requirement needs, since it fires for every catalog item in the instance, not just the ones the rule is meant for.

If the requirement genuinely holds up, option 2 is the better pattern, and best practice is to handle the split server-side at checkout rather than gatekeeping the cart. Group the cart items by Customer/Account first, then call sn_sc.CartJS() and its checkoutCart() method once per group instead of once for the whole cart. Each call to checkoutCart() returns its own REQ number and RITM ids, so you naturally get one REQ per Customer/Account without touching the add-to-cart flow at all. Wrap that grouping logic in a Flow Action so it's reusable and testable independent of the catalog items themselves.

Thank you,
Vikram Karety
Octigo Solutions INC

[SuhejlA]

Thanks for the suggestion. One thing I'm still trying to understand: CartJS().checkoutCart() normally checks out the entire cart. How do you ensure that only the items for one Customer/Account are processed in each call?