Way to close list view incidents without blocking auto closure job

[MouktikB]

There is a requirement to restrict users from closing incidents (p1 and p2) in list view without filling up a certain field. Created a BR to do the same and it worked as expected but also blocked the auto closure scheduled job. Created a data policy to replace that but wondering if that would also block the auto closure job? Please suggest if there are any better ideas and will not at all affect the auto closure job. This has led to quite some incidents which did not close automatically.

[MouktikB]

Thanks for your response. 
Actually, my script had a line current.setAbortAction(true) inside the scripting conditions which probably blocks auto closure job.
Do you think Adding this line gs.getSession().isInteractive() in Condition and then having the exiting script will help?

[Ankur Bawiskar]

@MouktikB 

in your BR simply add this in condition field

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

[Dr Atul G- LNG]

H i @MouktikB 

---

As per best practice, a user should not be able to close an incident — only resolve it.

Second, please check whether the State field is editable in the list view. If it is, it’s better to use an ACL to restrict it so that users cannot change the incident state directly from the list view. That is the recommended approach.

Third, if you still want to display an error message, you can use an onCellEdit Client Script. As soon as the user attempts to change the state to Closed (or any restricted state), show an error message and prevent the save action.

[Aditya_hublikar]

Hello @MouktikB ,

 As per my understanding in servicenow there is OOTB data policy which will restrict you to update incident state to resolved/close in list view  and that will not restrict auto closure. If you want to add your custom conditions then you can update their . But It not recommended to configure OOTB data policy .

If you already written business rule then you can go with @Ankur Bawiskar  gs.getSession().isInterative() method . This ensures the validation runs only when a user updates the record from UI (form or list view), and it will not impact scheduled jobs, flows, or background processes.

If this helps you then you can mark it as helpful and accept as solution.

Regards,

Aditya,

technical Consultant