Required Permissions
Access model
Compyl's ServiceNow integration is read-only. Every call is a GET against the ServiceNow Table API (/api/now/table/{table}). No table requires write, update, or delete access, Compyl never creates or modifies records in ServiceNow, and no security_admin elevation is required.
Permissions are evaluated against the OAuth Application User - the service account selected in the OAuth Application Registry (native path), or the ServiceNow user matched by the token claim (Entra federated path). That user needs read access to each source table listed below.
ServiceNow grants table access through role-based ACLs, and ACLs are commonly customized per instance, so the specific role that satisfies a given table differs from instance to instance. Rather than prescribe role names that may not match your configuration, have your ServiceNow administrator either (a) confirm an existing role covers the tables below, or (b) create a dedicated read-only integration role with read ACLs on those tables and assign it to the integration user.
Read access by functional area
Each area below corresponds to a group of Compyl endpoints. Endpoints are individually toggleable on the integration configuration - a table is only called if its endpoint is enabled, so you only need to grant access for the areas you intend to sync.
| Area | ServiceNow source tables | Notes |
|---|---|---|
| Identity & access | sys_user, sys_user_group, sys_user_grmember, sys_user_role, sys_user_has_role, sys_group_has_role | Underpins ownership attribution and access-review evidence. Role and role-assignment tables are the most commonly restricted of this group. |
| People & contacts | csm_consumer, customer_contact | Only required if CSM consumer / contact sync is enabled. |
| Tickets & changes | incident, change_request, change_task, std_change_proposal, task_ci, task_cmdb_ci_service | Change-management and incident evidence. Typically covered by the same role that grants ITSM read access. |
| CMDB - core | cmdb_ci, cmdb_ci_server, cmdb_ci_service | Asset and service inventory. |
| CMDB - application lineage | cmdb_ci_business_app, cmdb_ci_service_auto, cmdb_rel_ci | Business-application inventory and Application → Service Instance → Server traversal. cmdb_rel_ci is required for the traversal; without it the application and service records sync but cannot be linked. |
| Service catalog | sc_request, sc_req_item | Catalog request and fulfillment evidence (REQ / RITM records). |
| Audit trail | sys_audit, sys_audit_relation | Field-level change history. Read access to the audit tables is restricted to administrators in a default instance and usually needs an explicitly granted read ACL. Expect this area to require the most ServiceNow-side work. |
Field-level access for custom and scoped columns
The Business Application and Application Service syncs capture every column the Table API returns for each record, including customer-defined and scoped-application columns (for example x_psm_* columns from a scoped compliance application). Compyl does not request a fixed column list, so a custom column lands in Compyl automatically -- but only if the integration user is permitted to read it.
If standard columns populate but custom columns come back empty:
- Scoped application access. Columns owned by a scoped application require that application to permit cross-scope read access. If it does not, ServiceNow omits the column from the API response entirely rather than returning an error.
- Field-level (column) ACLs. A column can carry its own read ACL that is evaluated independently of the table-level ACL. Granting table read does not automatically grant read on every column of that table.
Verifying access
Every source table is registered as an endpoint in Compyl and probed with a single-row request (?sysparm_limit=1) when the configuration is saved. Any table the integration user cannot read fails its probe and is reported on the configuration screen, so permission gaps surface immediately instead of after a full sync.
Updated 22 days ago