# ServiceNow

## Overview

The Veza integration for ServiceNow enables the discovery of Users, Groups, Access Control List (ACL) Rules, and Roles from ServiceNow SaaS deployments, for release `Tokyo` and newer. You can create queries that target these ServiceNow entities and attributes to:

* Audit users with admin permissions in the ServiceNow instance.
* Explore User>Group and User>ACL Rule relationships.
* Create Rules, Queries, and Reports to understand and regulate ServiceNow user roles.

The integration also supports:

* [Activity Monitoring](#activity-monitoring) for tracking ServiceNow User access to ServiceNow Tables.
* [Custom Properties](#custom-properties) for extracting additional user attributes from ServiceNow.
* [User Type Filtering](#user-type-filtering) to limit discovery to specific user types.
* [Lifecycle Management](#lifecycle-management) Custom Actions for inserting records into ServiceNow tables.
* [AI Agent Discovery](#ai-agent-discovery) for AI Agents, Tools, Skills, and Models configured in ServiceNow.

See [ServiceNow Entities and Attributes](#servicenow-entities-and-attributes) for more information.

To establish an outbound connection for ticket creation, see [ServiceNow Notifications](/4yItIzMvkpAvMVFAamTf/administration/administration/notifications/destinations/servicenow.md).

***

## Prerequisites

Before configuring the integration, ensure you have:

* ServiceNow release `Tokyo` or newer
* Network connectivity between your Veza tenant (or [Insight Point](/4yItIzMvkpAvMVFAamTf/integrations/connectivity/insight-point.md)) and ServiceNow instance
* A ServiceNow user account with appropriate roles:
  * **Basic Auth**: `admin` role (grants broad access), or for reduced permissions: `itil`, `access_analyzer_admin`, and `oauth_admin` plus custom ACL grants for audit tables (see [Permissions approach](#permissions-approach))
  * **OAuth 2.0**: `itil`, `access_analyzer_admin`, and `oauth_admin` roles, plus custom ACL grants for the three audit tables. ServiceNow blocks OAuth users with the `admin` role (see [Permissions approach](#permissions-approach))

{% hint style="warning" %}
`snc_read_only` alone is insufficient. It grants access to only a subset of the tables required for a complete extraction. Most IAM tables will fail with errors if only `snc_read_only` is assigned.
{% endhint %}

* Administrator access to create users and assign roles in ServiceNow
* *(OAuth 2.0 only)* An OAuth application registered in ServiceNow with JWT Bearer grant type configured (see [OAuth 2.0 setup](#oauth-20-setup) below)
* *(AI Agent Discovery only)* The AI Agent Studio (`sn_aia`) plugin and, where applicable, Now Assist Skill Kit and the Generative AI Controller. If the `sn_aia` plugin is not installed, AI Agent extraction is skipped and the rest of the integration continues normally. See [AI Agent Discovery](#ai-agent-discovery).
* *(Machine Identity Console only)* ServiceNow release `Zurich` or newer with the Machine Identity Console feature active. When available, Veza reads the `sys_mi_user_tracker` table to provide timestamps for last API access in `last_login_at` attributes.

***

## ServiceNow setup

### Create a service account

Before adding the integration to Veza, create an API-only user (service account) in ServiceNow:

1. Browse to `https://<your_instance>.service-now.com` and log in with an account with the `user_admin` role.
2. Click the "System Security" module in the left navigation menu.
3. Pick "Users" from the dropdown menu.
4. Click *New* to create a user.
5. Enter the required details for the Veza user, including the name, username, and password.
6. Enable *Web service access only* to allow API calls and prevent UI access.
7. In the *Roles* section, assign the appropriate roles:
   * **Basic Auth**: Assign `itil`, `access_analyzer_admin`, and `oauth_admin`. Alternatively, assign `admin` if using Basic Auth and least privilege is not required.
   * **OAuth 2.0**: Assign `itil`, `access_analyzer_admin`, and `oauth_admin`. Do **not** assign `admin` — ServiceNow blocks OAuth authentication for users with the `admin` role.
8. Click *Save* to create the user.

For **Basic Auth**, note the username and password to use when configuring the integration in Veza.

For **OAuth 2.0**, note the username (this will be the **OAuth User Identifier** in Veza). Continue with the OAuth 2.0 setup steps below. You can omit the password if you will only use OAuth 2.0 authentication.

For more information, see [Create A User (ServiceNow)](https://docs.servicenow.com/bundle/sandiego-platform-administration/page/administer/users-and-groups/task/t_CreateAUser.html).

### OAuth 2.0 setup

To use OAuth 2.0 authentication, you must register an OAuth application in ServiceNow and configure it for the JWT Bearer grant type. This is a certificate-based authentication flow where Veza signs a JWT with a private key, which ServiceNow validates using the corresponding public certificate.

#### 1. Generate a certificate and private key

{% tabs %}
{% tab title="Generate with Veza" %}

1. In the Veza integration form, select **OAuth 2.0** as the Credential Type.
2. Optionally enter a password in the **Private Key Password** field to encrypt the private key.
3. Click **Generate & Download Certificate and Key**. Veza generates and downloads two files: a `.crt` certificate and a `.key` private key.
4. Save the `.crt` file — you will upload it to ServiceNow when registering the OAuth application (see step 2 below).
5. Upload the `.key` file when configuring the integration in Veza.

{% hint style="info" %}
If you set a password, provide it as the **Private Key Password** when configuring the integration in Veza.
{% endhint %}
{% endtab %}

{% tab title="OpenSSL (Manual)" %}
Generate a self-signed X.509 certificate and RSA private key. Example using OpenSSL:

```bash
# Generate an unencrypted private key and self-signed certificate (valid for 1 year)
openssl req -x509 -newkey rsa:2048 -nodes -keyout private_key.pem -out certificate.pem -days 365
```

To encrypt the private key with a passphrase (optional):

```bash
# Generate an encrypted private key and self-signed certificate (valid for 1 year)
openssl req -x509 -newkey rsa:2048 -keyout private_key_encrypted.pem -out certificate.pem -days 365
```

{% hint style="info" %}
If you encrypt the private key, you will be prompted to set a passphrase. Provide this passphrase as the **Private Key Password** when configuring the integration in Veza.
{% endhint %}
{% endtab %}
{% endtabs %}

#### 2. Upload the public certificate to ServiceNow

1. In ServiceNow, navigate to **System Definition** > **Certificates** (the `sys_certificate` table).
2. Click **New** to create a certificate record.
3. Copy the contents of `certificate.pem` and paste it into the **PEM Certificate** field.
4. Save the record and note the certificate name for the next step.

Remember to renew the certificate before it expires and update both ServiceNow and the Veza integration configuration.

#### 3. Register an OAuth application in ServiceNow

1. In ServiceNow, navigate to **System OAuth** > **Application Registry**.
2. Click **New** and select **Create an OAuth JWT API endpoint for external clients**.
3. Set the **Name** and configure the **User Field** to the `sys_user` column that matches the value you will provide as the **OAuth User Identifier** in Veza. For example, select **User ID** if you will use the service account's username, or **Email** if you will use the email address.
4. Under **Auth Scope**, configure a scope that grants access to the **Table API**. By default, the OAuth application uses the `useraccount` scope, which grants broad access and is not recommended. To create a restricted scope:
   1. Click **Create auth scope**.
   2. Enter a name for the scope (for example, `veza_table_api`).
   3. In the **Limit authorization to the following APIs** field, add **Table API**.
   4. Click **Save** to create the scope.
   5. Back on the OAuth application, select the new scope from the **Auth scope** dropdown.
   6. *(Optional)* Under **Scope validation settings**, check **Allow access only to APIs in selected scope** to prevent the integration from accessing APIs outside the configured scope.
5. Click **Save**.
6. Open the newly created OAuth application and click the **+** button next to **JWT Verifier Maps**.
7. In the **Sys Certificate** field, select the certificate uploaded in step 2.
8. Note the **Client ID** and **Client Secret** for the Veza configuration.

For detailed ServiceNow configuration steps, see [Create an OAuth JWT API endpoint for external clients (Xanadu release)](https://www.servicenow.com/docs/bundle/xanadu-platform-security/page/administer/security/task/create-jwt-endpoint.html) in the ServiceNow documentation.

#### 4. Configure the integration in Veza

When creating the integration in Veza, select **OAuth 2.0** as the Credentials Type and provide:

* **OAuth Client ID**: The Client ID from the ServiceNow application registry
* **OAuth User Identifier**: The username or email of the service account created in [Create a service account](#create-a-service-account). This must match the **User Field** configured on the ServiceNow OAuth application.
* **OAuth Client Secret**: The Client Secret from the ServiceNow application registry
* **OAuth Private Key File**: Upload the PEM-encoded private key file (`private_key.pem`)
* **Private Key Password**: *(Optional)* The passphrase, if the private key is encrypted. Leave empty for unencrypted keys.

{% hint style="warning" %}
Keep the private key secure. Veza encrypts and stores the private key, but the original file should be protected or deleted after upload. Do not share the private key or commit it to version control.
{% endhint %}

### Permissions approach

The Veza integration requires read access to specific ServiceNow tables. Choose one of the following approaches based on your organization's requirements:

#### Option A: System roles (recommended)

Assign the following built-in roles to the service account. This is the simpler configuration and covers all required tables. Please note that these roles support other purposes and include permissions beyond read-only access to the tables Veza uses.

| Role                          | Tables covered                                                                                                                                                                                                                                                   |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `itil`                        | `sys_user_grmember`, `sys_user_role`, `sys_user_role_contains`, `sys_user_has_role`, `sys_group_has_role`                                                                                                                                                        |
| `access_analyzer_admin`       | `sys_security_acl`, `sys_security_operation`, `sys_security_acl_role`, `sys_db_object`                                                                                                                                                                           |
| `oauth_admin`                 | `oauth_entity_profile`, `oauth_requestor_profile`, `oauth_entity_scope`, `oauth_entity_profile_scope`                                                                                                                                                            |
| `sn_aia.viewer`               | `sn_aia_agent`, `sn_aia_agent_config`, `sn_aia_tool`, `sn_aia_agent_tool_m2m` (see [AI Agent Discovery](#ai-agent-discovery))                                                                                                                                    |
| `sn_conv_fa.conv_fa_designer` | `sys_gen_ai_skill`, `sys_gen_ai_skill_config`                                                                                                                                                                                                                    |
| `one_extend_viewer`           | `sys_generative_ai_model_config`, `sys_generative_ai_config`                                                                                                                                                                                                     |
| `mi_admin`                    | `sys_mi_user_tracker` (see [Machine Identity Console](#machine-identity-console)). Only needed on Zurich or later when the Machine Identity Console is in use. Not a subset of `admin` — assign explicitly if the service account does not already have `admin`. |

For Basic Auth, you can use the `admin` role as a shortcut in place of `itil`, `access_analyzer_admin`, and `oauth_admin`. `admin` does **not** cover the three AI Agent Discovery roles above (`sn_aia.viewer`, `sn_conv_fa.conv_fa_designer`, `one_extend_viewer`) — those must be assigned explicitly even when the account already has `admin`.

{% hint style="info" %}
The `sys_security_type` table is required to resolve ACL type names on AI entities (for example, records typed `gen_ai_agent` or `gen_ai_skill`), but no convenient built-in role grants read access to it. If AI Agent Discovery is in use, either assign the elevated `security_admin` role to the service account, or create a one-off custom read ACL on `sys_security_type` using the procedure in [Option B](#option-b-custom-acls-least-privilege). Without this, ACLs on AI entities will appear with unresolved type names in Veza.
{% endhint %}

{% hint style="info" %}
The `oauth_credential` table (used to populate `scope`, `peer`, `created_by`, and `expires_at` on OAuth Token nodes) is **not** covered by `oauth_admin` and by default requires `admin` to read. Without read access, OAuth Token nodes are still created, but with empty values for these attributes. Grant the service account role read access to `oauth_credential` via a custom read ACL (follow the same procedure as [Grant access to audit tables](#grant-access-to-audit-tables-activity-monitoring-only), substituting `oauth_credential` for the table name), or accept the empty attributes. OAuth 2.0 service accounts are always affected, since ServiceNow blocks OAuth for `admin` users.
{% endhint %}

#### Option B: Custom ACLs (least privilege)

For strict read-only access, create individual ACL records granting only `read` permission on each required table instead of assigning the system roles above. See [Required tables and fields](#required-tables-and-fields) for the complete list of tables Veza accesses.

{% hint style="info" %}
Creating or modifying ACL records in ServiceNow requires a user with the `security_admin` role.
{% endhint %}

To enable activity monitoring, use the same procedure described in [Grant access to audit tables](#grant-access-to-audit-tables-activity-monitoring-only), repeating for each table in the required tables list.

#### Grant access to audit tables (Activity Monitoring only)

The three audit tables used by [Activity Monitoring](#activity-monitoring) (`sys_audit`, `syslog_transaction`, `sys_update_xml`) are not covered by any built-in role except `admin`. If you are using Option A (system roles) and plan to enable Activity Monitoring, create an ACL record to grant the service account role read access to each table. If you are using Option B (custom ACLs), include these three tables in your ACL set along with the IAM tables.

{% hint style="info" %}
Creating ACL records requires a user with the `security_admin` role in ServiceNow.
{% endhint %}

1. In ServiceNow, navigate to **System Security** > **Access Control (ACL)**.
2. Click **New**.
3. Set **Type** to `record` and **Operation** to `read`.
4. In the **Name** field, enter the table name (`sys_audit`, then repeat for `syslog_transaction` and `sys_update_xml`).
5. Under **Requires role**, add the role assigned to the service account.
6. Click **Save**. Repeat steps 2–6 for each of the three tables.

{% hint style="info" %}
The audit table ACL records are only required if you plan to enable Activity Monitoring. For IAM extraction only, you can skip this step.
{% endhint %}

Expand the section below to show the IAM tables and fields used for custom role configuration:

<details>

<summary>Required tables and fields</summary>

* `sys_user`
  * `sys_id`
  * `name`
  * `user_name`
  * `email`
  * `sys_created_on`
  * `last_login`
  * `enable_multifactor_authn`
  * `active`
  * `locked_out`
  * `password_needs_reset`
  * `failed_attempts`
  * `web_service_access_only`
  * `internal_integration_user`
  * `employee_number`
  * `source`
  * `identity_type`
  * `custom_properties` (any custom user attributes)
* `sys_user_group`
  * `sys_id`
  * `name`
  * `description`
  * `sys_created_on`
  * `sys_updated_on`
  * `active`
  * `parent`
  * `manager`
* `sys_user_grmember`
  * `user`
  * `group`
* `sys_user_role`
  * `sys_id`
  * `name`
  * `description`
  * `sys_created_on`
  * `sys_updated_on`
  * `grantable`
  * `elevated_privilege`
  * `can_delegate`
  * `sys_scope`
* `sys_user_role_contains`
  * `role`
  * `contains`
  * `sys_package`
* `sys_user_has_role`
  * `user`
  * `role`
  * `inherited`
  * `state`
* `sys_group_has_role`
  * `group`
  * `role`
  * `inherited`
  * `state`
* `sys_security_acl`
  * `sys_id`
  * `name`
  * `description`
  * `advanced`
  * `active`
  * `admin_overrides`
  * `sys_created_by`
  * `sys_created_on`
  * `sys_updated_on`
  * `script`
  * `condition`
  * `decision_type`
  * `type`
  * `sys_package`
  * `sys_scope`
  * `operation`
* `sys_security_operation`
  * `sys_id`
  * `name`
* `sys_security_acl_role`
  * `sys_security_acl`
  * `sys_user_role`
* `sys_db_object`
  * `sys_id`
  * `label`
  * `name`
  * `access`
  * `live_feed_enabled`
  * `client_scripts_access`
  * `alter_access`
  * `delete_access`
  * `read_access`
  * `configuration_access`
  * `actions_access`
  * `caller_access`
  * `ws_access`
  * `update_access`
  * `scriptable_table`
* `sys_package` (**web service access required** — see [ACL Rule package field](#servicenow-acl-rule) note)
  * `sys_id`
  * `name`
* `sys_properties` (optional)

  * `sys_id`
  * `name`
  * `value`

  **Note**: For `sys_properties`, Veza only gathers the `glide.security.allow_unauth_roleless_acl` property. Access to this table is optional.
* `sys_security_type` (**required for ACL on AI entities** — used to resolve the ACL `type` sys\_id to names such as `gen_ai_agent` and `gen_ai_skill`)
  * `sys_id`
  * `sys_name`
* `oauth_credential` (**not covered by `oauth_admin`** — used to populate `scope`, `peer`, `created_by`, and `expires_at` on OAuth Token nodes; see the note in [Permissions approach](#permissions-approach))
  * `sys_id`
  * `type`
  * `expires`
  * `peer`
  * `oauth_requestor_profile`
  * `scopes`
  * `sys_created_on`
  * `sys_updated_on`
  * `sys_created_by`

The following tables are read only when [AI Agent Discovery](#ai-agent-discovery) is in use. If the corresponding plugins are not installed, extraction is skipped and these tables do not need to be granted:

* `sn_aia_agent` (requires the `sn_aia` plugin)
  * `sys_id`
  * `name`
  * `description`
  * `strategy`
  * `sys_created_on`
  * `sys_updated_on`
* `sn_aia_agent_config` (requires the `sn_aia` plugin)
  * `sys_id`
  * `agent`
  * `active`
  * `run_as_user`
* `sn_aia_tool` (requires the `sn_aia` plugin)
  * `sys_id`
  * `name`
  * `description`
  * `type`
  * `active`
  * `sys_created_on`
* `sn_aia_agent_tool_m2m` (requires the `sn_aia` plugin)
  * `sys_id`
  * `agent`
  * `tool`
  * `active`
* `sys_gen_ai_skill` (requires Now Assist Skill Kit)
  * `sys_id`
  * `skill_name`
  * `skill_description`
  * `sys_created_on`
* `sys_gen_ai_skill_config` (requires Now Assist Skill Kit)
  * `sys_id`
  * `skill_id`
  * `active`
  * `discoverable`
* `sys_generative_ai_model_config` (requires the Generative AI Controller)
  * `sys_id`
  * `model`
  * `model_display_name`
  * `model_type`
  * `model_version`
  * `model_source`
  * `lifecycle_state`
  * `provider`
  * `enable_function_calling`
  * `max_tokens`
  * `active`
  * `sys_created_on`
* `sys_generative_ai_config` (requires the Generative AI Controller)
  * `sys_id`
  * `name`
  * `model`
  * `active`
* `sys_mi_user_tracker` (requires ServiceNow Zurich or newer with the Machine Identity Console; covered by the `mi_admin` role)
  * `sys_id`
  * `user`
  * `last_used`

</details>

## Veza setup

1. Open the Veza **Integrations** > *Integrations* overview.
2. Click *Add Integration* and pick *ServiceNow* as the integration to create.
3. Fill out the required information:

| Field                                 | Notes                                                                                                                                                                                                              |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Instance URL                          | ServiceNow FQDN hostname, for example `dev123456.service-now.com`                                                                                                                                                  |
| Credentials Type                      | Choose **Basic Auth** or **OAuth 2.0** (see below)                                                                                                                                                                 |
| API Page Size (`sysparm_limit`)       | Maximum number of records returned per API request. Default: **5000**. Reduce this value if extraction times out on large ServiceNow instances; increase it to reduce total API calls on high-volume environments. |
| User Types Filter                     | Multi-select filter to limit which user types are discovered (see [User Type Filtering](#user-type-filtering))                                                                                                     |
| Enable usage for Lifecycle Management | Enable this integration for [Lifecycle Management](#lifecycle-management)                                                                                                                                          |

#### Basic Auth

Authenticate with a ServiceNow service account username and password.

| Field    | Notes                                     |
| -------- | ----------------------------------------- |
| Username | Veza integration service account username |
| Password | Veza integration service account password |

#### OAuth 2.0 (JWT Bearer)

Authenticate using OAuth 2.0 with the JWT Bearer grant type. This method uses a certificate-based flow and does not require storing a user password in Veza.

| Field                  | Notes                                                                |
| ---------------------- | -------------------------------------------------------------------- |
| OAuth Client ID        | The Client ID of the OAuth application registered in ServiceNow      |
| OAuth User Identifier  | The ServiceNow username that the OAuth token will impersonate        |
| OAuth Client Secret    | The Client Secret of the OAuth application                           |
| OAuth Private Key File | PEM-encoded private key file for JWT signing                         |
| Private Key Password   | *(Optional)* Passphrase for the private key, if the key is encrypted |

***

## Advanced Configuration

### Custom Properties

ServiceNow contains additional metadata for users beyond the default fields collected by Veza. To include additional properties (both native ServiceNow and custom-defined) during discovery, specify the attribute name and data type for each property to collect.

1. On the integration configuration wizard, navigate to the **Custom Properties** tab.
2. Click **Add Custom Property**.
3. Enter the ServiceNow field name (from the `sys_user` table) as the **Name**.
4. Select the property **Type** from the dropdown.
5. Optionally, check **Unique Identifier** if this property should be used for identity matching in Lifecycle Management.
6. Click **Save** to complete the configuration.

The specified attributes will appear on Access Graph entities after the next extraction and can be referenced in [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/integrations/integrations/servicenow/provisioning.md) workflows as `{customprop_<property_name>}` (e.g., `{customprop_cost_center}`).

Supported types:

* String
* Number
* Boolean
* Timestamp
* String List

### User Type Filtering

Use the **User Types Filter** to control the types of ServiceNow users Veza discovers:

| Filter                      | Description                                                 |
| --------------------------- | ----------------------------------------------------------- |
| **Employee**                | Users with an employee number (`employee_numberISNOTEMPTY`) |
| **Web Service Access Only** | Service accounts with `web_service_access_only=true`        |
| **Internal Integration**    | Integration users with `internal_integration_user=true`     |

By default, all three options are selected (all users are discovered).

***

## Lifecycle Management

The ServiceNow integration supports Lifecycle Management with **Custom Actions**, enabling Veza to insert records into ServiceNow tables as part of automated workflows. ServiceNow can also serve as a source of identity for Lifecycle Management Policies.

To allow Lifecycle Management for ServiceNow, check **Enable usage for Lifecycle Management** when creating or editing the integration.

For configuration and supported actions, see [ServiceNow Lifecycle Management](/4yItIzMvkpAvMVFAamTf/integrations/integrations/servicenow/provisioning.md).

***

## Activity Monitoring

Veza supports activity monitoring for ServiceNow, enabling visibility into which ServiceNow Users are accessing which ServiceNow Tables. This helps identify over-provisioned access by comparing granted permissions against actual usage.

### Enabling activity monitoring

To enable ServiceNow activity monitoring:

{% hint style="info" %}
Activity Monitoring requires read access to `sys_audit`, `syslog_transaction`, and `sys_update_xml`. If the service account uses the minimum role set (not `admin`), you must create custom ACL records for these tables before enabling audit log extraction. See [Grant access to audit tables](#grant-access-to-audit-tables-activity-monitoring-only).
{% endhint %}

1. **Enable audit logs in ServiceNow**: Ensure that auditing is enabled in your ServiceNow instance (see [ServiceNow audit configuration](#servicenow-audit-configuration) below).
2. **Enable audit log extraction in Veza**: On the Veza **Integrations** page, locate the ServiceNow integration and click the integration name to view details. Expand the actions menu at the top right and click **Enable Audit Logs**.

### Activity data sources

Veza collects activity data from two ServiceNow logging mechanisms:

| ServiceNow Table     | Data Collected                                                        | Enabled by Default |
| -------------------- | --------------------------------------------------------------------- | ------------------ |
| `sys_audit`          | Record-level changes (create, update, delete operations)              | Per-table          |
| `syslog_transaction` | User access logs (list views, form views, report views, data exports) | Yes                |

### ServiceNow audit configuration

ServiceNow uses two separate logging systems that Veza relies on for activity monitoring. Depending on your instance configuration, you may need to verify that both are active for the tables you want to monitor.

**Record-level auditing (`sys_audit`)**: This table tracks create, update, and delete operations on individual records. Auditing is controlled by an **audit flag** on each table's dictionary record. Many standard tables (such as Incident, Change, and Problem) are audited by default, but not all tables have auditing enabled out of the box. To enable auditing for additional tables:

1. In ServiceNow, navigate to **System Definition** > **Tables**
2. Open the table you want to audit
3. Set the **Audit** flag to `true` and save

For more information, see [How to Enable Table Audits in ServiceNow](https://www.servicenow.com/community/developer-articles/how-to-enable-table-audits-in-servicenow-a-step-by-step-guide/ta-p/2960416) and [Audited Tables](https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/administer/time/concept/c_AuditedTables.html) in the ServiceNow documentation.

**Transaction logging (`syslog_transaction`)**: Tracks user navigation and access activity, including list views, form views, report views, and data exports. Transaction logging is enabled by default in ServiceNow and does not require additional configuration.

{% hint style="info" %}
If record-level auditing is not enabled for a specific table, Veza will still capture read-type activity (views, exports) from transaction logs, but will not show write operations (create, update, delete) for that table. For the most complete activity picture, enable auditing on all tables you want to monitor.
{% endhint %}

### Tracked actions

When enabled, Activity Monitoring tracks the following user actions on ServiceNow Tables:

| Action        | Description                                | Canonical Permission |
| ------------- | ------------------------------------------ | -------------------- |
| `CREATE`      | Creating a new record in a table           | Data Create          |
| `UPDATE`      | Modifying an existing record               | Data Write           |
| `DELETE`      | Deleting a record from a table             | Data Delete          |
| `LIST_VIEW`   | Viewing a list of records in a table       | Data Read            |
| `FORM_VIEW`   | Viewing a single record in a table         | Data Read            |
| `REPORT_VIEW` | Viewing a report based on table data       | Metadata Read        |
| `DATA_EXPORT` | Exporting data from a table                | Data Read            |
| `EXECUTE`     | Executing a script or operation on a table | Data Write           |
| `CREATETABLE` | Creating a new table in the instance       | Metadata Create      |
| `DELETETABLE` | Deleting a table from the instance         | Metadata Delete      |

### Supported queries

Activity monitoring supports the following queries in Query Builder:

* *ServiceNow User* to *ServiceNow Table*: Shows which users have access to which tables, with Over Provisioned Access Score (OPAS) based on actual table usage.

For more information, see [Access Monitoring](/4yItIzMvkpAvMVFAamTf/features/activity-monitoring.md).

***

## AI Agent Discovery

Veza discovers AI Agents and related assets configured in ServiceNow's Now Assist platform. The integration extracts AI Agents, Tools, Gen AI Skills, Models, and Gen AI Configs, along with the ACL Rules and the `run_as_user` relationships that govern their access.

### Plugin prerequisites

| Source plugin              | Entities discovered                                                          |
| -------------------------- | ---------------------------------------------------------------------------- |
| AI Agent Studio (`sn_aia`) | [AI Agent](#servicenow-ai-agent), [AI Agent Tool](#servicenow-ai-agent-tool) |
| Now Assist Skill Kit       | [Gen AI Skill](#servicenow-gen-ai-skill)                                     |
| Generative AI Controller   | [AI Model](#servicenow-ai-model), [Gen AI Config](#servicenow-gen-ai-config) |

If a plugin is not installed, extraction of its entities is skipped and the rest of the integration continues without error.

### Relationships

* The ServiceNow Instance contains AI Agents, Models, Tools, and Skills as direct children.
* An **AI Agent assumes a ServiceNow User** when the `run_as_user` field is set on the agent's `sn_aia_agent_config` record. This represents the "AI User" identity mode — the user whose permissions the agent operates under at runtime.
* An AI Agent is linked to its Tools through active `sn_aia_agent_tool_m2m` mappings.
* ACL Rules with a `type` of `gen_ai_agent` or `gen_ai_skill` attach to the corresponding AI Agent or Gen AI Skill. ACL decision semantics on AI assets match those on tables.
* A Gen AI Config is linked to an AI Model by model name, representing a platform-level capability-to-model binding.

{% hint style="info" %}
ServiceNow does not model a direct foreign key from an AI Agent to the model it uses. Model assignment is resolved at the platform level through Gen AI Config records that bind platform capabilities to specific models. As a result, Veza does not create a direct AI Agent → AI Model edge.
{% endhint %}

***

## Machine Identity Console

Starting with the ServiceNow `Zurich` release, Veza reads the Machine Identity Console (MIC) tracker table `sys_mi_user_tracker` to enhance the `last_login_at` signal on ServiceNow Users:

* Each tracker row records the `last_used` timestamp of a machine identity's most recent API call.
* Veza joins this onto the corresponding user, so that API-only service accounts reflect real activity (instead of appearing dormant based on UI login alone).

| Source table          | Entities enriched                                   |
| --------------------- | --------------------------------------------------- |
| `sys_mi_user_tracker` | [ServiceNow User](#servicenow-user) `last_login_at` |

Veza takes the maximum of `sys_user.last_login_time`, `sys_user.last_login`, and `sys_mi_user_tracker.last_used` per user, so configurations without MIC are unaffected.

The `mi_admin` role grants read access to `sys_mi_user_tracker`. If the service account uses the minimum role set (`itil`, `access_analyzer_admin`, `oauth_admin`), add `mi_admin` to pick up this signal — or grant a custom read ACL on the table. If the Machine Identity Console is not available, this step is skipped.

***

## ServiceNow entities and attributes

The following properties are available to filter results and create fine-grained searches, queries, and workflows:

### ServiceNow User

ServiceNow users are individual accounts that can access the platform. Each has a unique name, and can be assigned to one or more groups.

| Veza Attribute              | ServiceNow Field            | Type      |
| --------------------------- | --------------------------- | --------- |
| `email`                     | `email`                     | String    |
| `employee_number`           | `employee_number`           | String    |
| `source`                    | `source`                    | String    |
| `is_active`                 | `active`                    | Boolean   |
| `is_locked`                 | `locked_out`                | Boolean   |
| `mfa_active`                | `enable_multifactor_authn`  | Boolean   |
| `password_needs_reset`      | `password_needs_reset`      | Boolean   |
| `failed_attempts`           | `failed_attempts`           | Number    |
| `web_service_access_only`   | `web_service_access_only`   | Boolean   |
| `internal_integration_user` | `internal_integration_user` | Boolean   |
| `identity_type`             | See note below \*\*         | String    |
| `created_at`                | `sys_created_on`            | Timestamp |
| `last_login_at`             | `last_login` \*\*\*         | Timestamp |

\*\* Veza determines the user's identity type (`HUMAN` or `NONHUMAN`) using the ServiceNow `identity_type` field when available. If the field is empty or "unclassified", Veza classifies users as Non-Human when `internal_integration_user` is true or the user has no email address, and Human otherwise.

ServiceNow users with `identity_type` set to "AI Agent" are classified as Non-Human identities with an AI Agent subtype. This classification represents AI-powered service accounts in ServiceNow (such as Virtual Agent or predictive intelligence bots), distinguishing them from traditional service accounts and integration users.

\*\*\* `last_login_at` is the maximum of the `sys_user` fields `last_login_time` and `last_login` and, when available, the user's most recent `last_used` timestamp from `sys_mi_user_tracker`. Including the Machine Identity Console tracker ensures API-only service accounts do not appear dormant just because they never log in via UI. See [Machine Identity Console](#machine-identity-console).

### ServiceNow Group

Groups are collections of users based on role or function, used to grant permissions to several users at a time.

| Veza Attribute | ServiceNow Field | Type      |
| -------------- | ---------------- | --------- |
| `description`  | `description`    | String    |
| `parent_group` | `parent`         | String    |
| `manager_id`   | `manager`        | String    |
| `is_active`    | `active`         | Boolean   |
| `created_at`   | `sys_created_on` | Timestamp |
| `updated_at`   | `sys_updated_on` | Timestamp |

### ServiceNow Role

A role is a collection of permissions, allowing a user or group to take a variety of actions. For example, a role might grant the ability to create, read, update, or delete certain types of records.

| Veza Attribute       | ServiceNow Field     | Type      |
| -------------------- | -------------------- | --------- |
| `description`        | `description`        | String    |
| `scope`              | `sys_scope`          | String    |
| `is_grantable`       | `grantable`          | Boolean   |
| `elevated_privilege` | `elevated_privilege` | Boolean   |
| `can_delegate`       | `can_delegate`       | Boolean   |
| `created_at`         | `sys_created_on`     | Timestamp |
| `updated_at`         | `sys_updated_on`     | Timestamp |

### ServiceNow ACL Rule

ACL rules control access to ServiceNow resources by defining conditions that must be met before a user can perform an action. For example, an ACL rule might restrict a user's ability to view a particular field in a record.

| Veza Attribute    | ServiceNow Field  | Type      |
| ----------------- | ----------------- | --------- |
| `description`     | `description`     | String    |
| `object_type`     | `type`            | String    |
| `package` \*      | `sys_package`     | String    |
| `scope`           | `sys_scope`       | String    |
| `operation`       | `operation`       | String    |
| `condition`       | `condition`       | String    |
| `decision_type`   | `decision_type`   | String    |
| `created_by`      | `sys_created_by`  | String    |
| `is_active`       | `active`          | Boolean   |
| `is_advanced`     | `advanced`        | Boolean   |
| `admin_overrides` | `admin_overrides` | Boolean   |
| `created_at`      | `sys_created_on`  | Timestamp |
| `updated_at`      | `sys_updated_on`  | Timestamp |

\* Web service access to the `sys_package` table is **required** for Table→User relationship extraction. Without it, ACL rules will be extracted but Table→User relationships will not be created. To enable: in ServiceNow, navigate to **System Definition** > **Tables**, open the `sys_package` table, and check **Allow access to this table via web services**. See [Application Access Web Services](https://developer.servicenow.com/dev.do#!/learn/learning-plans/utah/new_to_servicenow/app_store_learnv2_securingapps_utah_application_access_web_services) for details.

![Enable web service access on the sys\_package table](/files/tjsYwGXBcZxmMfXgRn0K)

### ServiceNow Table

ServiceNow tables are collections of records that store data. Each table has a unique name and can contain various fields. Below are the properties from `sys_db_object` that Veza extracts for Table entities.

| Veza Attribute          | ServiceNow Field        | Type    |
| ----------------------- | ----------------------- | ------- |
| `access`                | `access`                | String  |
| `actions_access`        | `actions_access`        | Boolean |
| `alter_access`          | `alter_access`          | Boolean |
| `caller_access`         | `caller_access`         | String  |
| `client_scripts_access` | `client_scripts_access` | Boolean |
| `configuration_access`  | `configuration_access`  | Boolean |
| `delete_access`         | `delete_access`         | Boolean |
| `label`                 | `label`                 | String  |
| `live_feed_enabled`     | `live_feed_enabled`     | Boolean |
| `read_access`           | `read_access`           | Boolean |
| `scriptable_table`      | `scriptable_table`      | Boolean |
| `update_access`         | `update_access`         | Boolean |
| `ws_access`             | `ws_access`             | Boolean |

### ServiceNow AI Agent

AI Agents are automated assistants configured in ServiceNow's AI Agent Studio. Each agent has an execution strategy and can invoke a set of Tools to complete tasks.

| Veza Attribute | ServiceNow Field                      | Type      |
| -------------- | ------------------------------------- | --------- |
| `description`  | `description`                         | String    |
| `run_as_mode`  | See note below \*                     | String    |
| `is_active`    | `active` (from `sn_aia_agent_config`) | Boolean   |
| `created_at`   | `sys_created_on`                      | Timestamp |

\* `run_as_mode` is derived from the agent's `sn_aia_agent_config.run_as_user` field: `ai_user` when `run_as_user` is set (the agent operates under a specific user's permissions, and Veza creates an **Assumes User** edge to that ServiceNow User), or `dynamic_user` when it is empty (the agent operates under the caller's permissions at runtime).

### ServiceNow AI Agent Tool

AI Agent Tools are capabilities an AI Agent can invoke to read or act on ServiceNow data. Tools are associated with agents through `sn_aia_agent_tool_m2m` mappings.

| Veza Attribute | ServiceNow Field | Type      |
| -------------- | ---------------- | --------- |
| `description`  | `description`    | String    |
| `tool_type`    | `type`           | String    |
| `is_active`    | `active`         | Boolean   |
| `created_at`   | `sys_created_on` | Timestamp |

### ServiceNow Gen AI Skill

Gen AI Skills are reusable, prompt-based capabilities defined in Now Assist Skill Kit.

| Veza Attribute | ServiceNow Field                          | Type      |
| -------------- | ----------------------------------------- | --------- |
| `description`  | `skill_description`                       | String    |
| `is_active`    | `active` (from `sys_gen_ai_skill_config`) | Boolean   |
| `created_at`   | `sys_created_on`                          | Timestamp |

### ServiceNow AI Model

AI Models represent the generative models configured for use by the ServiceNow Now Assist platform (from `sys_generative_ai_model_config`).

| Veza Attribute    | ServiceNow Field              | Type      |
| ----------------- | ----------------------------- | --------- |
| `model_type`      | `model_type`                  | String    |
| `max_tokens`      | `max_tokens`                  | String    |
| `lifecycle_state` | `lifecycle_state`             | String    |
| `model_provider`  | `provider` (display value) \* | String    |
| `is_active`       | `active`                      | Boolean   |
| `created_at`      | `sys_created_on`              | Timestamp |

\* Veza reads the `provider` reference field using `sysparm_display_value=true` to resolve it to the provider's display name (for example, `Azure OpenAI` or `Amazon Bedrock`). If `provider` is empty, Veza falls back to `model_source`.

### ServiceNow Gen AI Config

Gen AI Configs bind a platform capability to a specific AI Model, controlling which model a given Now Assist feature uses (from `sys_generative_ai_config`). Veza joins these records to [AI Models](#servicenow-ai-model) by model name.

| Veza Attribute | ServiceNow Field | Type    |
| -------------- | ---------------- | ------- |
| `is_active`    | `active`         | Boolean |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/servicenow.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.