Restricting Ticket Visibility to assigned to and Opened by Users

[sireland]

I have been tasked with Restricting the visibility of offboarding tickets to the person the ticket was opened by and the specified technician that the ticket is assigned to. What is the best practice way to accomplish this? I tried to implement a before query business rule on the request, ritm, and catalog task table, but was having issues getting it to work properly. Does anyone have any suggestions or methods for accomplishing this? Thank you for your time and help! 

[Vaibhav Chouhan · Accepted solution]

I wouldn’t recommend using a before-query business rule for this. The best practice way to restrict visibility in ServiceNow is through Read ACLs.

If the requirement is that only the person who opened the ticket and the technician it’s assigned to can see it, you can handle that cleanly with a Read ACL on the relevant tables (sc_request, sc_req_item, and/or sc_task).

You’d create a Read ACL on the table and use a script like this:

answer = false;

// Only restrict Offboarding catalog items
if (current.cat_item && current.cat_item.name == 'Offboarding') {

    if (gs.getUserID() == current.opened_by ||
        gs.getUserID() == current.assigned_to) {
        answer = true;
    }

} else {
    // For all other items, allow normal access
    answer = true;
}

[Vaibhav Chouhan · Accepted solution]

I wouldn’t recommend using a before-query business rule for this. The best practice way to restrict visibility in ServiceNow is through Read ACLs.

If the requirement is that only the person who opened the ticket and the technician it’s assigned to can see it, you can handle that cleanly with a Read ACL on the relevant tables (sc_request, sc_req_item, and/or sc_task).

You’d create a Read ACL on the table and use a script like this:

answer = false;

// Only restrict Offboarding catalog items
if (current.cat_item && current.cat_item.name == 'Offboarding') {

    if (gs.getUserID() == current.opened_by ||
        gs.getUserID() == current.assigned_to) {
        answer = true;
    }

} else {
    // For all other items, allow normal access
    answer = true;
}

[sireland]

Hello Vaibhav,

I attempted this solution but found that the role based acls and other acls are evaluated first giving access to any sn_request_read. Is there any way to resolve this issue? 

Sincerely,

[SumanthDosapati · Accepted solution]

@sireland 

If you have another ACL which grants read access based on just role, then your new ACL will not make sense because if atleast one ACL is evaluated to true, it provides access.
I can think of 3 options for now:

1. Update the existing ACL with role to add this additional condition
2. You can instead try a Deny-Unless ACL 
3. Share the BR logic you tried so that we can help.

Accept the solution and mark as helpful if it does, to benefit future readers.
Regards,
Sumanth

[sireland]

@SumanthDosapati 

I was able to get it to work by updating the role ACLS. Although, I prefer the deny unless solution as it doesn't require modifying the OOTB role ACLS. Thank you for all the information and assistance!