Suggestions Needed for Optimizing Incident Access Logic

[Raj90]

Hello Team,

I need your insights on the following requirement.

We currently have a "before query" business rule on the Incident table, which needs to glide through multiple tables to verify user access. This approach, however, has been causing slower load times when users try to access the incident list.

To address this, we created a new list-type field on the Incident form to store all users related to each incident, replacing the old query-based business rule with a new script that checks if the logged-in user is included in this list field. After populating this list-type field with relevant users for all incidents, we noticed that loading times remain as slow as before.

I’d appreciate your suggestions on the best ways to optimize this setup. Would adding indexes to the list-type field help? Or are there alternative methods you would recommend?

Thanks in advance for your help!

[Vishnu kumar R]

Hi @Raj90 ,

If you are trying to restrict access to records then ACL with Script is more efficient then Query BR.

ACLs are optimized by the platform for enforcing access control without adding much overhead.

You can query thru multiple table records and provide access when query satisfies.

Sample script syntax:

//Add in read/write ACL accordingly
if(Your condition)
{
answer = true;
}else
{
answer = false;
}

Please mark helpful if it helps with your query.

[Ravi Gaurav]

Hello @Raj90 

What you can do is try Indexing the List-Type Field and try using  GlideCacheManager to cache the list of users that are related to the incident, reducing the need to repeatedly check this for every access.