READ ONLY role

[MThomas1]

Hello,

what is the role required to READ tables ( Incident/Problem/Change/CMDB etc)? Tried  snc_read_only but not getting the expected results , when trying to find Incident table from NAV BAR filter, it is not available. 

Thank you.

[Naveen20 · Accepted solution]

The snc_read_only grants table-level read ACLs but it does not grant access to the application menus and navigation modules. That's why the Incident table doesn't show up in your nav bar filter even though you technically have read permission on the underlying table.

There are two layers at play here:

1. Table ACL (read access to records) — snc_read_only covers this broadly.

2. Application Menu / Module visibility (nav bar entries) — These are controlled by roles assigned on the sys_app_module records. Each navigation module (like "Incident > All") has a "Roles" field that determines who can see it.

For the standard ITSM tables, the modules are gated behind the itil role. That's why snc_read_only alone won't surface them in the navigator.

What you can do depends on your goal:

If you want read-only access with nav visibility, the cleanest approach is to combine snc_read_only with one of these strategies:

• Grant itil role — This is the simplest fix and gives nav access to Incident, Problem, Change, etc. The downside is that itil also grants write access, so you'd need to layer on table-level ACL restrictions or use a read-only variant if available.

• Use module-specific read roles (available in newer releases like Xanadu/Yokohama/Zurich): sn_incident_read, sn_change_read, sn_problem_read. These grant both table read ACLs and navigation module visibility without write permissions.

• Create a custom role that inherits snc_read_only and is manually added to the relevant sys_app_module records' Roles field. This gives you fine-grained control.

verification: Navigate to sys_app_module.list, filter where Name = "All" and Application = "Incident", and check the Roles field — you'll see exactly which role is required for that nav entry to appear. That's the missing piece snc_read_only doesn't cover.

If you just need a quick way to access the table without the nav module, you can always type incident.list directly in the nav bar filter — that bypasses module visibility and only checks table-level ACLs, which snc_read_only should satisfy.

[Tanushree Maiti · Accepted solution]

Hi @MThomas1 

You’re probably unable to see the Incident table in the navigation bar because the user doesn’t have the required base ITIL role or the necessary read access (ACLs) for those tables.

Check that- and give/have required access-> It will work.

Refer: KB0748343 The read-only role and how to use it \

[Naveen20 · Accepted solution]

The snc_read_only grants table-level read ACLs but it does not grant access to the application menus and navigation modules. That's why the Incident table doesn't show up in your nav bar filter even though you technically have read permission on the underlying table.

There are two layers at play here:

1. Table ACL (read access to records) — snc_read_only covers this broadly.

2. Application Menu / Module visibility (nav bar entries) — These are controlled by roles assigned on the sys_app_module records. Each navigation module (like "Incident > All") has a "Roles" field that determines who can see it.

For the standard ITSM tables, the modules are gated behind the itil role. That's why snc_read_only alone won't surface them in the navigator.

What you can do depends on your goal:

If you want read-only access with nav visibility, the cleanest approach is to combine snc_read_only with one of these strategies:

• Grant itil role — This is the simplest fix and gives nav access to Incident, Problem, Change, etc. The downside is that itil also grants write access, so you'd need to layer on table-level ACL restrictions or use a read-only variant if available.

• Use module-specific read roles (available in newer releases like Xanadu/Yokohama/Zurich): sn_incident_read, sn_change_read, sn_problem_read. These grant both table read ACLs and navigation module visibility without write permissions.

• Create a custom role that inherits snc_read_only and is manually added to the relevant sys_app_module records' Roles field. This gives you fine-grained control.

verification: Navigate to sys_app_module.list, filter where Name = "All" and Application = "Incident", and check the Roles field — you'll see exactly which role is required for that nav entry to appear. That's the missing piece snc_read_only doesn't cover.

If you just need a quick way to access the table without the nav module, you can always type incident.list directly in the nav bar filter — that bypasses module visibility and only checks table-level ACLs, which snc_read_only should satisfy.

[Tanushree Maiti · Accepted solution]

Hi @MThomas1 

You’re probably unable to see the Incident table in the navigation bar because the user doesn’t have the required base ITIL role or the necessary read access (ACLs) for those tables.

Check that- and give/have required access-> It will work.

Refer: KB0748343 The read-only role and how to use it \

[Purvi Kotadiya · Accepted solution]

snc_read_only is a global safety role that prevents create, update, and delete actions across the platform.
It does NOT grant access to any application tables (Incident, Problem, Change, CMDB, etc.), which is why it’s not sufficient on its own.

- To actually see records, you must add table‑specific read roles, optionally combined with snc_read_only for safety.

Common read‑only roles:

• Incident → sn_incident_read
• Problem → sn_problem_read
• Change → sn_change_read
• CMDB → cmdb_read
• snc_read_only (optional safety net)

[MThomas1]

Thank you all and appreciate your support and guideance with detailed explanation.