Why asset tracking should not become another disconnected system

An asset-tracking deployment can solve one visibility problem while creating another.

The new platform knows where an item was detected. The ERP knows how it was purchased and valued. The WMS knows where it was booked. An asset register knows who owns it. A reporting platform tries to combine the results.

If these records remain disconnected, teams compare screens, export spreadsheets and decide manually which version to trust.

The answer is not necessarily one system that owns everything. It is a clear division of responsibilities and a reliable way to share the asset and movement record.

Start by defining what each system knows

Different systems often answer different questions.

An ERP may own:

• Purchasing and financial value.

• Stock transactions.

• Supplier and order information.

• Accounting treatment.

A WMS may own:

• Expected warehouse location.

• Put-away and picking workflows.

• Allocation and fulfilment state.

An asset-management system may own:

• Asset classification and ownership.

• Maintenance or inspection records.

• Assignment to people or teams.

An asset-visibility platform may own:

• Tag identities and associations.

• Physical sightings.

• Interpreted last-known locations.

• Movement history.

• Evidence and confidence behind the position.

Integration works better when these responsibilities are explicit. It becomes fragile when two systems silently compete to own the same field without a rule for reconciliation.

The expected location and observed location are different facts

One of the most valuable comparisons is also one of the easiest to blur.

• Expected location: where the operational system says an asset should be.

• Observed location: where tracking evidence most recently placed it.

These should not automatically overwrite each other. A difference may indicate a missed transaction, incorrect put-away, unexpected movement or stale tracking evidence. That difference is an exception to investigate, not merely a data-sync error.

Keeping both facts allows location validation to direct attention without destroying the evidence of disagreement.

Share identities before sharing events

Movement events are useful only when receiving systems know which business object moved.

The integration design needs a stable mapping between:

• The physical tag identifier.

• The Waytrail asset record.

• Relevant ERP, WMS or asset-register identifiers.

Decide how assets are created, associated, changed and retired. If a tag is replaced or reassigned, connected systems need the correct persistent identity rather than treating the new tag as an unrelated asset.

Identity governance is not glamorous, but it prevents technically successful event delivery from creating duplicate or orphaned records.

Use the right integration pattern for the job

API reads

A REST API lets another system request the current record when it needs it: asset details, last-known position, movement history or other supported data.

This can suit dashboards, reconciliation jobs, operational screens or scheduled processes.

Webhook events

Webhooks push an event when relevant movement occurs. This can support alerts, downstream workflows or updates that should not wait for a polling cycle.

Signed webhooks allow the receiver to verify the source. A delivery history helps teams understand what was sent and when, which is important when diagnosing integration behaviour.

Reporting and analytics

Movement history may also feed reporting or analysis. Keep the distinction between operational events and analytical extracts clear; they can have different freshness, volume and resilience requirements.

The correct pattern depends on what the receiving system needs to do, how quickly it needs to act and how failures should be handled.

Do not push raw detections downstream

Reader data can contain duplicates, low-confidence sightings and hardware-level identifiers. If every consumer receives raw reads, each one has to recreate the interpretation logic.

That creates inconsistent answers and tight coupling to the tracking hardware.

Instead, share the interpreted record where possible:

• Persistent asset identity.

• Recognised site, area and zone.

• Event type and time.

• Last-known position.

• Relevant evidence or confidence.

• A stable schema that does not depend on one reader model.

Read why raw detections are not operational answers for the interpretation steps that should happen before other systems act.

Plan for failure and ownership

An integration is not complete when the first event arrives.

Define:

• Which team owns the source and destination.

• How failed deliveries are surfaced and retried.

• Whether event ordering matters.

• How duplicate events are handled safely.

• What happens when a destination is unavailable.

• How schema changes are managed.

• How tag or asset associations are corrected.

• Which system users consult during a disagreement.

The operational process matters too. If a webhook creates an alert, who receives it, what evidence can they inspect and what action are they expected to take?

Without ownership, automation can move ambiguity faster rather than remove it.

Integrate only what creates value

A first deployment does not need every possible connection.

Begin with the minimum integration needed to test the operational outcome. That might be:

• Importing an existing asset identifier.

• Comparing an expected location with the observed record.

• Sending a movement event to an established alerting workflow.

• Making last-known location available within an existing operational screen.

Avoid turning a bounded visibility trial into a full enterprise-data programme before the asset record has proved useful.

The architecture should allow expansion, but scope should follow the commercial case.

Questions for buyers and architects

Ask:

• Which system owns each asset field?

• How are tag and business identifiers mapped?

• Are expected and observed locations kept distinct?

• Does the API expose the same interpreted record users see?

• Which events can webhooks publish?

• Are webhooks signed?

• Can delivery attempts be reviewed?

• How are duplicates, retries and destination failures handled?

• Can multiple tracking technologies feed the same asset model?

• What is the minimum integration required for the first use case?

These questions connect technical design to adoption and operational trust.

One record, used in more than one place

Waytrail maintains asset identities, last-known locations, sightings and movement history in one operational record. Its REST API lets existing systems read supported data, while signed webhooks push movement events with a delivery history showing what was sent and when.

The goal is not to replace every system around the asset. It is to ensure the physical evidence does not remain trapped in another dashboard.

See the record and integrations behind Waytrail, then define the smallest connection that makes the first use case genuinely operational.