How to add relationships and context to your Lansweeper assets

Lansweeper is excellent at what it was built for: discovering assets and keeping a reliable inventory of your IT environment. It scans your network, identifies devices, extracts technical attributes, and keeps that data up to date.

But once Lansweeper is up and running, many teams hit the same next question. How do we add more context to our assets?

That question usually comes from practical needs. IT teams want to understand not just what they have, but how their assets fit into the business. Who is using what? Which devices are affected by this contract? What services are supported by this asset and what happens if it fails?

This is where things start to get difficult.

What Lansweeper users often want to store alongside assets

Once asset discovery is under control, teams quickly want to connect assets to other types of information. Common examples include:

• Current and previous owners
• Manufacturer, warranties, lease agreements, or support contracts
• Physical locations such as offices, floors, racks, or stores
• Cost centres, departments, and business units
• Lifecycle status, criticality, and replacement plans
• Compliance controls and audit evidence

When making critical business decisions, for example, deciding next year’s budget spending, this additional context is invaluable to making the correct decisions that keep everything running smoothly and reduce overall spend and risk levels 

Why Lansweeper alone is not enough

The challenge is that Lansweeper’s data model is asset-centric by design. It’s an excellent discovery tool, but it was not designed to account for the additional context teams need.

Lansweeper treats assets as the primary object. Everything else exists in relation to that asset, often as custom fields or limited references. This can become restrictive when you want to model richer relationships.

Common friction points teams run into include:

• Too many custom fields that become hard to maintain e.g. a lifcycle custom field that has too many variations of ‘disposed’ as values, or three different custom field names representing cost centre that makes reporting a nightmare.
• Relationships are difficult to traverse in both directions, both visually in the tool and while creating reports.
• Data is exported to spreadsheets to clean and piece together with data from other systems

The workarounds most teams end up with

When Lansweeper becomes the only system, teams usually fall back on a familiar set of workarounds:

• Isolated point solutions or spreadsheets for tracking business information
• Custom reports that often require some spreadsheet manipulation

The cost is not just time, but also the risk of missing a critical insight that, for example, can lead to a vital piece of hardware’s maintenance contract expiring without anyone knowing.

A better approach: enrich your assets

A more sustainable pattern is to let Lansweeper do what it does best, and enrich the discovered assets with additional data elsewhere.

Lansweeper remains the source of truth for discovered asset data. Another system takes responsibility for modelling relationships between assets and the additional business context.

This means treating assets, people, contracts, locations, and vendors all as first-class objects, not fields bolted onto a device record. 

From an asset, you should be able to see its contract. From a contract, you should be able to see all affected assets. From a location, you should be able to see everything deployed there.

How Starhive fits alongside Lansweeper

Starhive is designed around flexible data models and relationships. Instead of prescribing the things you should track and what fields they should have, you decide exactly which objects matter to your organisation and how they connect to each other.

With the Lansweeper integration, discovered assets are synced into Starhive and kept up to date. Starhive does not replace Lansweeper’s scanning or inventory capabilities. It builds on top of them.

In Starhive, assets can be linked to:

• Users and teams
• Contracts and lease agreements
• Financial information
• Vendors and manufacturers
• Locations and sites
• Compliance frameworks and controls
• Service management tasks

These are concrete relationships. They can be queried, reported on, and navigated in both directions at the click of a button. For example, instead of asking “which assets have this lease agreement name in a field”, you can see all assets linked to a specific agreement object, along with renewal date, ownership information, and even the actual agreement pdf.

When this approach makes sense

When asset data and context live in the same model, decisions become faster and more accurate as key information isn’t locked in another system.

This setup is not for teams just getting started with asset discovery. It becomes valuable once Lansweeper is already doing its job, and the next bottleneck is context.

If any of these sound familiar, it is usually a sign:

• Asset data is trusted, but incomplete for decision-making
• Important context lives outside Lansweeper
• Reporting requires regular exports and manual work
• Asset data is used by finance, security, or compliance, not just IT

In those cases, enriching Lansweeper rather than stretching it further is often the cleaner path forward.

Starhive is built for that layer of work: connecting assets to the rest of your operational data, without breaking what already works.