Playbook: Alert your PagerDuty on-call team to drift on critical devices

Your network changes constantly. Most of that change is routine. Some of it is the first sign of a problem: a firewall rule altered outside a change window, or a router reconfigured by someone who should not have access to it.

Lansweeper already sees every change the moment it happens. The hard part is getting that change in front of the right person, with enough context to act on it, before it becomes an incident.

This playbook covers one Flow Builder workflow that closes that gap. It watches your critical network devices for change, and when one drifts, it sends a fully contextualized alert straight to your PagerDuty on-call queue, with no manual triage and no switching between systems to work out what happened.

What you will need

Before you start, make sure you have:

• A Lansweeper site with Flow Builder enabled
• A PagerDuty account (sign up free at pagerduty.com)
• Admin access to PagerDuty to create a service and an integration
• Edit access to Flow Builder to configure the workflow

Part one: Setting up PagerDuty

The workflow sends alerts using PagerDuty's Events API v2. To receive them, you need a PagerDuty service with an Events API v2 integration attached.

Step 1: Create or choose a service

1. In PagerDuty, go to Services > Service Directory.
2. Select + New Service, or select an existing service if you already have one for network operations.
3. Give it a clear name. "Lansweeper critical device drift" works well.
4. Finish the setup wizard, using your normal escalation policy.

Step 2: Add an Events API v2 integration

1. Open the service and select the Integrations tab.
2. Select Add another integration.
3. Select Events API v2 as the integration type, then select Add.
4. PagerDuty shows an Integration Key on the integration's details page. Copy it. This is the routing key the workflow needs.

Keep this key safe. Anyone with it can send alerts to this service.

Part two: The Lansweeper and PagerDuty connections

The workflow uses two Lansweeper connector steps: the trigger, and a step that looks up asset details. Flow Builder sets up the Lansweeper connection for both automatically, so there is nothing to configure.

The PagerDuty step needs no separate connection either. The Events API v2 integration key acts as the credential, and it travels inside the alert payload itself (see Part three).

Part three: The workflow

Workflow name: PagerDuty alerts for drift on critical devices

Purpose: watches every asset change on your Lansweeper site, filters for changes to routers and firewalls, and sends a PagerDuty alert for each one, carrying the asset's identity, type, and a direct link back to Lansweeper.

How it works

1. Trigger. The workflow fires on the Lansweeper asset change event. As shipped, it listens for assets that are updated or deleted. It ignores new assets and new discoveries.
2. Set PD routing key. This step stores your PagerDuty integration key as a value the rest of the workflow can reuse.
3. Repeat for each event. A single trigger run can carry more than one change event. This step loops over each one individually.
4. Get asset details. For each event, the workflow looks up the full asset record by its key, including its name, type, and a link to the asset in Lansweeper.
5. IF critical device. The workflow checks whether the asset's type is Firewall or Router. If it matches neither, the workflow stops for that event and sends no alert.
6. Create event payload. For a matching asset, the workflow builds the PagerDuty alert content: a summary, severity, and custom details.
7. Send event. The workflow posts the payload to PagerDuty using the Events API v2.

Setup and customization

• Set PD routing key: open this step and replace <your-routing-key> with the integration key you copied in Part one. This is the one change every user must make before the workflow can send alerts.
• Trigger conditions: the workflow ships with triggerOnAssetUpdated and triggerOnAssetDeleted set to true, and triggerOnAssetCreated and triggerOnNewDiscovery set to false. Change these on the trigger step if you also want to alert on new or newly discovered assets.
• Critical device definition: open the IF critical device branch to see the condition. It checks for asset type equal to "Firewall" or equal to "Router". Add more equal conditions to the or group to cover other asset types, such as "Switch" or "Load Balancer".
• Severity: the payload sets severity to critical for every alert. Edit the Create event payload step if you want to vary severity by asset type or another rule.
• Deduplication: the payload sets dedup_key to the asset's key. PagerDuty uses this to group repeated alerts about the same asset into a single incident, instead of opening a new one each time. Remove or change this if you want every drift event to raise a separate incident.

What the alert contains

Each PagerDuty alert carries the following fields:

Because the alert carries the asset's identity and a direct link back to Lansweeper, the on-call engineer does not need to open a second system to find out what changed or how important the device is.

Checking results in PagerDuty

After the workflow runs, open the service you configured in Part one and check the Alerts or Incidents tab. A drift on a firewall or router should appear within a few minutes, titled "Detected change to [asset name]", with the custom details and Lansweeper link attached.

If alerts are not appearing, check the following:

• The Set PD routing key step has your actual integration key, not the placeholder <your-routing-key>.
• The changed asset's type is spelled exactly Firewall or Router in Lansweeper; the condition is an exact match.
• The trigger step has triggerOnAssetUpdated or triggerOnAssetDeleted set to true, matching the kind of change you made.
• The PagerDuty integration on your service is still Events API v2, and the service has not been deleted or recreated (a recreated integration issues a new key).

Summary

1. In PagerDuty, create a service and add an Events API v2 integration. Copy the integration key.
2. Open the Set PD routing key step and replace the placeholder with your integration key.
3. Check the trigger conditions match the changes you want to alert on.
4. Check the IF critical device condition covers the asset types you consider critical, and add more types if needed.
5. Enable the workflow. Make a test change to a router or firewall asset in Lansweeper and confirm the alert reaches PagerDuty.

The result is a PagerDuty on-call queue that only hears about the device changes that matter, with the asset context already attached, so there are no manual lookups and no guessing which devices are critical.