Playbook: Sync Lansweeper asset data and signals to Freshservice

Some organizations use Lansweeper alongside Freshservice because it finds physical and virtual assets that would otherwise go unrecorded, and because it tracks end-of-life dates, warranty dates, and vulnerabilities across the whole estate. That value only reaches your service desk team if it also appears inside Freshservice. This playbook covers six Flow Builder templates, built on the Flow Builder Freshservice connector, that get that data into Freshservice.

This playbook covers the two device-import flows in full setup detail, since they share a schedule, a data model, and a sizing consideration you need to plan for. It covers the four Problem and ticket flows in less detail. They follow a simpler, shared pattern, and need less tailoring to get running.

Before you start: check which Freshservice product you're on

This check applies only to the two device-import flows above. The four Problem and ticket flows use Freshservice's standard Ticket and Problem objects, which don't depend on this distinction.

Freshservice's asset data model depends on when your account was created, and this changes which steps apply to you.

• Accounts created before 31 March 2026 generally still run the original Freshservice Assets API, a single, undifferentiated asset model.
• Accounts created after 31 March 2026 run Freshservice's newer ITAM experience, with three separate modules: physical assets, devices, and resources.
• All Freshservice customers move to the newer ITAM product by December 2028.

The two device-import flows in this playbook are built against the newer ITAM device API (itam/devices), not the original Assets API. This matters because:

• You need a Freshservice plan that supports the ITAM device API. Not every plan tier includes it. Confirm this with Freshservice, or in your Freshservice admin settings, before you build anything.
• The Flow Builder connector does not yet cover the ITAM API natively. Both device-import flows call itam/devices using the connector's Raw Request action, because the connector's built-in Asset actions target the older Assets API. This is expected behavior for the current connector. See Older connector versions below if you're not on the newer ITAM product.

If you're not sure which product you're on, check your Freshservice account's signup date and ask your Freshservice admin whether ITAM device records (as opposed to the classic Asset object) are available in your instance. Confirm this before you follow the device-import steps below. They assume the ITAM device API is available.

What you will need

Before you set up any of these flows, confirm you have:

• A Freshservice API key with permission to create and update the record types each flow needs (devices, Problems, or tickets).
• Your Freshservice domain, for example yourcompany.freshservice.com.
• Access to the Lansweeper connector, with the relevant Lansweeper site or sites configured.
• A real requestor email address in your Freshservice instance. All four Problem and ticket flows need one. See Setting up the Problem and ticket flows.

For the two device-import flows only, also confirm:

• A Freshservice plan that supports the ITAM device API (see above).
• An API key with permission to create and update devices specifically, not just the standard Asset object.
• A defined asset type and subtype in Freshservice for each type of hardware or virtual asset you want to sync, for example "Windows device" or "Internal VM". The flows write to an existing subtype; they don't create one for you.
• Enough spare capacity under your Freshservice license's Core Licensing Unit limit to hold every device record the flow will create. Check this against your expected asset count before you activate either flow. See Why this matters: license capacity below.

Import assets into the Freshservice CMDB

How the two device-import flows work

Each flow follows the same shape:

1. Schedule trigger. Runs hourly by default.
2. Get the saved position. Reads a cursor the flow saved at the end of its last run, so this run picks up where the last one stopped.
3. List Assets. Queries Lansweeper for assets matching the configured type and state, starting from that cursor, up to the page size limit.
4. Create or update device. For each matching asset, calls Freshservice's itam/devices endpoint. Freshservice's own API handles matching and deduplication, so the flow doesn't need a separate search-then-branch step.
5. Write back the device ID. After each create or update, the flow writes the Freshservice device ID to a custom field on the Lansweeper asset, so the two records stay linked.
6. Save the new position. Once every asset in the batch has been processed, the flow saves the next cursor for the following run. If the run reaches the end of the asset list, it saves a reset position instead, so the next run starts again from the beginning.

Why a saved position, not a time filter

Freshservice's ITAM device API processes roughly 500 devices per run within Flow Builder's execution limit. Each flow instance works through its full matching asset list in a fixed order, one batch at a time, and remembers where it stopped. This guarantees every matching asset syncs within a fixed number of runs, regardless of how often Lansweeper rescans it.

For example, with 10,000 matching assets, a page size of 500, and an hourly schedule, a full pass through the list takes 20 runs, about 20 hours. Run the flow more often to shorten this if Freshservice needs to catch up faster.

The flow saves its position automatically. You do not need to configure this.

Why this matters: license capacity

Working through the full matching asset list means the flow creates and updates device records at a steady rate. Before you activate either flow, check your Freshservice license's Core Licensing Unit limit against the number of physical and virtual devices you expect to sync. If the flow reaches the limit partway through a run, that run fails, and the saved cursor does not advance until the license issue is resolved. Ask your Freshservice admin to confirm current usage against the plan limit, and either raise the limit or narrow which asset types and subtypes you sync, so ongoing use stays under it.

Set up Create/Update Freshservice Physical Devices

1. Add the Freshservice connection. Enter your API key and domain.
2. Set the asset type. The Freshservice asset type this instance imports, for example "Windows".
3. Set the physical subtype. The Freshservice subtype value to assign, for example "Workstation".
4. Set page size and record limit. Page size controls how many records the flow fetches from Lansweeper per request. Record limit caps how many it processes in a single run.
5. Check the schedule. Hourly by default. Adjust for the size of your estate. See Tailoring the device-import flows.
6. Review the field mapping. Check which Lansweeper fields map to which Freshservice fields before go-live, and add or remove fields to match your Freshservice ITAM setup.

Set up Create/Update Freshservice Virtual Devices

Follows the same steps as Physical Devices, with one difference:

• Virtual subtype. Enter the plain text label as it appears in Freshservice, for example "Internal VM". This is a string value, not the numeric ID from Freshservice's virtual subtype reference table.

Tailor the device-import flows

• One instance per type. Freshservice needs one subtype value per device record, so deploy a separate flow instance for each physical subtype or virtual subtype you want to sync. One instance handles "Windows" devices, a second handles "Linux" devices, a third handles "Internal VM" assets, and so on. Tailor each instance to the hardware or virtual asset types in your own estate.
• Match schedule to estate size. A larger estate needs a more frequent schedule to complete a full pass through its asset list in reasonable time. A smaller estate can run less often, for example every 4 hours. A full pass takes the total number of matching assets divided by the page size, in runs.
• Review field mappings before go-live. Add or remove mapped fields to match what your Freshservice ITAM setup expects.
• Check license capacity before go-live. See Why this matters: license capacity above.

Raise Freshservice Problems and tickets from Lansweeper signals

The remaining four flows share a simpler pattern than the device-import flows: schedule, query Lansweeper for a specific condition, and (if enough matching assets are found) create one Freshservice Problem or ticket summarizing them. None of these four flows need the ITAM device API; they use Freshservice's standard Problem and Ticket objects.

Set up the Problem and ticket flows

Each of the four flows needs the same basic setup before you activate it:

1. Add the Freshservice connection. Enter your API key and domain, or confirm the flow points at an existing connection.
2. Set a real requestor email. Every flow ships with a placeholder email address in its first step. Freshservice's Create Problem and Create Ticket actions both require an initiator email, so replace the placeholder before you activate the flow. Ticket or Problem creation fails otherwise.
3. Confirm priority, status, and impact values. Each flow ships with default codes for these fields. Freshservice's Problem and ticket status values can differ between instances, so confirm the defaults are valid in yours before you activate the flow.
4. Check the schedule. Each flow ships with a default frequency. See the table above. Adjust the trigger step to match how often you want the flow to run.

Create Freshservice Problem for End of Life Assets

Checks Lansweeper for assets that reached end of life in the last 30 days. If it finds 2 or more, it creates one Freshservice Problem summarizing them.

• Runs monthly by default.
• Beyond the shared setup above, no further configuration is needed to get this flow running.

Create Freshservice Problem for Expired Warranties

Checks Lansweeper for assets with a warranty that has already expired, using a 90-day look-ahead window to catch assets before their warranty end date. If it finds 2 or more expired assets, it creates one Freshservice Problem with an HTML table listing each asset, its warranty date, and a link back to Lansweeper.

• Runs weekly, Monday 06:00 Europe/Brussels by default.
• The due date on the Problem is set automatically, 30 days out from creation.
• Tailoring: adjust the 90-day look-ahead window if you want a longer or shorter early-warning period.

Create Freshservice Problem for Offline Assets

Checks Lansweeper for active assets that have been offline for more than 5 days. If it finds 2 or more, it creates one Freshservice Problem with an HTML table listing each affected asset.

• Runs weekly, Monday 06:00 Europe/Brussels by default.
• Tailoring: adjust the 5-day offline threshold to match how quickly your team wants to be alerted.

Create Freshservice Incident for Critical Vulnerabilities

Checks Lansweeper for critical vulnerabilities found in the last 30 days. For each new one, it creates a Freshservice ticket. The ticket includes the CVE identifier, source, severity, risk score, attack vector, EPSS score, patch status, and a table of affected assets linking back to Lansweeper.

Before creating a ticket, the flow checks for an existing ticket already tagged with the same CVE, to avoid raising duplicates.

• Runs daily, 06:30 Europe/Brussels by default.
• Setup, beyond the shared steps above:
  • Set the target workspace ID. Defaults to workspace 2.
  • Keep the CVE tag on the ticket-creation step in place. The duplicate check depends on it.

Older connector versions (v12 and earlier)

If your Freshservice account is still on the original Assets API rather than the newer ITAM device API, you will need an earlier release of the Flow Builder Freshservice connector. We recommend version 12. This version includes native Asset actions built against the original Assets API. Use these native actions in place of the Raw Request steps in the two device-import templates above. The rest of the flow logic (schedule, saved-position batching, field mapping) still applies. This doesn't affect the four Problem and ticket flows, which already use native connector actions.

What this playbook doesn't cover yet

• Software and software asset management records. Freshservice treats these differently from hardware and virtual devices, and the newer ITAM API has no endpoint for them yet. Importing them isn't covered by any flow in this playbook.
• CI relationships. For example, a virtual machine's link to the physical server hosting it. The connector has no dedicated relationship action; this would need a separate Raw Request call.

Troubleshooting

Device-import flows

• A run doesn't finish, or the backlog isn't clearing. Check the schedule frequency against your estate size. See Tailoring the device-import flows.
• The same batch of assets syncs on every run, and the rest of the estate never gets a turn. The saved cursor is not advancing. Confirm the step that reads the cursor and the step that saves it both use the same key. A mismatch here fails silently: no error is raised, and the fault only shows up as the batch never changing.
• A run fails partway through with a Freshservice license error, such as reaching the Core Licensing Unit limit. Check current usage against your Freshservice plan limit. See Why this matters: license capacity. A run that fails this way stops before it saves a new cursor, so the next run retries the same batch once the license issue is resolved.
• A device record doesn't get created. Confirm the Freshservice asset type and subtype configured on the flow instance already exist in Freshservice. The flow writes to an existing subtype; it doesn't create one.
• Raw Request calls fail with a 403 or similar. Confirm your Freshservice plan tier includes the ITAM device API, and that your API key has permission to create and update devices.
• The Freshservice device ID isn't appearing on the Lansweeper asset. Check that the flow has permission to create and write custom fields on Lansweeper assets.

Problem and ticket flows

• Problem or ticket creation fails. Check the requestor email step still holds a real address, not the placeholder.
• Creation fails with an invalid priority, status, or impact value. Confirm the codes used in the flow are valid Problem or ticket values in your Freshservice instance. These can differ between instances and between Problems and tickets.
• No Problem or ticket is created even though matching assets exist. Each flow only creates a record once it finds 2 or more matching assets. Check the count in a test run before assuming the flow has failed.
• A duplicate ticket is raised for a vulnerability already reported. Confirm the CVE tag on the ticket-creation step in the Critical Vulnerabilities flow hasn't been removed or renamed. The duplicate check depends on it.

Summary

1. Confirm which Freshservice product you're on (the original Assets API or the newer ITAM device API) before you build the two device-import flows.
2. Set up the Freshservice connection once, then deploy one device-import instance per hardware or virtual asset subtype you want to sync.
3. Leave the device-import schedule at hourly for most estates, and adjust it to suit the size of yours. The flow tracks its own position between runs, so there is no time window to configure.
4. Check your Freshservice license's Core Licensing Unit limit against your expected device count before you activate either device-import flow.
5. For the four Problem and ticket flows, replace the placeholder requestor email and confirm the priority, status, and impact codes are valid in your instance before you activate each one.
6. If you're on an older connector version, swap the Raw Request steps in the device-import flows for the native Asset actions.