Restrict read access to certain SLA's by role?

[Edwin Fuller]

I have a scoped application which I'll call "X" for this discussion. This application is used ONLY by the business users and not IT staff. I've created several SLA's for "X" application and need to give read access to the business users so that can see the SLA's for the X application. However, I don't want them seeing any other SLAs for example Incident SLAs, Change SLAs, etc...

Any users with the "X" role should only see SLA's for the "X" application/table. Hope this makes sense. Can someone point me in the right direction to accomplish this?

Thanks

[awessel · Accepted solution]

Are the SLAs for this scoped application all associated with the same table? If that's the case, you could add a "read" ACL on the task_sla table that includes "X" role in the Roles list and has a condition that Task.Task Type (sys_class_name) is Table X. That should accomplish what you're looking for.

[Edwin Fuller]

Thank you, that worked

[Community Alums]

Just a word of caution for anyone reading this post who (like myself) were trying to stop scoped SLA records appearing in the global reports and vice versa. . .

ServiceNow by design executes the ACL's after it has queried the database, this is for performance related reasons. However I have found that in the case of the SLA's this means that even when applying the above recommended ACL restrictions the scoped SLA's still add to the count in the global charts (even though they don't display in the lists when drilled into).

In my experience it would appear that the charts are rendered before the ACL's are applied therefore your SLA chart can be seriously effected by this issue.

The recommended work around on the HI Portal, that I successfully employed, is to insert a Before Query Business Rule. I will tip my hat to SN Guru, Mark Stanger for the finer details on how to achieve this . . .

Controlling Record Access Before Query Business Rules

hope this helps