IRM Access - R/O access for Watch List

[brittanymcc]

Hello! I have been getting stuck with an access use case. We leverage a MSP and they have a compliance team that requires read only access to issues that were identified by MSP employees. We have been adding the MSP employees to the watch list and provided them with the roles sn_grc.business_user_lite and sn_smart_asmt.template_reader. They are able see the dashboard we created for them but they receive the error that no rows were returned due to access issues. What roles should these users be seeing for the use case or what suggestions do you have for us to help provide this information without providing too broad of access. As an example, we have considered adding them as their own 'Issue Origin' and trying to find a way to give them access to issues opened against that issue origin, but that was getting complicated as well. Thank you so much for the help! 

[Me Being Mustaq]

Hi @brittanymcc ,

For your use case where MSP compliance team members need read-only access only to issues identified by MSP employees, the roles you currently assign (sn_grc.business_user_lite and sn_smart_asmt.template_reader) provide limited access mostly relevant to GRC and assessment templates but may not grant read access to issue records themselves or filtered by creator.

Suggested approach to provide controlled read-only access to issues:

1. Use Scoped Roles and Custom Access Controls:
   • Create a dedicated role for MSP compliance users with read access on the issue tables.
   • Implement record ACLs that allow read only if the issue was created by an MSP employee or if the MSP employee is on the watch list.
   • This way, MSP users see only issues relevant to them, not all issues.
2. Leverage the Watch List for Access Filtering:
   • Use the watch list as the source of access control.
   • Record ACL scripts can check if the current user is in the watch list on the issue record (current.watch_list contains current user).
   • Combine this with the role assignment to ensure only read-only rights.
3. Avoid Broad Roles:
   • Avoid granting more powerful roles like full incident or case access.
   • The OOB snc_read_only role makes all accessible records read-only but requires that the baseline access controls already allow read access to the right records.
4. Example ACL Script for Read Access:

// Read access on Issue table for MSP compliance users
answer = false;
if (gs.hasRole('your_msp_readonly_role')) {
// allow read if user is in watch list or creator of issue
if (current.watch_list.indexOf(gs.getUserID()) !== -1 || current.opened_by == gs.getUserID()) {
answer = true;
}
}

1. Handling Dashboards:
   • Dashboards typically respect ACLs; if no rows show, the ACLs likely block visibility.
   • Ensure dashboards’ data sources (reports, list widgets) are filtered or accessible for MSP role scope.
2. Use User Criteria and Dynamic Groups:
   • You can use User Criteria in ServiceNow to further filter visible data based on dynamic user membership, attributes, or watch list membership.
3. Alternative: Issue Origin User Mapping
   • As you noted, creating MSP users as 'Issue Origin' or similar fields can get complex.
   • It’s often cleaner to rely on watch list or assigned groups with ACLs instead of custom origin matching.

Resources and Further Reading

• sn_grc.business_user_lite is limited; full business_user role or custom roles may be needed.
• ServiceNow docs: GRC Business User Role
• Role-based ACL scripting best practices
• Use Access Control rules with script condition referencing watch list or issue creator

This solution balances least privilege with access need and fits your MSP compliance team's requirements without exposing unnecessary data.

Please refer to the below link:-

• https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0864247
• https://www.servicenow.com/community/csm-forum/role-and-acl-to-allow-read-only-for-cases-not-working...

If it is helpful, please hit the thumbs button and accept the correct solution by referring to this solution in the future it will be helpful to them.

Thanks & Regards,

Mohammed Mustaq Shaik