Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

How Can i Limit a user with Admin role to read a table extend task table ?

Bruno Moreira1
Tera Contributor

Hello. I created an extended table from the task table for a specific function in my company.

I created a specific role and ACLs for the table without admin override to ensure that only those who have this role can read, write, modify, and delete records.

Even so, users with the Admin role are still able to read my table.

Could someone help me with guidance? Since this is a table that will store sensitive data, it is a requirement to limit reading even for ServiceNow administrators.

 

BrunoMoreira1_0-1763133568410.png

 

thank you Evebody to help me

1 ACCEPTED SOLUTION

Renat Akhmedov
Kilo Sage

Hi @Bruno Moreira1,

In ServiceNow, "admin" tolr always has access unless you explicitly change the admin override behavior.

To restrict an "admi" from reading a table that extends the task, you must:

1. Disable "Security Admin" override on ACLs (which you already did);

2. AND disable “Admin overrides” for the table itself in the dictionary record;

3. AND ensure an access-restriction role is required;

4. AND control access at the parent-level ACLs (task) if needed;

 

If you miss any one of these parts, the "admin" role user holder will still read your table.

Also, If my answer was helpful, please don’t hesitate to give it a thumbs-up - it only takes a second, but it means a lot to me. Thank you!

 

Best regards,
Renat Akhmedov

View solution in original post

4 REPLIES 4

Renat Akhmedov
Kilo Sage

Hi @Bruno Moreira1,

In ServiceNow, "admin" tolr always has access unless you explicitly change the admin override behavior.

To restrict an "admi" from reading a table that extends the task, you must:

1. Disable "Security Admin" override on ACLs (which you already did);

2. AND disable “Admin overrides” for the table itself in the dictionary record;

3. AND ensure an access-restriction role is required;

4. AND control access at the parent-level ACLs (task) if needed;

 

If you miss any one of these parts, the "admin" role user holder will still read your table.

Also, If my answer was helpful, please don’t hesitate to give it a thumbs-up - it only takes a second, but it means a lot to me. Thank you!

 

Best regards,
Renat Akhmedov

Dr Atul G- LNG
Tera Patron
Tera Patron

Hi @Bruno Moreira1 

“OOTB, the admin has kind of super privileges. If you want to restrict that, you would need to update the ACL so the admin can’t override it. But I would suggest not doing this—keep the access with the admin.”

*************************************************************************************************************
If my response proves useful, please indicate its helpfulness by selecting " Accept as Solution" and " Helpful." This action benefits both the community and me.

Regards
Dr. Atul G. - Learn N Grow Together
ServiceNow Techno - Functional Trainer
LinkedIn: https://www.linkedin.com/in/dratulgrover
YouTube: https://www.youtube.com/@LearnNGrowTogetherwithAtulG
Topmate: https://topmate.io/atul_grover_lng [ Connect for 1-1 Session]

****************************************************************************************************************

MaxMixali
Kilo Sage

Base on my experience try to do this one:

 

  1. Navigate to System Security > Access Control (ACL)
  2. Create a new ACL for your table (e.g., u_your_table)
  3. Set Operation: read (create separate ACLs for write, delete, create)
  4. Set Type: record
  5. In the Script field, add:
 
 
javascript
answer = gs.hasRole('your_specific_role') && !gs.hasRole('admin');

Or use the Roles field:

  • Roles required: Add your specific role
  • Advanced: Check the box for "Advanced" and add a script:
 
 
javascript
// Explicitly deny admin, allow only your specific role
if (gs.hasRole('admin')) {
    answer = false;
} else if (gs.hasRole('your_specific_role')) {
    answer = true;
} else {
    answer = false;
}

MikeWoolsey
Tera Contributor

So, I'm reading over the answer, and of course the answer is accurate and practical.

 

But ... do you truly want to prevent your Admin(s) from supporting users who are having trouble with your feature?

 

See, when you prevent an admin from viewing what's going on, they're also prevented from helping users who are troubled by what's going on and have called in for help.

 

I'm sure there are ways around this, but they're just kind of insecure and also raise red flags: such as, allowing an admin the ability to impersonate anybody.

 

As long as your company is happy with either 1- granting production admins the ability to look into this data by impersonation, or 2- admins telling end users they can't help them, I guess it's not a problem for you. Still, I'd find it a constant annoyance, especially if you end up blocking admin access to even more data ... which they're supposed to be administering.

 

And y'can't (or shouldn't) hold admins responsible for things they can't see. Because they can't see or warn what could happen.