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

# IBM SevOne NPM alert integration

> Send IBM SevOne NPM policy alert triggers and clears to Flashduty On-call through a Webhook Definition.

Use IBM SevOne NPM 8.x Webhook Definition Manager to send policy alert triggers and clears to Flashduty On-call. SevOne has no fixed webhook payload: you write the request body as a template, so this page gives the JSON template to paste and Flashduty parses exactly that template. Each SevOne alert maps to one Flashduty alert: it is created when the policy triggers, merges on repeated triggers, and closes when the policy clears.

<div className="hide">
  ## In Flashduty On-call

  ***

  You can get the integration push URL in either of the following ways.

  ### Use a dedicated integration

  1. In the Flashduty console, go to **Channels** and open a channel
  2. Select **Configuration** → **Integrations** → **Private integration**, then click **Add an integration**
  3. Select **IBM SevOne NPM** and click **Save**
  4. Open the new integration card and copy the **push URL**

  ### Use a shared integration

  1. In the Flashduty console, go to **Integration Center → Alert Events**
  2. Select **IBM SevOne NPM** and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under **Routes** after creation
  4. Click **Save** and copy the generated **push URL**
</div>

## Configure SevOne NPM

***

Create two Webhook Definitions: one sent when an alert triggers, one sent when it clears.

<Steps>
  <Step title="Create the trigger webhook">
    1. Sign in to SevOne NMS, go to **Events → Configuration → Webhook Definition Manager**, and click add
    2. Set **Definition Type** to **Policy** and enter `Flashduty trigger` as the **Webhook Definition Name**
    3. Paste the complete Flashduty push URL into **Destination URL**
    4. Set **Request Method** to **POST** and **Content Type** to **application/json**
    5. Paste this template into **Body**:

    ```json theme={null}
    {"event":"trigger","alert_id":"$alertId","severity":"$alertState","message":"$alertMessage","alert_type":"$alertType","occurrences":"$occurrences","device_id":"$deviceId","device_name":"$deviceName","device_ip":"$deviceIp","device_group":"$groupName","policy_id":"$policyId","policy_name":"$policyName","threshold_name":"$thresholdName","object_name":"$objectName","plugin":"$pluginName","cluster":"$clusterName"}
    ```

    6. Click **Test Definition** to check that the request can be sent, then click **Save**
  </Step>

  <Step title="Create the clear webhook">
    Create a second definition the same way, named `Flashduty clear`, with this **Body** (`event` is `clear`, plus `closure_message`):

    ```json theme={null}
    {"event":"clear","alert_id":"$alertId","severity":"$alertState","message":"$alertMessage","alert_type":"$alertType","occurrences":"$occurrences","device_id":"$deviceId","device_name":"$deviceName","device_ip":"$deviceIp","device_group":"$groupName","policy_id":"$policyId","policy_name":"$policyName","threshold_name":"$thresholdName","object_name":"$objectName","plugin":"$pluginName","cluster":"$clusterName","closure_message":"$closureMessage"}
    ```
  </Step>

  <Step title="Assign the webhooks to policies">
    1. Go to **Events → Configuration → Policy Browser**, select the policies to connect, and click **Assign Webhooks**
    2. Select `Flashduty trigger`, check **Trigger** under **Apply To**, and save
    3. Click **Assign Webhooks** again, select `Flashduty clear`, check **Clear** under **Apply To**, and save
  </Step>

  <Step title="Verify the lifecycle">
    Let a policy trigger and confirm Flashduty shows an active alert. Then let it clear (the condition recovers, or acknowledge it manually under **Events → Alerts**) and confirm the alert recovers.
  </Step>
</Steps>

<Warning>
  * **Content Type** must be **application/json**. SevOne escapes variables according to the Content Type, so other types can produce JSON that cannot be parsed.
  * `event` must be `trigger` in the trigger template and `clear` in the clear template. Flashduty rejects other values.
  * The push URL carries `integration_key`, so no authentication header is needed.
</Warning>

## Payload

***

Each field is the substitution of one SevOne variable (see IBM's [Webhook Definition Manager](https://www.ibm.com/docs/en/SSUWLY_8.0/nms/Webhook_Definition_Manager.html)):

| Field | SevOne variable | In Flashduty |
| :- | :- | :- |
| `event` | fixed text | `trigger` triggers, `clear` recovers |
| `alert_id` | `$alertId` | Alert Key, label `alert_id` |
| `severity` | `$alertState` | severity, label `severity` |
| `message` | `$alertMessage` | title (prefixed with the device name) |
| `alert_type` | `$alertType` | label `alert_type` |
| `occurrences` | `$occurrences` | description |
| `device_id` / `device_name` / `device_ip` / `device_group` | `$deviceId` etc. | labels `device_id`, `host`, `resource`, `device_ip`, `device_group` |
| `policy_id` / `policy_name` | `$policyId` / `$policyName` | labels `policy_id`, `policy_name`, `check` |
| `threshold_name` | `$thresholdName` | label `threshold_name`, description |
| `object_name` / `plugin` | `$objectName` / `$pluginName` | labels `object_name`, `plugin`; only set for metric policies |
| `cluster` | `$clusterName` | label `cluster` |
| `closure_message` | `$closureMessage` | description; clear template only |

SevOne outputs `n/a` for a variable a policy type does not support (for example `$pluginName` on flow policies). Flashduty ignores `n/a`.

## Alert Key

***

Flashduty uses `alert_id` (`$alertId`, described by IBM as "The id of the triggered alert") as the Alert Key. Repeated triggers and the clear of one SevOne alert carry the same `alert_id`, so they land on one Flashduty alert. Changing the policy name, severity or message does not change the Alert Key.

If `alert_id` is empty, `n/a`, or still the unsubstituted `$alertId`, Flashduty returns a parameter error.

## Status and severity

***

`$alertState` is the policy severity. A clear event keeps the alert's severity and sets the status to recovered.

| SevOne severity | Flashduty severity |
| :- | :- |
| Emergency, Alert, Critical | Critical |
| Error, Warning | Warning |
| Notice, Info, Debug | Info |
| Empty or other | Warning |

## FAQ

***

<AccordionGroup>
  <Accordion title="Does Test Definition create an alert in Flashduty?">
    IBM documents only that Test Definition returns the status code, response header and body; it does not document the test body. If the test request carries a valid `alert_id` and `event`, it creates or closes an alert like a real notification; without them Flashduty returns a parameter error. Close any alert created by a test manually.
  </Accordion>

  <Accordion title="Can I configure only the trigger webhook?">
    Alerts arrive, but Flashduty alerts do not recover automatically. Enable auto-close on timeout in the integration or channel, or add the clear webhook.
  </Accordion>

  <Accordion title="Does a policy that keeps triggering create several alerts?">
    No. Every trigger of the same SevOne alert has the same `alert_id` and merges into one Flashduty alert.
  </Accordion>

  <Accordion title="Can trap alerts be connected?">
    The templates on this page are for the Policy type. Trap definitions use a different variable set and are out of scope for this integration.
  </Accordion>
</AccordionGroup>

## Troubleshooting

***

* **SevOne cannot deliver**: check that Destination URL is the complete push URL; for a self-signed TLS certificate, check **Allow insecure webhook connection**, and use a certificate with a SAN rather than only a Common Name
* **Flashduty returns a parameter error**: check that Content Type is application/json, `event` is `trigger` or `clear`, and `alert_id` has a value
* **Alert does not recover**: check that the clear webhook is assigned to the same policy with **Clear** checked