Only opened by should able to see RITM not other how to restrict

[s_nandhini]

Hi All,

I have a requirement only opened by should able to see the Req and RITM not other even requested for should not able to see the request for particular catalog item.

I tried restricted via ACL and Query BR but still requested for and other ITIL users able to see the RITM and REQ.

Please guide me which is the best approach.

[DanielJ43996773]

Hi @s_nandhini 

This requirement is quite common, but also tricky because REQ (sc_request) and RITM (sc_req_item) visibility is influenced by multiple factors beyond just ACLs.

Based on your description, the issue is that:

Opened by should see the records
Requested for should NOT see them (for a specific catalog item)
Other ITIL users are still able to see REQ/RITM
Key Point (Why your current approach is not working)

Using only ACLs or Query Business Rules is often not enough because:

OOB roles like itil already have broad read access to sc_req_item and sc_request
The platform evaluates multiple ACLs (table + field + role-based)
Some visibility comes from request filters, relationships, and implicit access
Recommended Approach (Best Practice)
1. Use ACL with Script Condition (Most Important)

Instead of just role-based ACLs, you need a scripted ACL on:

sc_req_item
sc_request

Example logic:

// Allow only opened_by
if (gs.getUserID() == current.opened_by.toString()) {
return true;
}

// Optional: allow admins
if (gs.hasRole('admin')) {
return true;
}

// Deny for requested_for explicitly (for specific item)
if (current.cat_item == 'SYS_ID_DO_ITEM') {
return false;
}

return false;

2. Restrict by Catalog Item (Granular Control)

If this applies only to specific catalog items, include condition:

current.cat_item == 'SYS_ID_DO_ITEM'

This avoids impacting all requests globally.

3. Avoid Query BR for Security

Query Business Rules:

Can be bypassed (e.g., via API, background scripts)
Are not security controls, only data filters

Use them only as complement, not primary enforcement.

4. Review OOB Roles (Important)

Role itil has broad visibility. You have 3 options:

Adjust ACL to override OOB access (recommended)
Remove unnecessary roles (risky in enterprise)
Use data segregation via ACL script (best option)

5. (Advanced) Use Before Query BR + ACL Together

For performance + UX:

ACL → security enforcement
Before Query BR → hide from lists

Example Query BR:

if (!gs.hasRole('admin') && current.cat_item == 'SYS_ID_DO_ITEM') {
current.addQuery('opened_by', gs.getUserID());
}
Final Recommendation (Clean Architecture)
ACL (scripted) → security layer (mandatory)
Query BR → UI filtering (optional)
Condition by catalog item → avoid global impact
Common Mistake

The most common mistake is assuming:

“If I restrict Requested For, they won’t see the record”

But in ServiceNow:

Visibility ≠ ownership
Roles override many assumptions

If this answer helps, please mark it as helpful.

Regards,
Dan

[Ankur Bawiskar]

@s_nandhini 

why not use query BR on sc_req_item table?

Something like this

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

    if (!gs.getSession().isInteractive() || gs.hasRole('admin')) {
        return;
    }

    var catItemId = 'PUT_CATALOG_ITEM_SYS_ID_HERE';

    current.addEncodedQuery(
        'cat_item!=' + catItemId +
        '^NQcat_item=' + catItemId + '^request.opened_by=' + gs.getUserID()
    );

})(current, previous);

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[s_nandhini]

How to restrict for request also and in the RITM opened by and particular group should able to see the RITM.

[Ankur Bawiskar]

@s_nandhini 

you can enhance the logic for REQ

did you test it for RITM based on script I gave and it worked fine?

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏