Restricting incidents based on caller and a specific group

Chris DeLaPaz
Tera Contributor

I have a requirement to hide tickets created by an automation tool to all but a specific group.

I have looked at both ACL's and Before query Business rules and it seems with my requirements Before Query BR's is the most likely.

So, the actual requirement would be something like If caller_id is "autotool" and Assignment group is "Group A" hide Incidents from all except if logged in user is a member of Group A.

I have found results similar to this but sans the caller_id aspect, which is important as they want others to see their other tickets, just not the ones generated from this tool.

I have limited scripting knowledge, and I am hoping someone can help me or point me in the right direction to meet this requirement.

Thanks

1 ACCEPTED SOLUTION

Juan Pablo
Tera Expert

Hi Chris,

Yes, an onQuery Business Rule sounds like a good fit for this requirement since you want to dynamically filter records from list/query results based on multiple conditions.

What I would recommend is:

  • Create an Before Query Business Rule on the Incident table

  • Check:

    • if the incident was created by the automation caller

    • if the assignment group is the restricted one

    • if the logged in user is NOT a member of that group

  • If all conditions match, exclude the record from the query

Something like this should work as a starting point:

(function executeRule(current, previous /*null when async*/) {

    var restrictedCaller = 'AUTOTOOL_SYS_ID';
    var restrictedGroup = 'GROUP_A_SYS_ID';

    // If user is member of Group A allow access
    if (gs.getUser().isMemberOf(restrictedGroup)) {
        return;
    }

    // Hide automation generated tickets for everyone else
    current.addEncodedQuery(
        'caller_id!=' + restrictedCaller +
        '^ORassignment_group!=' + restrictedGroup
    );

})(current, previous);

A couple notes:

  • Replace both SYS_ID values with your actual records

  • Using SYS_IDs is safer than names because names can change

  • This approach hides the records from lists and most queries

  • If you need full security enforcement (API access, direct record access, etc.) you may still want complementary ACLs later

I’ve implemented similar solutions before and the query BR approach is usually much simpler to maintain for this kind of visibility rule.

Hope this helps!
Regards,
Juan


If my reply was Helpful, please mark the answer as correct.

View solution in original post

5 REPLIES 5

Thank you sir, this worked perfectly