UI Policies on List View

[simmons_andre]

We have written several UI Policies for forms in custom scoped apps for our client. These UI Policies contain complex logic for data entry based on task state and user role. We centralized this logic in UI Policies, instead of spreading across multiple business rules and ACLs, to ease future maintenance. Initially, the client did not allow users to make edits in the List view. Now the client wants to allow users to make edits in the list view. Because the users can personalize the list view they could add a field that normally they may not have access to based on their role or task status or a combination of both.

The one option we have thought about is creating ACLs to limit which fields could be added to the list view. This way we could allow simple fields like description, which has no restrictions, to be editable, but restrict fields such as Assignment Group which does have restrictions. The drawback we found with this approach is that is a user has already added the field to their list view then the ACL will not remove it. We would have to write a fix script to prune the restrictive fields from the users list view. This may be disruptive to users and not provide a good user experience initially.

Are there any other options we could explore?

[vinothkumar]

Can you try converting the UI policies to Data policies and try again. So that it will be executed on server side

[simmons_andre]

I did. According to the first line in the ServiceNow Docs "Data policies enable you to enforce data consistency by setting mandatory and read-only states for fields."

Our requirement is to set field visibility as well as edibility based on role or request status. Also, there are fields that are dependent on other fields which could cause issues if the user changes one field in the list view, but not the other one because the "onChange" client script does not fire in the list view.