Restrict RITM visibility in SOW but allow full visibility in ESC

[Daniel_san]

Hi everyone,
I need a group/role of agents to:

1. In SOW (Service Operations Workspace) or the Classic UI, only be able to see and manage the sc_req_items of a certain category.

   • Using an ACL applied to the group/role, I can easily restrict visibility based on the sc_req_items category.
   • But that ACL also applies in ESC (Employee Center) which prevents the members of the group from being able to view their own sc_req_items in ESC.

2. In ESC, members of that group/role should still be able to view their sc_req_items as users, regardless of the tickets' category.

Any ideas or advice?

[Daniel_san]

I’m still searching without success for a way… the ideal solution would be to identify and apply the user/agent’s UI Context (SOW, ESC,...) as a condition in the ACLs. But since ACLs are executed on the server side, I believe that’s not possible 😞

• Given that limitation, with ACLs I can restrict agents in the group so they can only see tickets from the categories they are allowed to manage, as well as their own tickets as end users.
• But these ACLs apply to all user interfaces, both SOW and ESC.
  • It’s not ideal, because in SOW they can see the inner workings of how other support groups manage their tickets
  • This gap can be minimized by hiding fields with client scripts… but it’s annoying and not very scalable/maintainable.

NOTE: I’m surprised not to find an effective/quick way to limit the visibility of certain agents inside the workspaces while keeping their permissions intact as end users in Employee Center. I’d say this must be a common problem, for example for specific agents handling confidential topics or HR cases.

I’ll share anything I find if I discover a workable solution.

[Daniel_san · Accepted solution]

I finally managed to achieve it using several Before Query Business Rules, which allow identifying the UI context using the following (in the example, to identify SOW or UI Classic for sc_req_items):

    var glideURI = gs.action.getGlideURI();

    var url = glideURI.toString();

    if (url.indexOf('api/now/uxf') >= 0 || url.indexOf('sc_req_item.do?') >= 0) { 
( .......)

With that information, it becomes easy to add other conditions based on the agent’s specific role, the RITMs categories... applied only to the needed contexts. It’s not as effective as restricting access with ACLs… but it more or less does the job 🙂