{/* migration: slug: workflow-integrations */} {/* migration: section: ai-automation/automation */} Some [Workflow Actions](/actions/docs/incident-workflow-actions-overview) use a type of integration called Workflow Integrations to connect to [Incident Workflows](doc:incident-workflows). Workflow Integrations support authentication via API keys or OAuth and are designed for incident response teams and administrators to securely and easily connect PagerDuty to external tools. Tools that use. This feature simplifies automation, enhances security, and streamlines Incident Workflows, enabling faster resolutions and improved efficiency. ### 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](/actions/docs/aws) - [Azure Functions](/actions/docs/azure) - [Confluence](/actions/docs/confluence-get-page-content-by-url) - [Datadog](/actions/docs/datadog) - [Dynatrace](/actions/docs/dynatrace) - [Elasticsearch](/actions/docs/elasticsearch) - [GitHub](/actions/docs/github-get-repository-content) - [Logz.io](/actions/docs/initiate-rca-in-logzio) - [Jeli](/actions/docs/jeli) - [Linear](/actions/docs/linear) - [Microsoft Entra ID (Azure AD)](doc:entra-id-integration-jeli) - [New Relic](/actions/docs/new-relic-search-logs) - [PagerDuty Runbook Automation](https://docs.rundeck.com/docs/) - [ServiceNow](/actions/docs/servicenow-retrieve-runbook) - [Slack Bot Integration](/actions/docs/slack) - [Splunk](/actions/docs/splunk) - [Sumo Logic](/actions/docs/sumo-logic) - [Web API](/actions/docs/web-api) ### 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** :fa-arrow-right: **Workflow Integrations**. 2. Click **Add Connection** to the right of your preferred tool.

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

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.
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** :fa-arrow-right: **Incident Workflows** :fa-arrow-right: **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::<>:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "<>" } } } ] } ``` ### 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 SRE Agent 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** :fa-arrow-right: **Incident Workflows** :fa-arrow-right: **Workflow Integrations** :fa-arrow-right: **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.

b. **Azure Functions**

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>`.

c. **Confluence**

Confluence

1. After you select **Add Connection**, provide a **Connection Name**. If you use Confluence with the SRE Agent, select **Allow SRE Agent Access**. For more on configuring Confluence with the SRE Agent, see [Agent Tooling Configuration](doc:connectors-and-tools). 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**.

d. **Datadog**

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 SRE Agent Access	If you use Datadog with the SRE Agent, select Allow SRE Agent Access. For more on using Datadog with the SRE Agent, see Agent Tooling Configuration.

e. **Dynatrace**

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 SRE Agent Access	If you use Dynatrace with the SRE Agent, select Allow SRE Agent Access. For more on using Dynatrace with the SRE Agent, see Agent Tooling Configuration.

`} > **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.

f. **Elasticsearch**

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 SRE Agent Access	If you use Elasticsearch with the SRE Agent, select Allow SRE Agent Access. For more on using Elasticsearch with the SRE Agent, see Agent Tooling Configuration.

`} > **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.

g. **GitHub**

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 the SRE Agent, select **Allow SRE Agent Access**. For more on configuring GitHub with the SRE Agent, see [Agent Tooling Configuration](doc:connectors-and-tools). 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**.

h. **Grafana**

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 SRE Agent Access	If you use Grafana with the SRE Agent, select Allow SRE Agent Access. For more on using Grafana with the SRE Agent, see Agent Tooling Configuration.

i. **Jeli**

Jeli

Field Name	Description
Connection Name	The name to give the new connection.
API Token	The Jeli API token.
Username	The user who created the Jeli API token.

j. **Linear**

Linear

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

k. **Logz.io**

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.

l. **Microsoft Entra ID (Azure AD)**

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.

m. **New Relic**

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 SRE Agent Access	If you use New Relic with the SRE Agent, select Allow SRE Agent Access. For more on using New Relic with the SRE Agent, see Agent Tooling Configuration.

n. **PagerDuty Runbook Automation**

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 that provides authentication.
Username	The user associated with the token.

o. **ServiceNow**

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.

p. **Slack Bot Integration**

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.

q. **Splunk**

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 SRE Agent Access	If you use Splunk with the SRE Agent, select Allow SRE Agent Access. For more on using Splunk with the SRE Agent, see Agent Tooling Configuration.

r. **Sumo Logic**

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 SRE Agent Access	If you use Sumo Logic with the SRE Agent, select Allow SRE Agent Access. For more on using Sumo Logic with the SRE Agent, see Agent Tooling Configuration.

s. **Web API**

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](doc:teams) from the **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](doc:incident-workflows#create-an-incident-workflow). 5. Click **Add**. # Delete a Workflow Integration 1. In the web app, navigate to **Integrations** :fa-arrow-right: **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 :fa-ellipsis-h: :fa-arrow-right: **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](doc:incident-workflows#actions) for more information.