# ServiceNow ITSM

This Integration requires Fides Cloud or Fides Enterprise. For more information, [talk to our solutions team. (opens in a new tab)](/content/speak-with-us?utm_source=docs-site/index.html)

[ServiceNow IT Service Management (ITSM) (opens in a new tab)](https://www.servicenow.com/products/itsm.html) is a cloud-based platform for managing IT services, including incidents, problems, change requests, service catalog requests, and knowledge management. This integration processes access and erasure requests against personal data stored in a ServiceNow instance, covering user records, ITSM tickets, audit logs, attachments, and email artifacts.

## Prerequisites [Permalink for this section](/content/docs/integrations/saas-integrations/servicenow-itsm#prerequisites/index.html)

In order to [integrate](/content/docs/integrations/index.html) with ServiceNow ITSM, you'll need to collect the following information:

| Name | Description |
| :-- | :-- |
| **Domain*** | The hostname of your ServiceNow instance, without the protocol (e.g. `your-instance.service-now.com`). |
| **Client ID*** | The Client ID from your OAuth Application Registry record. See [ServiceNow's OAuth setup documentation (opens in a new tab)](https://www.servicenow.com/docs/bundle/yokohama-platform-security/page/administer/security/task/t_CreateEndpointforExternalClients.html) for details. |
| **Client secret*** | The Client Secret associated with the OAuth Application Registry record above. |

### Configuring ServiceNow for the integration [Permalink for this section](/content/docs/integrations/saas-integrations/servicenow-itsm#configuring-servicenow-for-the-integration/index.html)

Before adding the integration in Fides, prepare the ServiceNow instance:

1. **Enable the client_credentials grant.** In ServiceNow, set the system property `glide.oauth.inbound.client.credential.grant_type.enabled` to `true`.
2. **Create an OAuth Application Registry record.** Navigate to **System OAuth → Application Registry → New → "New Inbound Integration Experience" → "OAuth - Client credentials grant"**. Note the generated **Client ID** and **Client Secret**.
3. **Assign an integration user.** The OAuth registry must be tied to a ServiceNow user account with read and write access to `sys_user` and the ITSM tables (`incident`, `problem`, `change_request`, `change_task`, `sc_request`, `sc_req_item`, `sc_task`, `kb_knowledge`, `kb_feedback`, `task_time_worked`, `sys_audit`, `sys_attachment`, `sys_journal_field`, `sys_email`, and related membership tables). Erasure additionally requires write access on the user and ticket tables.

## Integrating with ServiceNow ITSM [Permalink for this section](/content/docs/integrations/saas-integrations/servicenow-itsm#integrating-with-servicenow-itsm/index.html)

To integrate an existing system with ServiceNow ITSM:

1. Navigate to **Data map** → **View Systems** and choose the system that you want to connect.
2. Click on the **Integrations** tab.
3. Pick the vendor or system type that you want to integrate with from the **Connection type** drop-down menu.
4. Complete the required fields for the integration and click **Save**.

You may confirm your connection is working using the **Test connection** button, if desired.

To learn more, please see our guide for [Managing Integrations](/content/docs/integrations/guides/manage-integrations/index.html).

## Technical detail [Permalink for this section](/content/docs/integrations/saas-integrations/servicenow-itsm#technical-detail/index.html)

Fides utilizes _API endpoints_ to access the _API service_ for a SaaS application. An _API service_ is the programmatic interface through which Fides can query and update data within an application to access, rectify, or delete personal information. Each SaaS tool will have a unique set of endpoints to enable privacy functions.

The ServiceNow ITSM integration uses the [ServiceNow Table API (opens in a new tab)](https://developer.servicenow.com/dev.do#!/reference/api/yokohama/rest/c_TableAPI) for all read and write operations. Identity resolution is performed via direct lookup against `sys_user.email`.

### Erasure behavior [Permalink for this section](/content/docs/integrations/saas-integrations/servicenow-itsm#erasure-behavior/index.html)

Erasure requests **mask** personal data in place via HTTP `PATCH` rather than deleting records. This preserves ITSM audit, SLA, and retention obligations and avoids orphaned references in tickets owned or modified by other users. Immutable identifiers (`sys_id`, `user_name`) are preserved so that historical references remain intact; ServiceNow rejects PATCH requests that attempt to modify these fields.

### ServiceNow ITSM endpoints [Permalink for this section](/content/docs/integrations/saas-integrations/servicenow-itsm#servicenow-itsm-endpoints/index.html)

In the table below, you can find which ServiceNow tables are accessed for each type of privacy function. All operations go through the ServiceNow Table API.

| Privacy function | Table | Description |
| --- | --- | --- |
| **Access Requests** | `sys_user` | The user record matched by email; the root of identity resolution. |
| **Access Requests** | `sys_user_grmember` | Group memberships for the user. |
| **Access Requests** | `sys_user_has_role` | Role assignments for the user. |
| **Access Requests** | `sys_user_preference` | User-level preferences and settings. |
| **Access Requests** | `incident` | Incident tickets where the user is caller, opener, or assignee. |
| **Access Requests** | `problem` | Problem records associated with the user. |
| **Access Requests** | `change_request` | Change requests associated with the user. |
| **Access Requests** | `change_task` | Change tasks associated with the user. |
| **Access Requests** | `sc_request` | Service catalog requests submitted by or for the user. |
| **Access Requests** | `sc_req_item` | Requested items belonging to the user's service catalog requests. |
| **Access Requests** | `sc_item_option` | Variable values captured on the user's requested items. |
| **Access Requests** | `sc_item_option_mtom` | Many-to-many links between requested items and their option values. |
| **Access Requests** | `sc_task` | Catalog tasks generated from the user's requested items. |
| **Access Requests** | `kb_knowledge` | Knowledge articles authored by the user. |
| **Access Requests** | `kb_feedback` | Feedback submissions left by the user on knowledge articles. |
| **Access Requests** | `task_time_worked` | Time entries logged by the user against tasks. |
| **Access Requests** | `sys_audit` | Audit log entries attributed to the user (queried by `user_name`). |
| **Access Requests** | `sys_attachment` | Attachments created by the user (queried by `sys_created_by`). |
| **Access Requests** | `sys_journal_field` | Journal field entries (work notes, comments) authored by the user. |
| **Access Requests** | `sys_email` | Email records that include the user as a recipient. |
| **Update or Erasure Requests** | `sys_user` | Masks PII fields (email, name, phone, address, etc.); preserves `sys_id` and `user_name`. |
| **Update or Erasure Requests** | `incident` | Masks user-identifying content fields on incident records. |
| **Update or Erasure Requests** | `problem` | Masks user-identifying content fields on problem records. |
| **Update or Erasure Requests** | `change_request` | Masks user-identifying content fields on change request records. |
| **Update or Erasure Requests** | `change_task` | Masks user-identifying content fields on change task records. |
| **Update or Erasure Requests** | `sc_request` | Masks user-identifying content fields on service catalog requests. |
| **Update or Erasure Requests** | `sc_req_item` | Masks user-identifying content fields on requested items. |
| **Update or Erasure Requests** | `sc_task` | Masks user-identifying content fields on catalog tasks. |
| **Update or Erasure Requests** | `kb_knowledge` | Masks user-identifying content fields on knowledge articles. |
| **Update or Erasure Requests** | `kb_feedback` | Masks user-identifying content fields on knowledge feedback submissions.