Normal user cannot see CMDB reference variable values in catalog item – best practice?

[Kishore47]

Hi All,

In a ServiceNow catalog item, I have reference variables pointing to:

• cmdb_ci_computer

• cmdb_ci_service

• sys_user

I observed that a normal user (no roles):

• ❌ Cannot see values for cmdb_ci_computer and cmdb_ci_service

• ✅ Can see values for sys_user

After assigning the cmdb_read role to the user, the CMDB reference variable values started displaying correctly.

My understanding is:

• sys_user is publicly readable

• CMDB tables are role-restricted, so cmdb_read is required

I want to confirm:

• Is assigning cmdb_read the correct and best-practice approach for this requirement?

• Are there any recommended alternatives (ACL-based or group-based access) for production environments?

Please share your thoughts or real-time project experience.

Thanks in advance.

[sivasankaris]

Hi @Kishore47 ,

Yes, your understanding is correct

• sys_user

  • Publicly readable

  • Normal users can see reference values without any role

• CMDB tables (cmdb_ci_*)

  • Protected by ACLs

  • Normal users cannot read CIs

  • Hence reference variables appear empty

• Assigning cmdb_read

  • ✅ Works as expected

  • ✅ Commonly used solution

  • ⚠️ Grants read access to the entire CMDB (can be too broad)

Best-practice recommendations:

• Prefer custom read ACLs on required CI classes only

• Or create a custom role (instead of full cmdb_read) and assign it to relevant users/groups

• Always use reference qualifiers to limit visible CIs (e.g., operational, owned by user, etc.)

Conclusion:

• cmdb_read is technically correct

• For production, least-privilege access via ACLs + qualifiers is recommended

If you find this as helpful, please mark it as helpful and please accept my solution...

Best Regards

SIVASANKARI S

[Its_Sagnic · Accepted solution]

Hi @Kishore47 ,

Hope you are doing well.

Is Assigning cmdb_read the Best Practice?

Yes. Assigning the cmdb_read role is the official and recommended approach for granting end-users (requesters) read-only access to CMDB data for service catalog purposes. 

• Licensing: Crucially, cmdb_read is a requester role, meaning it typically does not consume a paid ITIL or fulfiller license.
• Security: This role provides minimum necessary access to read configuration items (CIs) without granting permission to modify them or access sensitive IT-only modules. 

Why sys_user Works but CMDB Tables Do Not :

• sys_user (Public/Requester Read): This table has Out-of-Box (OOB) ACLs that allow any authenticated user to read basic user details to facilitate global searches and reference fields.
• cmdb_ci Tables (Protected): By default, CMDB tables are restricted to roles like itil or asset. In newer versions , ServiceNow has tightened security, requiring specific roles or advanced ACLs for AJAX-based reference lookups in the Service Portal. 
  
  
  Recommended Implementation Steps:
  
  
  In a production environment, follow these steps to manage access correctly:
  1. Group-Based Assignment: Never assign the role directly to a user. Create a specific group (e.g., "CMDB Requesters") and assign the cmdb_read role to that group.
  2. Use Lookup Select Box (Performance Alternative): If you have thousands of CIs, a Lookup Select Box is often better than a Reference Variable. It uses simpler queries that sometimes bypass the stricter AJAX security requirements of reference fields and performs better with large datasets.
  3. Advanced ACLs (Optional/Complex): If your security policy strictly forbids the cmdb_read role, you must create a custom Read ACL at the table level (e.g., cmdb_ci.none) specifically for your catalog requesters. However, this is less desirable than using the OOB role because it increases maintenance overhead.
  4. Reference Qualifiers: Always apply a Reference Qualifier to your variable to ensure users only see the specific CIs relevant to that request (e.g., only "Active" computers), rather than the entire CMDB. 
  
  

If this solution is helpful for you please mark it as helpful and accept the solution to clode the thread.

Regards,

Sagnic

[Kishore47]

Hi, if possible, could you please write down the ACL steps for this requirement?

[Kishore47]

I realized that adding normal users to that group would be difficult, especially if there are thousands of users with no roles.

Could you please suggest an ACL-based approach with steps, if possible?

Thanks in advance.