How to create custom sn_customerservice_agent rol without CMDB access

[Tona26]

Hi!

Our agents are using sn_customerservice_agent role so they can create interaction, request and incidents as a 3rd person but, we need to limit their access so they can't access to the CMDB tables.

I tried to "duplicate" the sn_customerservice_agent, meaning that I created a custom role and added all the contain roles, Applications with role and Modules with Role as the sn_customerservice_agent.

The sn_customerserive_agent role contains the sn_esm_agent role, this sn_esm_agent role contains the cmdb_read role so, at the "duplicated" role I didn't add the sn_esm_agent role, instead of that I added all the sn_esm_agent contains roles (excpeting the cmdb_read), Applications with role and Modules with Role.

The "duplicated" role is exactly as the original role but, when I tried to do some tests at the CSM Workspace I cannot create any Interaction, it stays at a blank page.

Why is that happening? Is there another way to grant access to the agents as the sn_customerserive_agent without acces to the CMDB tables? I also tought about creating ACL's but, cmdb has a grat bounch of tables.

[danmjunqueira]

Hey @Tona26 how are you?

I believe You're on the right track with creating a custom role to replace sn_customerservice_agent without granting CMDB access, but the issue you're facing — blank Interaction screen in CSM Workspace, likely stems from the fact that some critical permissions or implicit dependencies are not being fully replicated when you manually deconstruct sn_customerservice_agent.

Here’s why and my suggestion how to fix it:

Why You See a Blank Page
sn_esm_agent includes more than just cmdb_read

sn_esm_agent is not just a container; it grants access to essential Workspace data models, UI elements, and actions.

By excluding sn_esm_agent, you are inadvertently removing required access to workspace components like:

interaction creation UIs

workspace-specific form/view scripts

required ACLs and modules

CSM Workspace relies on expected role chains

The blank Interaction screen suggests the agent is missing a view script, UI action, or model permission required to load the interaction form.

These are typically inherited from sn_esm_agent, sn_interaction or sn_customerservice_agent.

Duplicating role relationships ≠ duplicating behavior

Even if you've replicated the contains roles and module assignments, some functionality relies on role names (e.g., scripts checking for sn_esm_agent directly).

So removing sn_esm_agent breaks parts of the experience, even if other roles are technically present.

Recommended Solutions

Option 1: Use ACLs to Block CMDB Access (Recommended)
Instead of removing sn_esm_agent, keep the original roles but explicitly deny access to CMDB via ACLs.

Steps:

Navigate to System Security > Access Control (ACL)

Filter for: Table name STARTSWITH cmdb_ci

Create a read ACL like:

Table: cmdb_ci (and repeat for other core CMDB tables if needed)

Operation: read

Condition: !gs.hasRole('u_sn_customerservice_agent_NoCMDB')

Script: answer = false; (or build logic per your org’s policy)

Make sure this ACL takes priority over inherited cmdb_read.

This gives agents full use of the Workspace without access to CI data.

Option 2: Keep sn_customerservice_agent and Use CMDB ACL Denial Rules
You can use ACL deny logic to hide or restrict CI views even if the agent has cmdb_read, by adding:

Glide scripts like gs.hasRole('sn_customerservice_agent') && current.sys_class_name == 'cmdb_ci_server' && denyAccess();

Use GlideRecord filters in client scripts or UI Policies to suppress unwanted fields or references.

Option 3: Clone the Entire Role Stack via Plugin or Update Set (Riskier)
You can try to export the full sn_customerservice_agent role, recreate all its relationships, then surgically remove cmdb_read—but this is fragile, labor-intensive, and risks breaking future upgrades.

Not recommended unless you're building a full custom app layer.

Let me know if works, 

[Tona26]

I tried to create an ACL but didn't work

Type: record
Operation: read
Decision Type: Allow if
Name: cmdb_retirement_custom_definitions
Requieres role: u_ITIL_NoCMDB (I changed the custom name role)
Script condition: answer=false;

What am I missing?