Some Workflow Actions use a type of integration called Workflow Integrations to connect to Incident Workflows. Workflow Integrations support authentication via API keys and/or OAuth and are designed for incident response teams and administrators to securely and easily connect PagerDuty to external tools. This feature simplifies automation, enhances security, and streamlines Incident Workflows, enabling faster resolutions and improved efficiency.

Workflow Integrations are supported with the following tools:

• AWS
• Azure Functions
• Confluence
• Datadog
• Dynatrace
• Elasticsearch
• GitHub
• Logz.io
• Jeli
• Linear
• Microsoft Entra ID (Azure AD)
• New Relic
• PagerDuty Runbook Automation
• ServiceNow
• Slack Bot Integration
• Splunk
• Sumo Logic
• Web API

🚧

Required User Permissions

Users with the following base roles 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.

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

   1. 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) 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 will assume.

      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 (e.g., da399432e33cd15616a59a08f523ac65)

      Step 2: Create an IAM Role in AWS

      Step 2.1: Open IAM Console

      1. Sign in to the AWS Management Console.
      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 will 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 (e.g., PagerDuty-IncidentWorkflows-Role).
      2. (Optional) Add a Description (e.g., "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 on 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 perform these tasks:

         Field	Description
         Connection Name	Enter a descriptive name (e.g., "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 (e.g., 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 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 below.
           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. 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. 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 would block PagerDuty.

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

   2. 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, e.g., https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>.

   3. Confluence

      Confluence

      1. After you select Add Connection, provide a Connection Name.
         If you are using Confluence with the SRE Agent, select Allow SRE Agent Access. For more on configuring Confluence with the SRE Agent, please see Agent Tooling Configuration.
      2. Click Add. You will be taken to a page to connect PagerDuty with Confluence.
      3. Select the specific Confluence site to integrate.
      4. Click Accept.

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

   5. 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 may enter the raw UUID or a value prefixed with urn:dtaccount:.
      Allow SRE Agent Access	If you are using Dynatrace with the SRE Agent, select Allow SRE Agent Access. For more on using Dynatrace with the SRE Agent, please 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.

      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 and Permissions in Grail.
      • Network: Your Environment URL must be reachable from PagerDuty over HTTPS.

      
      

   6. 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	Your Elasticsearch API key. PagerDuty stores it securely and sends it using Elasticsearch API key authentication (Authorization: ApiKey …).
      Allow SRE Agent Access	If you are using Elasticsearch with the SRE Agent, select Allow SRE Agent Access. For more on using Elasticsearch with the SRE Agent, please 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 will fail 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. The following is an example only; adjust cluster and index names to your environment:

      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 may need to add view_index_metadata per Elasticsearch index privileges.
        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.

   7. GitHub

      GitHub

      1. After you select Add Connection, provide a Connection Name and click Add. You will be taken to a page to connect PagerDuty with GitHub.

         • If you are using GitHub with the SRE Agent, select Allow SRE Agent Access. For more on configuring GitHub with the SRE Agent, please see Agent Tooling Configuration.

      2. Select the specific GitHub organizations to integrate.

      3. Click Authorize, then Continue.

      4. Review the details and then select Authorize pd-incident-workflows-integration

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

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

   8. Linear

      Linear

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

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

   9. Microsoft Entra ID (Azure AD)

      Microsoft Entra ID (Azure AD)

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

      You will be directed to Microsoft's login page. Follow the on-screen prompts to complete the Workflow Integration.

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

   11. 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 will provide authentication.
       Username	The user associated with the token.

   11. 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 will fail). Error text from ServiceNow may 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.

   
   

   11. Slack Bot Integration

       Slack Bot Integration

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

       You will be directed to Slack's authentication page. Follow the on-screen prompts to complete the Workflow Integration.

   12. 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 are using Sumo Logic with the SRE Agent, select Allow SRE Agent Access. For more on using Splunk with the SRE Agent, please see Agent Tooling Configuration .

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

   14. 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, e.g., Authorization: Bearer XXXX.
       Allowed Hostnames	Enter the hostnames to allow sending these credentials to, one per line. An asterisk (*) may be used for subdomains, e.g., 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 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.

5. Click Add.

Delete a Workflow Integration

1. In the web app, navigate to Integrations Workflow Integrations.
2. Click the Integration Name (e.g., AWS, Azure Functions, etc.) that contains of the connection you'd like to delete.
3. To the right of the connection you'd like 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 will allow you to use some tool-specific Incident Workflow Actions. Please read Incident Workflows for more information.