What integrations should an IT asset management service provide?

A capable IT asset management service should integrate with the systems that create, use and govern asset data, while preserving a reliable record of ownership, configuration, security status and lifecycle stage. The important question is not how many connectors are advertised, but whether each integration transfers the right information accurately, securely and consistently.

Integrations should support both discovery and ongoing synchronisation. Discovery integrations collect information from devices, user accounts, applications and subscriptions. Synchronisation then keeps those records current when equipment is assigned, software access changes, a device is retired or a security control is applied. A service that only imports data during an initial setup can become inaccurate as soon as the organisation changes.

• Identity and directory systems: These integrations should associate people, teams and locations with the assets they use. They should also reflect joiners, movers and leavers, so that equipment and access rights can be reviewed when a person changes role or leaves the organisation.
• Device and endpoint management: An integration with endpoint management should collect details such as device name, operating system, hardware configuration, encryption state, management status and last check-in. This helps identify equipment that is missing from the register, has stopped reporting or no longer meets the organisation’s requirements.
• Security and monitoring tools: Security information can add context to an asset record. For example, the record may show whether a device has protection enabled, is affected by a known weakness, or requires investigation. The asset system should distinguish between an inventory fact and a security alert rather than treating every warning as a permanent asset attribute.
• Service desk and ticketing systems: Linking incidents, requests, changes and problems to specific assets provides a history of support activity. This can reveal recurring faults, costly equipment and devices that require repeated intervention. The integration should allow technicians to open or update related records without retyping core asset information.
• Procurement, finance and contract systems: These connections should link assets to purchase records, suppliers, warranties, leases, cost centres and renewal dates. The purpose is not to duplicate the entire finance system, but to retain the commercial information needed for ownership decisions, budgeting and disposal controls.

Data mapping is a central requirement. Different systems may use different names for the same field, such as asset number, serial number, hostname or device identifier. The service should define which value is the authoritative key, how records are matched and what happens when two systems contain conflicting information. Without clear matching rules, synchronisation can create duplicate records or attach a device to the wrong person.

It should also distinguish between authoritative and supporting sources. A procurement system may be the authority for purchase cost, an endpoint platform may be the authority for technical configuration, and an identity system may be the authority for a user’s department. The asset register can bring these values together while retaining their source and last synchronisation date. This makes the record easier to verify and prevents one system from unintentionally overwriting information owned by another.

Look for integrations that support appropriate data flows rather than assuming that every connection must be fully bidirectional. In some cases, importing data is sufficient. In others, the asset service may need to send a status change, create a service ticket or trigger an approval. Each write-back action should be deliberate, permission-controlled and recorded in an audit trail.

Useful integration capabilities include:

• Scheduled and event-based updates: Scheduled imports are suitable for less time-sensitive information, while event-based updates can reflect important changes sooner. The choice should match the operational risk of stale data.
• Application programming interfaces and webhooks: Standard interfaces make it easier to connect existing systems and extend the service if the organisation’s requirements change.
• Import and export controls: A controlled file import can be useful during migration or for systems without an API. It should include validation, error reporting and a way to reverse or correct an unsuccessful import.
• Duplicate and conflict handling: The service should flag uncertain matches and conflicting values for review instead of silently creating or merging records.
• Integration health monitoring: Administrators should be able to see whether a connection is active, when it last ran, how many records were processed and whether any failures need attention.
• Field-level permissions: Sensitive information, such as purchase cost, user details or security findings, should only be available to appropriate roles.
• Auditability: Changes should show what was updated, when it changed, which source supplied the value and, where relevant, which user or process made the change.

Security controls apply to the integrations themselves. Connections should use appropriate authentication, encryption and least-privilege permissions. Access tokens, service accounts and credentials should be managed securely, with a process for reviewing, rotating and revoking them. A service should also make clear what data it stores, where it is processed and how access is restricted between different customers or business units.

Integration design should reflect the organisation’s operating model. A small business may need a straightforward connection between its asset register, identity platform and support process. A multi-site organisation may additionally need location data, departmental ownership, multiple procurement routes and different approval workflows. The service should handle these distinctions without forcing teams to maintain separate unofficial spreadsheets.

Before choosing a service, ask for a demonstration using realistic asset changes: assigning a device to a new user, replacing a device, disabling an account, renewing a subscription and retiring equipment. Check whether each change appears in the correct systems, whether failed synchronisations are visible, and whether the resulting history can be audited. This practical test is more informative than a long connector list because it shows whether the integrations support accurate decisions throughout the asset lifecycle.