# Workflow Integrations

Connect Incident Workflows to external tools like AWS, GitHub, and Slack via API key or OAuth-based Workflow Integrations.

Some [Workflow Actions](/workflow-actions) rely on a type of integration called Workflow Integrations to connect [Incident Workflows](/ai-automation/automation/incident-workflows) to external tools. Workflow Integrations support authentication via API keys or OAuth, letting incident response teams and administrators connect PagerDuty to the tools they use during a response.

> **API Key vs. OAuth Authentication:** Tools that use OAuth redirect you to the provider's own login or authorization page to complete the connection. Tools that use API keys or tokens require you to generate a credential in the external tool and enter it directly into PagerDuty.

Workflow Integrations are supported with the following tools:

- [AWS](/workflow-actions/aws/aws-enable-or-disable-instance-protection)
- [Azure Functions](/workflow-actions/azure/azure-invoke-an-azure-function)
- [Confluence](/workflow-actions/confluence/confluence-get-page-content-by-url)
- [Datadog](/workflow-actions/datadog/datadog-create-a-graph-snapshot)
- [Dynatrace](/workflow-actions/dynatrace/dynatrace-search-logs)
- [Elasticsearch](/workflow-actions/elasticsearch/elasticsearch-search-logs)
- [GitHub](/workflow-actions/github/github-get-repository-content)
- [Logz.io](/workflow-actions/logzio/initiate-rca-in-logzio)
- [Jeli](/workflow-actions/jeli/jeli-create-a-post-incident-review)
- [Linear](/workflow-actions/linear/linear-create-issue)
- [Microsoft Entra ID (Azure AD)](https://support.pagerduty.com/main/docs/entra-id-integration-jeli)
- [New Relic](/workflow-actions/new-relic/new-relic-search-logs)
- [PagerDuty Runbook Automation](https://docs.rundeck.com/docs/)
- [ServiceNow](/workflow-actions/servicenow/servicenow-itsm-create-an-incident)
- [Slack Bot Integration](/workflow-actions/slack/archive-a-slack-dedicated-channel)
- [Splunk](/workflow-actions/splunk/splunk-search-logs)
- [Sumo Logic](/workflow-actions/sumo-logic/sumo-logic-search-logs)
- [Web API](/workflow-actions/web-api-1/send-delete-request)

> **Required Permissions:** If you have one of the following base roles, you can **add, update, and delete** Workflow Integration connections:
>
>   - Manager
>   - Admin
>   - Account Owner

## Create a Workflow Integration

Workflow Integrations securely store connection credentials.

1. In the PagerDuty web app, navigate to **Integrations**  →  **Workflow Integrations**.
2. Click **Add Connection** to the right of your preferred tool.

![Add connection](/images/kb/2bb05e1cc8828f0b7c550ca47c6ca7d7b4c9250a7b5dcb09f565230e7d76f8a1-add_connection.webp)
*Add connection*

3. Expand the section that corresponds to your preferred technology and enter the requested information:

**AWS**

## Overview

This section guides you through configuring an AWS connection for PagerDuty Incident Workflows by assuming an [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) role along with an external ID. This secure, credential-less authentication method allows PagerDuty to access your AWS resources without requiring long-lived access keys.

## Prerequisites

- AWS account with permissions to create IAM roles and policies.
- PagerDuty account with admin or global managers permissions.
- Basic familiarity with AWS IAM concepts.

## Architecture

The integration uses AWS IAM role assumption with these key components:

| Component | Description |
| --- | --- |
| **Trust Relationship** | Allows PagerDuty's AWS account to assume a role in your account. |
| **External ID** | Provides additional security against the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). |
| **IAM Role** | Defines what permissions PagerDuty has in your AWS environment. |
| **Role ARN** | The unique identifier for the role that PagerDuty assumes. |

## Step 1: Initiate Connection Setup in PagerDuty

1. Navigate to **Automation**  →  **Incident Workflows**  →  **Workflow Integrations** in PagerDuty.
2. For AWS, click **Add Connection**. The "Add AWS Connection" modal appears with the following information:
   - **Account ID**: PagerDuty's AWS account
   - **External ID**: A unique identifier (for example, `da399432e33cd15616a59a08f523ac65`)

## Step 2: Create an IAM Role in AWS

### Step 2.1: Open IAM Console

1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/).
2. Navigate to IAM (Identity and Access Management).
3. Select **Roles** from the left navigation.
4. Click **Create role**.

### Step 2.2: Configure Trust Relationship

1. Select **AWS account** as the trusted entity type.
2. Choose **Another AWS account**.
3. Enter the **Account ID** copied from PagerDuty.
4. Select the **Require external ID** checkbox.
5. Enter the **External ID** copied from PagerDuty.
6. Click **Next**.

**Example Trust Policy JSON** (visible in JSON editor):

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<<account ID copied from PagerDuty>>:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<<external ID copied from PagerDuty>>"
        }
      }
    }
  ]
}
```

> **Note:** Replace the `External ID` with your actual value from PagerDuty.

## Step 3: Attach Permissions Policy

Select permissions based on the actions your workflows perform. You can attach AWS-managed policies, create custom policies, or use a combination.

### Option A: Start with Read-Only Access _(Recommended for Testing)_

For initial setup and testing, start with minimal permissions:

1. On the **Add permissions** page, search for `ReadOnlyAccess`.
2. Select the **ReadOnlyAccess** AWS-managed policy.
3. Click **Next**.

### Option B: Create Custom Policy for Specific Actions

For production use, grant only the permissions necessary for your workflows.

**Example: CloudWatch Logs Access**

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams",
        "logs:GetLogEvents",
        "logs:FilterLogEvents"
      ],
      "Resource": "*"
    }
  ]
}
```

**Example: Lambda Function Management**

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "lambda:ListFunctions",
        "lambda:GetFunction",
        "lambda:InvokeFunction"
      ],
      "Resource": "*"
    }
  ]
}
```

### Common Workflow Actions and Required Permissions

| Workflow Action | Required AWS Permissions |
| --- | --- |
| **Query CloudWatch Logs** | `logs:DescribeLogGroups`, `logs:FilterLogEvents`, `logs:GetLogEvents` |
| **Invoke Lambda Function** | `lambda:InvokeFunction`, `lambda:GetFunction` |

## Step 4: Name and Review the Role

1. Enter a **Role name** (for example, `PagerDuty-IncidentWorkflows-Role`).
2. (Optional) Add a **Description** (for example, "Allows PagerDuty Incident Workflows to perform automated actions in AWS").
3. Add **Tags** if your organization requires them.
4. Review the trust policy and permissions.
5. Click **Create role**.

### Step 4.1: Copy the Role ARN

1. After creating the role, view your new role in the roles list.
2. Click the role name to view its details.
3. Copy the **ARN** from the summary section. Format: `arn:aws:iam::123456789012:role/PagerDuty-IncidentWorkflows-Role`

## Step 5: Complete the Configuration in PagerDuty

1. Return to PagerDuty's **Add AWS Connection** modal and complete the following fields:

| Field | Description |
| --- | --- |
| **Connection Name** | Enter a descriptive name (for example, "Production AWS Account"). |
| **Account ID** | Verify this is displayed (pre-filled). |
| **External ID** | Verify your unique external ID is displayed (pre-filled). |
| **Role ARN** | Paste the ARN you copied from AWS. |
| **Default Region** | Enter your preferred AWS region (for example, `us-east-1`, `us-west-2`). |
| **Who can edit or select the connection** | Choose access level: **Default** — All admins and global managers. **Custom** — Select specific users or teams. |
| **Allow Paige access** | Toggle ON if you want AI-powered agents to use this connection. |

2. Click **Add**.

## Step 6: Verify the Connection

PagerDuty automatically verifies the connection by assuming the IAM role you configured.

### Check Connection Status

1. Navigate to **Automation**  →  **Incident Workflows**  →  **Workflow Integrations**  →  **AWS**.
2. Locate your connection in the connections table.
3. Check the **Status** column:
   - **Healthy**: PagerDuty successfully assumed the role and can use this connection.
   - **Unhealthy**: PagerDuty cannot assume the role. Refer to the troubleshooting instructions in the following section. The status is checked automatically when the connection is created and periodically thereafter.

### Steps to Troubleshoot If Status Shows "Unhealthy"

Verify the following in AWS:

| Step to Troubleshoot | Description |
| --- | --- |
| Role ARN is correct and complete | Format: `arn:aws:iam::123456789012:role/RoleName` — no extra spaces or characters. |
| External ID matches exactly | Check the trust policy in AWS IAM and compare with the External ID shown when you created the connection. |
| Trust policy includes PagerDuty's account ID | Principal should be: `arn:aws:iam::<<PagerDuty account Id>>:root` |
| IAM role exists and is active | Verify the role was not deleted or renamed and check whether the role is in the correct AWS account. |
| No conflicting conditions in trust policy | Ensure there are no IP restrictions or other conditions that block PagerDuty. |

After making corrections in AWS, the status updates automatically within a few minutes. You can also edit the connection in PagerDuty to trigger an immediate verification check.

**Azure Functions**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **API Key** | The API Key for your Azure Function. |
| **URL** | The URL for the connection, for example, `https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>`. |

**Confluence**

1. After you select **Add Connection**, provide a **Connection Name**. If you use Confluence with Paige, PagerDuty's SRE Agent, select **Allow Paige Access**. For more on configuring Confluence with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills).
2. Click **Add**. The app navigates to a page to connect PagerDuty with Confluence.
3. Select the specific Confluence site to integrate.
4. Click **Accept**.

**Datadog**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name for the created connection. |
| **API Key** | Your Datadog API key. Can be found in Datadog at **Organization Settings** › **Access** › **API Keys**. |
| **Application Key** | Your Datadog application key. Can be found in Datadog at **Personal Settings** › **Security** › **Application Keys**, or **Organization Settings** › **Access** › **Application Keys**. |
| **Allow Paige Access** | If you use Datadog with Paige, select **Allow Paige Access**. For more on using Datadog with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

**Dynatrace**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name for the new Dynatrace connection in PagerDuty. |
| **Default** | **Yes** or **No**. If Yes, this connection is used by default for Dynatrace workflow actions when a step does not pick a specific connection. |
| **Environment Type** | **SaaS** or **Managed/ActiveGate** (on-premises or managed with ActiveGate). |
| **Environment URL** | Your Dynatrace environment base URL. SaaS: `https://{your-environment-id}.live.dynatrace.com`. Managed/ActiveGate: `https://{your-activegate-domain}:9999/e/{your-environment-id}`. Use HTTPS. |
| **OAuth2 Client ID** | The OAuth2 client ID from Dynatrace account settings (client credentials flow). |
| **OAuth Client Secret** | The OAuth2 client secret paired with the client ID. PagerDuty stores it securely. |
| **OAuth2 Account UUID** _(optional)_ | Your Dynatrace account UUID for resource scoping when requesting tokens. You can enter the raw UUID or a value prefixed with `urn:dtaccount:`. |
| **Allow Paige Access** | If you use Dynatrace with Paige, select **Allow Paige Access**. For more on using Dynatrace with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

> **OAuth2 client permissions (connection and health check)**

PagerDuty validates the connection by requesting an OAuth2 access token from Dynatrace:

- Token endpoint: `https://sso.dynatrace.com/sso/oauth2/token`
- Grant type: `client_credentials`
- Scopes used by the integration (default): `storage:logs:read` and `storage:buckets:read` (space-separated). Your OAuth client in Dynatrace must allow these scopes.

If you provide **OAuth2 Account UUID**, PagerDuty includes a resource parameter (`urn:dtaccount:{uuid}`) on the token request so the token is scoped to your account. See [Dynatrace access tokens and OAuth clients](https://docs.dynatrace.com/docs/manage/identity-access-management/access-tokens-and-oauth-clients).

> **Dynatrace environment API token permissions**

Some environments use a **Dynatrace environment API** token instead of OAuth2 for API calls. For the **Dynatrace: Search Logs** action, PagerDuty calls the Grail query APIs on your Environment URL (`POST …/platform/storage/query/v1/query:execute` and polling on `…/query:poll`).

Apply **least privilege** in Dynatrace:

- Minimum scopes for log search (typical): `storage:logs:read` and `storage:buckets:read` — align with the OAuth scopes used by the integration and sufficient for standard `fetch logs` style DQL against Grail log data.
- Broader DQL: If your queries read other Grail record types (for example spans, events, metrics), add the matching `storage:*:read` scopes for those types. See [Add permission scopes to use Dynatrace APIs](https://developer.dynatrace.com/develop/guides/security/add-permission-scopes-to-use-dynatrace-apis/) and [Permissions in Grail](https://docs.dynatrace.com/docs/platform/grail/organize-data/assign-permissions-in-grail).
- Network: Your Environment URL must be reachable from PagerDuty over HTTPS.

**Elasticsearch**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name for the new Elasticsearch connection. |
| **Default** | **Yes** or **No**. If Yes, this connection is used by default for Elasticsearch workflow actions when a step does not pick a specific connection. |
| **Elasticsearch URL** | The base URL of your Elasticsearch cluster (for example, an Elastic Cloud deployment URL or `https://elasticsearch.example.com:9200` for self-managed). Use HTTPS in production. |
| **API Key** | The **encoded** value of your Elasticsearch API key. When Elasticsearch creates an API key, it returns both an `api_key` field and an `encoded` field. You must provide the `encoded` value here — providing the `api_key` value will result an error. PagerDuty stores it securely and sends it using Elasticsearch API key authentication (`Authorization: ApiKey …`). |
| **Allow Paige Access** | If you use Elasticsearch with Paige, select **Allow Paige Access**. For more on using Elasticsearch with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

> **API Key Permissions**

Create an API key in Elasticsearch with least privilege for what your workflows need.

- Saving the connection — PagerDuty sends an authenticated **GET** request to the **Elasticsearch URL** you provide. The API key must authenticate successfully. If Elasticsearch returns **401** or **403**, the connection cannot be created or fails health checks.
- **Elasticsearch: Search Logs** — The action calls:
  - `POST /{index_pattern}/_search` for Lucene, KQL, and Query DSL query types, and
  - `POST /{index_pattern}/_eql/search` for EQL.

The API key must have permission to search (read) the indices that match every **Index Pattern** you use in workflows (for example `logs-*`, `filebeat-*`). Tighten names to only the patterns you need.

- **Example — API key with restricted index read access** — Your Elasticsearch admin can create a key using the [Create API key API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-create-api-key). The following is an example only; adjust cluster and index names to your environment:

```json
POST /_security/api_key
{
  "name": "pagerduty-incident-workflows",
  "role_descriptors": {
    "pagerduty_elasticsearch_read": {
      "cluster": ["monitor"],
      "indices": [
        {
          "names": ["logs-*", "filebeat-*"],
          "privileges": ["read"]
        }
      ]
    }
  }
}
```

- `"cluster": ["monitor"]` in the example — Helps compatibility with cluster-level checks; some hosted deployments differ — confirm with your Elastic version and security policy.
- `"privileges": ["read"]` on the indices in the example — Includes search/read on the listed patterns. If certain queries fail (for example metadata or field mapping), your admin can add `view_index_metadata` per [Elasticsearch index privileges](https://www.elastic.co/docs/reference/elasticsearch/security-privileges#privileges-list-indices). Use HTTPS, rotate API keys periodically, and avoid granting broader index wildcards than necessary. When you save the connection, PagerDuty validates the URL and API key. If the URL is wrong, the key is invalid, or your network or firewall blocks PagerDuty from reaching the cluster, the connection cannot be created.

**GitHub**

1. After you select **Add Connection**, provide a **Connection Name** and click **Add**. The app navigates to a page to connect PagerDuty with GitHub.
   - If you use GitHub with Paige, select **Allow Paige Access**. For more on configuring GitHub with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills).
2. Select the specific GitHub organizations to integrate.
3. Click **Authorize**, then click **Continue**.
4. Review the details and then select **Authorize pd-incident-workflows-integration**.

**Grafana**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **Default** | Set this as the default connection for Grafana actions. |
| **URL (Self-hosted or Cloud)** | The URL of your Grafana instance. |
| **Service Account Token** | The Grafana service account token. |
| **Allow Paige Access** | If you use Grafana with Paige, select **Allow Paige Access**. For more on using Grafana with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

**Jeli**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **API Token** | The [Jeli API token](/incident-management/after-incident/jeli-settings-and-integrations/jeli-api). |
| **Username** | The user who created the Jeli API token. |

**Linear**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **API Key** | Your Linear API key. |

**Logz.io**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **Region** | Your Logz.io account region. |
| **API Token** | The Logz.io API token. |

**Microsoft Entra ID (Azure AD)**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |

The system directs you to [Microsoft's login page](https://login.microsoftonline.com/). Follow the on-screen prompts to complete the Workflow Integration.

**New Relic**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **Region** | Your New Relic account region. |
| **Account ID** | Your New Relic Account ID. |
| **API Key** | Your New Relic User API Key. |
| **Edit connection** | Users who can edit or select the New Relic connection. |
| **Allow Paige Access** | If you use New Relic with Paige, select **Allow Paige Access**. For more on using New Relic with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

**PagerDuty Runbook Automation**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |
| **Subdomain** | The subdomain for your `runbook.pagerduty.cloud` account. |
| **Token** | The [API Token](https://docs.rundeck.com/docs/api/api_basics.html) that provides authentication. |
| **Username** | The user associated with the token. |

**ServiceNow (OAuth)**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name for the new ServiceNow connection in PagerDuty. |
| **URL** | Your ServiceNow instance URL (for example `https://yourcompany.service-now.com`). PagerDuty derives the **instance base URL** (scheme and host) from this value for API and OAuth calls. |
| **ServiceNow Username** | The ServiceNow user account used with the OAuth password grant (stored securely in PagerDuty). |
| **ServiceNow Password** | The password for that ServiceNow user account (stored securely). |
| **ServiceNow OAuth Client ID** | The **Client ID** from your ServiceNow OAuth API application (stored securely). |
| **ServiceNow OAuth Client Secret** | The Client Secret from that OAuth application (stored securely). |

> **How PagerDuty validates the connection**

When you save the connection, PagerDuty requests an OAuth access token from your instance at:

`POST {instance}/oauth_token.do` using the Resource Owner Password Credentials grant (`grant_type=password`) with your client_id, client_secret, username, and password. If ServiceNow returns a non-success response, the connection cannot be created (or health checks fail). Error text from ServiceNow can appear in the connection error when available.

> **ServiceNow-side setup and permissions**

Your ServiceNow administrator must configure the instance so the integration can authenticate and so workflow actions can read Knowledge data.

- **OAuth application** — Create or use an OAuth API endpoint/application on the instance that allows the password grant (the same parameters PagerDuty sends above). Follow your ServiceNow release documentation for creating OAuth applications and client credentials.
- **Integration user** — The ServiceNow Username must be able to complete the password grant and must have rights appropriate for the workflow actions you run (at minimum, for Retrieve Runbook from Knowledge Base Article, read access to Knowledge content via the Table API).
- **Tables and APIs used by Retrieve Runbook** — The action calls ServiceNow Table API endpoints, including:
  - `sn_km_mr_st_kb_knowledge` — primary article payload (number, short description, content, author, sys_id, and related fields). This table is part of ServiceNow Managed Knowledge capabilities; confirm with your admin that it exists and is licensed on your instance.
  - `kb_knowledge` — supplemental fields (knowledge base, workflow state, last updated metadata).
  - `sys_attachment` (attachment API) — optional attachment metadata when Include Attachments is enabled (JSON metadata only; binary files are not downloaded).

Exact role names vary by instance, plugins, and ACLs. Your admin should grant the integration user read access to these tables (and REST access) consistent with your security model. See ServiceNow's Table API and your internal OAuth setup guides.

- **Network** — The ServiceNow instance must be reachable from PagerDuty. Use HTTPS in production.

When you save the connection, PagerDuty validates credentials as described. If the URL is wrong, OAuth settings do not match your instance, the user cannot authenticate, or your network or firewall blocks PagerDuty, the connection cannot be created.

**Slack Bot Integration**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name to give the new connection. |

The system directs you to Slack's authentication page. Follow the on-screen prompts to complete the Workflow Integration.

**Splunk**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name for the new Splunk connection in PagerDuty. |
| **Splunk URL** | Enter the base URL of your Splunk instance's REST API, including the port when your environment requires it (many deployments use port 8089). Example: `https://splunk.example.com:8089`. |
| **Authentication Token** | Enter your Splunk authentication token or session key used to access the REST API. This value is stored securely in PagerDuty. |
| **Allow Paige Access** | If you use Splunk with Paige, select **Allow Paige Access**. For more on using Splunk with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

**Sumo Logic**

| Field Name | Description |
| --- | --- |
| **Connection Name** | The name for the new Sumo Logic connection in PagerDuty. |
| **Deployment** | Select the Sumo Logic deployment region for your account. Choose one of: `US1` (default), `US2`, `CA`, `FED`, `EU`, `DE`, `AU`, `JP`, `IN`. This determines which Sumo Logic API endpoint PagerDuty uses. |
| **Access ID** | Enter your Sumo Logic Access ID. Stored securely in PagerDuty. |
| **Access Key** | Enter your Sumo Logic Access Key. Stored securely in PagerDuty. |
| **Allow Paige Access** | If you use Sumo Logic with Paige, select **Allow Paige Access**. For more on using Sumo Logic with Paige, see [Paige: Connectors and Skills](/ai-automation/advance/connectors-tools-and-skills). |

**Web API**

| Field Name | Description |
| --- | --- |
| **Connection Name** | Enter a name for the new connection. |
| **Authentication Headers** | Enter the headers to include in Web API calls made with this connection, one per line, for example, `Authorization: Bearer XXXX`. |
| **Allowed Hostnames** | Enter the hostnames to allow sending these credentials to, one per line. An asterisk (`*`) may be used for subdomains, for example, `example.com`, `subdomain.example.com`, or `*.example.com`. |
| **Health Check URL** | Enter a URL to monitor the health of this connection. |
| **Health Check Method** | Select which HTTP method to use for the health check request, `HEAD` or `GET`. |

4. In the field **Who can edit or select the connection**, select **All admins and global managers** (default) or **All admins, global managers team managers on specific teams**. If you choose **All admins, global managers team managers on specific teams**, select one or more [Teams](/account-admin/teams) from the **Select teams** dropdown.

![Select Teams](/images/kb/252076bdccbb7f4243cf892bc4e6a06b6654ec46dc4da0fda5c4f04299aab8b1-select_teams.webp)
*Select teams dropdown*

> **Permission Scope:** This setting affects which users can edit the connection or select the connection when configuring actions in an Incident Workflow. This setting does not affect who can invoke an Incident Workflow; that setting is administered while [creating or editing an Incident Workflow](/ai-automation/automation/incident-workflows#create-an-incident-workflow).

5. Click **Add**.

## Delete a Workflow Integration

1. In the web app, navigate to **Integrations**  →  **Workflow Integrations**.
2. Click the **Integration Name** (for example, **AWS**, **Azure Functions**) that contains the connection you want to delete.
3. To the right of the connection you want to delete, click   **Delete**.
4. In the confirmation modal, click **Delete**. This action cannot be undone.

## Use a Workflow Integration in Incident Workflows

Creating a Workflow Integration allows you to use specific tool-specific Incident Workflow Actions. Read [Incident Workflows](/ai-automation/automation/incident-workflows#actions) for more information.