Playbook: Connect Lansweeper Asset Intelligence with Jira Service Management for automated alerts

When a firewall changes configuration or a router disappears from your estate, you want your operations team to know immediately, not when someone happens to check a dashboard. Lansweeper's Flow Builder lets you wire up exactly that kind of automated alert, pushing rich context about the affected asset directly into Jira Service Management's operations queue.

The workflow follows a three-step pattern: Lansweeper detects an asset change, checks whether the device type warrants an alert, and fires a structured notification into your operations queue.

What you will need

Before you start, make sure you have:

• A Lansweeper site with Flow Builder enabled
• A Jira Service Management account with an operations team configured
• Admin access to both platforms

Part one: Setting up the Jira API integration

Creating the API integration in Jira Service Management

The Jira side of this integration creates a named endpoint that accepts incoming alerts and routes them to your operations team. Authentication uses a GenieKey, also labeled "API key" in the Jira Service Management interface. It differs from a standard Atlassian API token and works only with the Operations integration events API.

1. Go to your team's Operations page in Jira Service Management and select Integrations from the left navigation.
2. Select Add integration, search for "API" and select the API integration type.
3. Give it a clear name ("Lansweeper Flow Builder" works well) and optionally assign it to a specific team using the Assignee team field. Assigning it here means alerts route automatically to that team's queue.
4. Select Continue, then Turn on integration. Turn on the integration before any rules you configure can fire.
5. Copy the GenieKey. Jira Service Management shows it only once, so store it somewhere safe. You will need it when setting up the Flow Builder connection.

Note: Atlassian recommends creating a separate API integration per monitoring system rather than reusing the default integration. It keeps alert processing rules clean and lets you adjust routing per source without affecting other integrations.

Configuring alert processing rules

Once the integration is active, you can define how incoming alerts are handled. A typical starting configuration has a single "Create Alert" rule assigned to your infrastructure team, set to fire on all matching alerts.

This default is a sensible starting point. You can layer in more granular conditions later, for example routing alerts to different teams based on the asset type field in the payload.

Part two: Setting up the Flow Builder connection

Before building the workflow, create a named connection for the Jira Service Management integration.

In Flow Builder, navigate to your connections and create a new connection of type Ops Integration API Key (part of the Jira Service Management connector). Enter the GenieKey you copied from the Jira integration setup. Give it a recognizable name. "Ops Integration API Key" is the convention used in the alert template.

This connection is reusable. Any future Flow Builder workflow that sends alerts to Jira Service Management Operations can reference the same named connection without re-entering the key.

Part three: Add the ready-made template

Rather than building the workflow step by step, add the template from the Lansweeper Marketplace: Jira Service Management Operations alerts for drift on critical devices. It already contains the trigger, tags, loop, asset lookup, branch and alert steps described below. You only need to add your connections and adjust 3 labeled customization points.

Adding the template from the Marketplace

1. In Flow Builder, open the Marketplace.
2. Search for Jira Service Management Operations alerts for drift on critical devices and add it to your workflows.
3. The workflow opens fully built, ready for you to configure.

What the template does

• Trigger: fires on Asset Updated and Asset Deleted events. Asset creation and new-discovery events are off by default.
• Set Alert Tags (edit as needed): tags every alert Lansweeper and Critical. Change these tags here.
• Repeat for Each Asset: loops over every asset in the trigger event.
• Get Asset Details: looks up each asset's URL and last-updated timestamp, alongside the standard asset fields.
• If device matches condition (edit as needed): routes the asset down the alert path when its type is Router or Firewall. Add more types, or change these two, here.
• Set Details Values (tailor as needed): builds the key, name, asset type, URL and last-updated fields that appear as alert details.
• Create Integration Alert: sends the alert. Priority is set to P1, source to Lansweeper, and entity to CriticalDevice. The alias and message both reference the asset name, so repeated updates on the same device de-duplicate correctly.

What you still need to configure

The template ships with the connection fields empty. Before you enable it:

• Set the Lansweeper connection on the trigger and the Get Asset Details step.
• Set the Jira Service Management connection (the Ops Integration API Key connection you created in part two) on the Create Integration Alert step.

Once the connections are set, test the workflow before enabling it against live data.

Adapting the workflow for other device types

The conditional logic in the If device matches condition (edit as needed) step is quick to modify. To monitor a different set of device types:

• Open that step and update the values in the condition group
• Add new condition rows using the + button to match additional types
• Use Or if you want any condition to trigger the alert, rather than all of them

To alert on changes across servers and network infrastructure, for example, use an Or group matching Server, Router, Firewall and Switch. The workflow structure remains the same.

The message and description in the alert step can also be tailored per device type. A message about unexpected firewall reconfiguration reads differently from one about a server going offline, and that context helps the on-call engineer respond faster.

Checking the results in Jira

When the workflow runs and the Create Integration Alert step succeeds, a new alert appears in your Jira Service Management operations team's Alerts queue. It will carry the message, tags, details and alias you configured. The alias ensures repeated updates to the same device update a single open alert rather than flooding the queue.

The integration overview in Jira, under Operations > Integrations, shows the integration status, the assigned team, the API key, and the alert processing rules. If alerts are not appearing, check here first: confirm the integration is switched on and that the GenieKey in your Flow Builder connection matches exactly.

Summary

1. Create a named API integration in Jira Service Management Operations and copy the GenieKey token.
2. Create an Ops Integration API Key connection in Flow Builder using that token.
3. Add the ready-made template from the Flow Builder Marketplace. The trigger, loop, Get Asset Details step, and conditional branch are already built.
4. Use a Create Integration Alert step to send the alert: no headers, no manual JSON.
5. Set the alias using the asset key to deduplicate repeated alerts on the same device.
6. Enable the workflow and verify alerts appear in Jira before rolling out to production.

Once the pattern is established, you can adapt it to other device types, different teams, or richer payloads. The same structure works equally well for monitoring server patch compliance, unexpected software installations, or any other asset change that warrants an operational response.

Alerts are one way to use the connector. To enrich Jira Service Management tickets with Lansweeper asset data instead, see Jira Service Management ticket enrichment.