> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# DRE Integrations

> Connect operational platforms, then manage how DRE listens for Signals, reads investigation context, and sends outcomes.

Open **DRE → Integrations** to manage a platform as one operational relationship. Each platform groups its connection instances, the events it can receive, and the outcomes it can send back.

A segmented control switches the page between two layouts: **Split**, a platform sidebar beside a detail pane, and **Cards**, a grid of every platform. Both show the same platforms, so pick whichever reads better for you.

## Understand the three parts

| Part        | Purpose                                                              | Examples                                                                             |
| ----------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Connections | Authenticate the account, workspace, or project that DRE can access. | Cloud account, Slack workspace, GitHub organization                                  |
| Signals     | Bring operational events into Pulse.                                 | Webhook, polling, chat event                                                         |
| Outcomes    | Send a response artifact or update to another system.                | Incident update, Slack war room, Jira follow-up, draft fix merge request, postmortem |

One platform does not need to support every part. The integration page shows what the selected platform can do and what remains unconfigured.

## Configure the capability you need

Select a platform, then configure only the sections it supports and your incident process needs.

### Connections

Add the account, workspace, or project instances that DRE should read. Some platforms support several connection instances. Some webhook or outcome capabilities do not require a connection.

### Signals

When the platform is an event source, configure a webhook, polling, or chat path. Send or retrieve one representative event and confirm that Pulse produces the expected Signal.

### Outcomes

When the platform is a response destination, enable the supported Incident update, war room, follow-up ticket, draft fix, postmortem, or provider synchronization action. An outcome-only platform does not need a Signal path.

A war room has its own minimum severity: **Critical**, **High**, or **All**. Set it so routine incidents do not open a channel.

A postmortem is written on request and costs a model call. It is an outcome, not a lifecycle state, so requesting one does not change the Incident's status.

## Read integration readiness

A platform can appear as ready, needing a connection, needing setup, partially configured, in error, needing review, or not configured. Readiness describes the complete platform setup, not authentication alone.

For a Signal capability, use source-first verification: a webhook must deliver a Signal, polling must retrieve an event, or chat must produce the expected event. Only then treat that signal path as active.

## Related

<CardGroup cols={2}>
  <Card title="Connect Pulse sources" icon="plug" href="/guide/pulse/setup">
    Verify a webhook, polling, or chat event in Pulse.
  </Card>

  <Card title="Configure webhooks" icon="webhook" href="/guide/incident/webhook-integrations/overview">
    Map third-party payloads into stable operational Signals.
  </Card>

  <Card title="Understand DRE" icon="diagram-project" href="/guide/incident/overview">
    Follow the Detect, Analyze, Resolve, and Validate stages.
  </Card>

  <Card title="Tune DRE behavior" icon="sliders" href="/guide/incident/settings">
    Control automatic RCA and re-investigation sensitivity.
  </Card>
</CardGroup>