Mandatory additional comments on CSM portal when approver rejects approval is not working
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-08-2026 01:52 AM - edited 09-08-2026 03:07 AM
Hi all,
Thank you in advance,
Victoria
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-08-2026 02:00 AM
you can check this against any PDI which is on Zurich or any fresh instance and see if that's OOTB behavior.
💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-08-2026 05:03 AM
Hi Victoria,
For the CSM Approval Info widget you’re using, the rejection reason is not currently enforced by the widget code. When the user clicks Reject, the client script inn the widget sends rejected directly to the server, and the server updates the sysapproval_approver record without checking for a reason first.
I’d recommend cloning the CSM Approval Info widget rather than changing the OOTB widget directly. In the cloned widget, add spModal to the client controller and intercept the rejected action. Show a prompt asking for the rejection reason and only continue when the user has entered a value.
Pass that value to the server as something like c.data.rejectionReason. Then, before gr.update(), check whether the action is rejected and save the reason to the comments field on the approval record.
This keeps the approval flow unchanged for Approve, while Reject requires a reason. I’d also test this in a sub production instance first and verify whether E Signatures are enabled, since the widget has separate handling for those actions.
If this helped, could you mark it as the solution or helpful?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Friday
The widget does not enforce a rejection reason out of the box. A Community expert explains why: when you click Reject, the widget’s client script sends the rejected state to the server, and the server updates the approval record without checking for a reason. The fix is to clone the widget and add a prompt, rather than editing the out-of-box widget.
- Go to Service Portal > Widgets, open CSM Approval Info and clone it. Use your own name for the copy.
- In the clone’s client controller, add spModal and intercept the reject action. Show a prompt asking for the rejection reason, and continue only if the user enters a value.
- Send the value to the server, for example as c.data.rejectionReason.
- In the server script, before the gr.update() call, check whether the action is rejected. If it is, save the reason to the comments field on the approval record.
- Replace the original widget with the clone on the CSM portal page that shows approvals.
- Test approve, reject with a reason and reject with a blank reason.
Community examples of the same change use spModal.open with input: true, which includes a text box in the prompt. They also copy the entered text into the approval record’s comments field on the server side. If your instance has e-signature approvals enabled, check the widget’s separate e-signature handling, because it treats those actions differently. Also check that the comment is not saved twice, which community members report happening in some versions.
If you want a server-side safeguard for every channel, community answers suggest a before-update business rule or data policy on sysapproval_approver. It would require comments when the state changes to rejected. Note that one thread reports an extra “Invalid value on Update” message with a business rule that aborts the update. Test it in a sub-production instance, and prefer the data policy if you see that message.
Sources: