- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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.
thank you Evebody to help me
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
“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]
****************************************************************************************************************
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Base on my experience try to do this one:
- Navigate to System Security > Access Control (ACL)
- Create a new ACL for your table (e.g., u_your_table)
- Set Operation: read (create separate ACLs for write, delete, create)
- Set Type: record
- In the Script field, add:
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:
// 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; }
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
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.
