Skip to main content

ServiceNow Evidence Sources and Enterprise Automation Landscape

Date: 2026-02-07 Purpose: Deep research to answer (1) authoritative ServiceNow evidence sources for execution and role change events, (2) deterministic linkage between Entra service principals and ServiceNow integration identities, and (3) top autonomous execution types in modern enterprises.

1) Authoritative ServiceNow Logs And Tables For Execution Evidence​

This section prioritizes evidence-grade sources that can prove autonomous execution without inference. The list is ordered by best-available authority and practical reliability.

1.1 Transaction Log (Inbound REST + UI)​

Table: syslog_transaction

Why it is authoritative: The Transaction Log records transactions and includes the user and URL, which is direct evidence that the integration identity executed a request.

Best use: Proof of inbound REST API execution by OAuth-integrated identities.

Evidence fields to rely on: user, URL, response time, session, created timestamp. It does not store request/response body by default.

Notes:

  • Transaction Log entries are system tables and may require permissions or explicit allowlisting for reporting/API access.
  • You will typically filter on user (integration user) and url (e.g., /api/now/*) to show autonomous activity windows.

1.2 Outbound HTTP Logs (Outbound REST from ServiceNow)​

Table: sys_outbound_http_log (requires HTTP logging configuration)

Why it is authoritative: If enabled, it can record outbound REST message execution from ServiceNow, including response bodies, and acts as proof of autonomous execution from ServiceNow to third-party systems.

Best use: Evidence that a ServiceNow automation executed outbound API calls.

Notes:

  • This is optional and may not be enabled by default.

1.3 Flow Designer Execution Context​

Table: sys_flow_context (execution context records)

Why it is authoritative: Flow execution context records are the canonical instance-level evidence that a flow ran. This provides proof of execution independent of the triggering event.

Best use: Evidence that a flow actually executed (not just configured).

Notes:

  • The detailed step/action records are not clearly documented; you should verify the step-level execution tables in your instance.

1.4 Scheduled Jobs And Scheduled Script Execution​

Tables: sys_trigger, sysauto_script

Why it is authoritative: Scheduled job metadata and execution scheduling are stored here and serve as configuration evidence for autonomous execution schedules.

Best use: Evidence of continuously running scheduled automations, combined with execution evidence from logs.

Notes:

  • Scheduled jobs are stored in sys_trigger and often reference sysauto_script for script jobs.

1.5 MID Server Execution Evidence​

Table: ecc_queue

Why it is authoritative: The ECC queue is the source of truth for tasks queued to MID Servers and is the coordination layer for asynchronous execution.

Best use: Evidence of MID Server-based autonomous execution (discovery, orchestration, integrations).

2) Authoritative ServiceNow Logs And Tables For Role Change Events​

2.1 Role Assignment Audit (Best-Available Authority)​

Table: sys_audit_role

Why it is authoritative: Records role assignment/removal actions with who changed the role, which role, and which user.

Critical requirement: The system property glide.role_management.v2.audit_roles must be enabled; otherwise the table is empty.

Best use: Deterministic evidence for scope drift in ServiceNow role assignments.

2.2 Role Membership State (Current Snapshot)​

Table: sys_user_has_role

Why it matters: This is the authoritative mapping of users to roles (current state). It can be used as a baseline for detecting drift when combined with timestamps and/or audit history.

Best use: Compute current standing access and compare against previous baselines.

Notes:

  • If sys_audit_role is not enabled, sys_user_has_role + timestamps provides weaker evidence but can still show additions over time.

3) Deterministic Link: Entra Service Principal → ServiceNow Integration Identity​

This section proposes a deterministic linkage strategy that avoids inference and is defensible in an evidence pack.

3.1 Linking by OAuth Client Record​

Primary linkage key: Entra Service Principal appId (client_id) <-> ServiceNow OAuth Application Registry record in oauth_entity (client_id).

Why this is deterministic: The same client_id must be presented by the external OAuth client when requesting tokens; ServiceNow stores that client_id in the OAuth application registry record.

Key tables and fields to verify:

  • oauth_entity.client_id (or equivalent client_id field)
  • oauth_entity.user (the ServiceNow user identity used for inbound requests, if configured)

3.2 Mapping OAuth Tokens to a ServiceNow User​

JWT-based OAuth endpoints: ServiceNow’s OAuth JWT endpoint configuration includes a User Field that maps the JWT subject (sub) claim to a field in the sys_user table (for example, Email). This deterministically binds tokens to a ServiceNow user record.

Non-JWT OAuth endpoints: Community guidance suggests a ServiceNow user is still created and used by the OAuth application record (often a dedicated integration user). That user then drives role grants and access evaluation.

3.3 Identity-to-Role Graph​

Once the ServiceNow integration user is identified:

  • Roles are obtained from sys_user_has_role.
  • Role definitions come from sys_user_role.
  • Role changes over time are proven by sys_audit_role (if enabled).

3.4 Execution Proof​

Use syslog_transaction to show that the integration user actually executed API calls in a given time window. This prevents “configured but unused” false positives.

4) Top 10 Common Autonomous Execution Types In Modern Enterprises​

This list is meant to maximize coverage of autonomous execution surfaces that can experience ownership decay and scope drift. For each type, capture evidence from the system of record and map execution identities to owners.

  1. Scheduled batch jobs (cron-style). Evidence: Kubernetes CronJobs or platform schedulers store repeat schedules and create periodic jobs.

  2. ITSM/ITOM workflow automation (no-code flows). Evidence: ServiceNow Flow Designer provides flow-based automation with triggers and actions, often without code.

  3. CI/CD scheduled pipelines. Evidence: GitHub Actions supports scheduled workflows via cron expressions.

  4. Serverless scheduled jobs. Evidence: EventBridge can run Lambda functions on a schedule.

  5. Data integration / ETL pipelines. Evidence: Azure Data Factory schedule triggers run pipelines on defined recurrences.

  6. Infrastructure automation (IaC auto-runs). Evidence: Terraform Cloud run triggers automatically queue runs based on upstream applies.

  7. Runbook automation (IT ops). Evidence: Azure Automation schedules runbooks to run once or on a recurring schedule.

  8. RPA bots (robotic process automation). Evidence: UiPath Orchestrator supports cron-based job triggers.

  9. Identity provisioning and sync. Evidence: SCIM defines an HTTP protocol for provisioning and managing identity data across domains.

  10. Backup and recovery automation. Evidence: AWS Backup scheduled plan executions record scheduled backup times and rules.

5) Practical Coverage Guidance For SecurityV0​

  • Start with execution evidence sources that are deterministic and reliably populated (syslog_transaction, sys_audit_role, sys_user_has_role).
  • Do not claim role-change drift without sys_audit_role or another authoritative audit trail.
  • Build a fallback strategy when audit logging is not enabled: mark findings as “incomplete history” rather than inferring approval or drift.
  • Use oauth_entity + sys_user + sys_user_has_role as the minimum deterministic chain for Entra→ServiceNow linking.
  • Extend coverage with Flow Designer (sys_flow_context) and scheduled jobs (sys_trigger) to prove execution in the absence of API calls.

Sources Consulted (titles only)​

  • ServiceNow: Flow Designer product overview
  • ServiceNow: OAuth JWT API endpoint configuration (Application Registry)
  • ServiceNow: ECC Queue (MID Server)
  • ServiceNow Community: Role auditing with sys_audit_role and required system property
  • ServiceNow Community: Transaction Log usage for REST API monitoring
  • ServiceNow Community: Scheduled jobs stored in sys_trigger and sysauto_script
  • Insightsoftware: oauth_entity and sys_user_has_role table schema references
  • GitHub Actions: workflow schedule events
  • Kubernetes: CronJob
  • AWS: EventBridge scheduled rules and AWS Backup scheduled plan execution
  • Azure: Automation schedules and Data Factory schedule triggers
  • UiPath: Orchestrator cron-based job triggers
  • IETF: SCIM protocol (RFC 7644)
  • HashiCorp: Terraform Cloud run triggers

Next Action​

Status: adopted — shipped Evidence sources adopted: Business Rules, Script Includes, Flow Designer flows, Scheduled Jobs, REST Messages, OAuth Entities. Connector implemented in sv0-connectors (entra-servicenow). Execution chain model documented in 01-data-model.md. No further action required.