Task table read ACL for Inbound integration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
58m ago
I am trying to make a successful security tool integration using OAuth profile -> Auth Scope (useraccount) -> Service account on instance and the security tool.
My goal is to provide read access to Task, Label, User, Groups table.
Roles attached to example service acoount user (rest_service, web_service_admin, custom role for user table, custom role for group table, snc_internal) but when i try to create a custom role svc_task_read and ACL as task.none on Task table and attach newly created role to ACL and User, the other users are getting impacted with query_match errors.
We have only OOB ACLs on Task table for read/record "allow if"
My goal is not to overprovision.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
54m ago
Hi @RamAdapa ,
I would not add a broad read ACL on Task [task] for this integration unless the security tool genuinely needs access to every Task-derived table.
Task is a parent table. A read ACL created on Task can apply to tables extending Task, such as Incident, Problem, Change Request and many other application task tables. That makes task-level access much broader than it initially appears.
Also, query_match is a separate ACL operation from read. Adding a broad Task read ACL is not the correct way to resolve query_match failures.
Recommended architecture:
OAuth
-> Dedicated API authentication scope
-> Dedicated service account
-> Dedicated integration role
-> Restricted REST endpoint/API
-> Exact table ACLs
-> Exact fields/records required
1. Do not use useraccount if least privilege is the goal
The useraccount OAuth scope is special. It can allow the OAuth entity to access APIs beyond individually configured REST API Auth Scopes.
If your requirement is strict least privilege, create a dedicated REST API Auth Scope for this integration and associate only the required API.
Also consider a REST API Access Policy restricted to:
Authentication: OAuth
HTTP method: GET
Required API/table
Trusted source/IP conditions if applicable
The API access policy restricts which API can be called. It does not replace table/field ACL security.
2. Remove web_service_admin from the runtime service account
web_service_admin is intended for users who create and administer Scripted REST APIs.
It is not required simply to call a Scripted REST API endpoint.
The service account should contain only runtime roles required by the integration.
3. Create one dedicated role
For example:
x_company.security_tool_reader
Prefer assigning it through an integration-specific group:
Security Tool Integration
-> x_company.security_tool_reader
-> Service account
This makes ownership and access reviews easier.
4. Do not modify the OOB Task ACLs
Create new Allow-If ACLs instead of adding your integration role to existing OOB ACLs.
Multiple Allow-If ACLs at the same evaluation point are additive. Passing one can grant access.
For example, if the tool needs Incidents and Changes:
Table:
Incident [incident]
Operation:
read
Decision type:
Allow If
Requires role:
x_company.security_tool_reader
Table:
Change Request [change_request]
Operation:
read
Decision type:
Allow If
Requires role:
x_company.security_tool_reader
Then create equivalent read ACLs only for the additional tables genuinely required:
User [sys_user]
Group [sys_user_group]
<actual Label table>
Do not create:
task.read
unless the security tool genuinely requires all Task classes.
5. Do not create write access
For a read-only security integration, the service account should not receive:
create
write
delete
access.
Only grant read access.
Field-level ACLs should continue to protect sensitive fields.
6. Prefer a Scripted REST API if only limited data is required
If the security tool needs only specific information, for example:
Task:
sys_id
number
state
assigned_to
assignment_group
sys_updated_on
User:
sys_id
user_name
active
Group:
sys_id
name
active
then exposing the complete Table API is broader than necessary.
A stronger architecture is:
Security Tool
-> OAuth
-> Custom Scripted REST API
-> GET-only resources
-> Fixed tables
-> Fixed filters
-> Fixed response fields
For example:
/api/x_company/security/tasks
/api/x_company/security/users
/api/x_company/security/groups
Protect the Scripted REST API with a REST Endpoint ACL requiring:
x_company.security_tool_reader
Do not accept an arbitrary table name or unrestricted encoded query from the caller.
This significantly reduces the API attack surface.
7. Investigate the query_match error separately
query_match controls whether a user can execute match queries such as:
is
is not
is empty
against protected data.
Do not create a broad query_match ACL just because the REST request returns that error.
Use:
Access Analyzer
-> Analyze Permissions
Select:
User:
Integration service account
Table:
Affected table
Field:
Field being used in sysparm_query
Then inspect:
read
query_match
Also compare the result with a normal user who started receiving the error.
If other users started failing only after your ACL change, verify immediately that:
- No OOB ACL was modified.
- Your new ACL is Decision Type = Allow If.
- You did not create a Deny-Unless ACL.
- You did not create/modify a query_match ACL.
- No ACL was created on Task with an unintended Applies-to condition.
- No Data Filter was added.
A separate Allow-If ACL with your custom role should not remove access previously granted to existing users at the same ACL evaluation point.
8. Important Task-table consideration
If the security tool calls:
/api/now/table/task
you are effectively exposing a very large inheritance hierarchy.
That can include records from applications that the security tool may not need.
For least privilege, I would prefer:
/api/now/table/incident
/api/now/table/change_request
/api/now/table/problem
or preferably your controlled Scripted REST endpoints.
Avoid querying the base Task table unless the business requirement explicitly requires all task classes.
Recommended final design:
Dedicated service account
-> Dedicated integration group
-> x_company.security_tool_reader
-> Dedicated OAuth Auth Scope
-> REST API Access Policy
-> GET only
-> Scripted REST API
-> Explicit tables
-> Explicit fields
-> Existing ACL/security enforcement
This avoids overprovisioning and prevents changes to Task security from affecting normal platform users.
One more important point:
If you create a separate Allow-If Task read ACL and normal users are impacted, I would not continue adding ACLs until you run Access Analyzer. A new Allow-If ACL itself should be additive, so the query_match failures suggest that another ACL type, parent/field ACL, Data Filter, or modified OOB rule is involved.
Official references:
ACL evaluation:
https://www.servicenow.com/docs/r/platform-security/access-control/exploring-access-control-list.htm...
ACL types and Task inheritance:
https://www.servicenow.com/docs/r/platform-security/access-control/acl-rule-types.html
REST API Auth Scope:
https://www.servicenow.com/docs/r/platform-security/authentication/rest-api-auth-scope.html
REST API Access Policies:
https://www.servicenow.com/docs/r/platform-security/authentication/create-api-access-policy.html
Table API:
https://www.servicenow.com/docs/r/api-reference/rest-apis/c_TableAPI.html
Scripted REST API security:
https://www.servicenow.com/docs/r/api-reference/rest-api-explorer/t_WbSvcRqACL.html
Access Analyzer:
https://www.servicenow.com/docs/r/platform-security/access-control/using-evaluate-access.html
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.
Kind Regards,
Abhishek Pal
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
24m ago
We did try API access policies at first, but the same Task table read access failures occurred, eventually when i tried to configure with service account login on the security tool which is synced from AD on both sides Instance & sec tool with admin role attached to service account user on instance it worked.
The sec tool definitely needs whole task table access, we don't have control over how that was coded on sec tool, we just need to use guided wizard for the integration.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
25m ago
Hi @RamAdapa ,
What you're seeing is a common side effect of adding a new ACL on the Task table.
Why other users are getting query_match errors
The Task table already has OOB read access controlled by a combination of:
- Record ACLs
- Before Query Business Rules
- User Criteria / domain constraints (depending on implementation)
- The OOB Task.None read model ("Allow if" ACL)
Recommended approach
Instead of creating a custom Task read ACL, create a dedicated integration strategy.
