ACL on Table not working
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2022 10:23 AM
I believe that I have added the ACL correctly on a table
They asked for Read/Write/Delete on a certain table
I did the following:
1. Created a Role
2. Added the User to the Role
3. When to System Security and added the ACL (after elevating Role)
4. Filled out the form
Everything seems to be in place, but the user is trying to access through the API and said they are not able to access the tables. Am I missing something here?
- Labels:
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2022 12:23 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2022 12:34 PM
Hello Tony, I have verified that the Allow Access to this table via web services is checked.
Is there anything else I might be missing?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2022 12:50 PM
Hi, you mention API, Which API are you trying to use?
Do you get a response\error code if you test via Postman or similar?
Is your user able to authenticate\obtain a token?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-12-2022 12:41 PM
Hi,
ACLs can be tricky.
1) For maintenance purposes, a role should be assigned to groups and not to users. Is it possible? Yes, it is.
The fact is that the ServiceNow recomendation is to always assighn roles to groups.
You can create a User Group (ie: "My Group 1") and then assign your "sn_ti.table_rwd" role to it.
2) Role names
If you're creating a role, don't start the name with "sn_".
The reason is that the core roles (used internally by the plataform) starts with "sn_" so it is not recommended to do that.
3) Operations
After Elevating Roles you can assign to you the secure_admin role. The session will last for a short period of time or until you log off.
When your session has this privilege, you'll see a padlock on the right of your user name. This allows you to perform special actions and one of that is to create ACLs.
If you want to allow the users from a Group to create, read, write and delete records on the table "sn_ti_lookup_result" then you should create four operations for that table:
3.1) Name: Threat Lookup Results, * (means all fields)
Type: record
Operation: create
Requires role: your_role_1
3.2) Name: Threat Lookup Results, * (means all fields)
Type: record
Operation: read
Requires role: your_role_1
3.3) Name: Threat Lookup Results, * (means all fields)
Type: record
Operation: write
Requires role: your_role_1
3.4) Name: Threat Lookup Results, * (means all fields)
Type: record
Operation: delete
Requires role: your_role_1
4) Always assign Users to Groups
Since you've assigned "your_role_1" to your group "My Group 1" in step 1, now you can assign users to "My Group 1" and they're going to inherit the for operations you've specified for your table on step 3.
In the moment you put a user into "My Group 1", he/she will be able to perform operations within the Threat Lookup Results table.
5) Final tips
- Take a look and confirm if there's only one record for each operation for that table (ie: a unique record with the operation 'read') and make sure it is active.
- Talking about other tables (ie: sn_ti_observable_enrichment_result).
Let's suppose you create four ACLs for this table and assign a role called "your_role_2"
If you want your users from "My Group 1" to have access to this table, the only thing to do is to assign the role "your_role_2" to the Group "My Group 1".
Incredible isn't it? Now you can see the power of that recommendation (step 1).
Please mark my response as Correct or Helpful, if you find it appropriate.
________________________
Carlos Camacho
https://www.linkedin.com/in/camachojunior