Prevent user to reject approval from SOW

[swapnilsoni]

Hello All,

There is a requirement to prevent user to reject approval from related list without putting the comment of rejection in native ui and SOW both.

So in native ui i created oncelledit client script to add one popup to put comment when someone rejecting from list view and mapping it in approval comment. (it is working fine)

But in SOW this client script is not working. so i make the modification in sys_ux_list table for My approvals and All approvals. (it is also working)

Now the issue is, in SOW only if someone open change request or RITM and in related records they open approvals and from there if they rejects it, then it is rejecting. so how can i prevent user to reject approval permanently from list view in SOW. 

Please suggest some solution. i am struggling for this in last week. Thanks in advance.

[swapnilsoni]

Hi @Badrinarayan 

TAB is not approving ACL and Data policy, if you have any other solution please let me know.

[Ankur Bawiskar]

@swapnilsoni 

Data policy or ACL is best approach

BR is also feasible but it won't show the info message I believe as you mentioned earlier

I don't think any other approach is available

Better to ask the TAB to share the best approach from their side and implement that

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

[kateparker7]

Since you've already found that a Before Business Rule works for aborting the action but doesn't show the message in Service Operations Workspace (SOW), and your team is avoiding Data Policies, you have two practical options left:

1. The ACL Approach (Best for blocking edits)
If the goal is to force users to open the record to reject it, create a list_edit type ACL on the sysapproval_approver table for the state field.

This will lock the State field in list views (Native and SOW) so they can't double-click to change it.

This forces them to click into the record, where your existing UI policies/scripts for comments will work perfectly.

2. Fix the Business Rule Message
The reason gs.addInfoMessage() often fails to show in SOW during a setAbortAction(true) is because the transaction is killed before the message is pushed to the UI. Try using:

JavaScript gs.addErrorMessage("Rejection requires a comment. Please open the record to provide details.");
current.setAbortAction(true);

Note: If SOW still swallows the message, the List Edit ACL is your most reliable "low-code" fix. It removes the temptation for users to bypass the rules via the list view entirely.