Identifier-based deduplication

Atomicwork's identifier-based deduplication, part of our Identification and Reconciliation Engine (IRE), automatically merges hardware asset records when multiple sources report the same device. For example, if Kandji enrolls a MacBook and an Atomicwork Discovery scan also picks it up, both reports collapse into a single asset in Atomicwork, with both Kandji and Discovery listed as contributing sources on the record.

Without deduplication, every integration would create its own asset record. A single laptop would show up as two or three separate assets across your inventory. This inflates asset counts, splits lifecycle history across records, and makes reconciliation, audits, and license tracking painful to keep straight. Deduplication keeps your inventory accurate and gives you one record per real device to assign, ticket, and report on. It runs automatically as each integration syncs.

What gets deduplicated

Hardware assets: yes

Deduplication applies to hardware assets discovered by MDM and IT discovery tools:

• Microsoft Intune
• Kandji
• Jamf
• Atomicwork Discovery
• JumpCloud (coming soon)

Software and applications: no

Application records synced from your identity and device providers (Azure AD apps, Intune apps, JumpCloud, Google Workspace, Okta) are kept separate per source, by design.

There can be no reliable unique identifier for a piece of software. The same product is named differently by different sources. Versions, editions, publisher names, and localized titles all vary, so matching on name can produce wrong merges more often than right ones. Rather than guess, Atomicwork keeps each source's application inventory intact and attributed to that source. This also lets you answer questions like "which applications does Intune see that Okta doesn't?"

Cloud resources: no

Cloud assets don't need deduplication. An Azure virtual machine and a Google Compute Engine instance are genuinely different machines, not two views of one server. Each cloud provider issues its own resource identifiers inside its own account, and those identifiers never overlap between providers.

How deduplication works

Atomicwork compares hardware identifiers to deterministically match assets. The four attributes used are:

Any one of these four identifiers is enough. If an incoming record shares any one identifier with an existing asset, that's a match. This matters because sources report different subsets of identifiers.

For example, Microsoft Intune reports a MacBook with a serial number and a hardware UUID. An Atomicwork Discovery scan of the same MacBook reports only a serial number. Because a single identifier match is enough, both records collapse onto the same asset on the shared serial number.

If no match is found, the incoming record becomes a new asset. Because matching relies on exact hardware identifiers, nothing is merged on a guess. Two assets with different identifiers stay two assets, even if they share a hostname or are assigned to the same person.

On every sync, as a record's information gets enriched with more identifiers, Atomicwork automatically checks whether it matches an existing asset and merges them, so admins never have to re-run matching or clean up duplicates manually. For example, if a network scan misses a serial number on its first sync and reports it later, the record automatically merges with any existing asset that shares that serial.

Importing assets via CSV

Deduplication happens when an integration syncs. If you upload a CSV after any integration has already synced, its rows are added as new records with no matching.

Example 1: CSV first, then integration (deduplication happens)

You import a spreadsheet of 500 laptops with their serial numbers. You then connect Intune. As Intune syncs, each device it reports is checked against what you already have, matches your imported row on the serial number, and is linked to it. One asset, with Intune now listed in Asset Sources.

Example 2: Integration first, then CSV (deduplication does not happen)

You connect Intune and sync all end user devices. You then import a spreadsheet covering all purchased laptops, assigned or otherwise, and those rows are created as new assets. The import doesn't check for existing matches, so you'll end up with two records per assigned device.

Viewing assets and their details

To view the asset directory, navigate to Directory > Assets in the left navigation. Every deduplicated asset appears as one row. The Asset Sources column shows which tools are reporting it:

You can also filter assets by the source. Select one or more sources to see only assets with a contribution from those tools. For example, say you've synced assets from both Jamf and Kandji. Select only Jamf in the Asset Sources filter to see everything Jamf reports. Add a second filter, Asset Sources is not Kandji, to spot devices Jamf covers but Kandji missed. This is the fastest way to find MDM coverage gaps after a rollout.

Asset details view

Clicking on any asset opens the Asset details view. This opens in the Unified view: a single combined view built from every source reporting that asset.

For every asset, you can see the Details, Relationships, and Activity tabs.

How the Unified view is built

Think of every asset record as one form with a set of blanks: display name, operating system, serial number, RAM, location, asset tag, and so on.

Every source that reports this asset fills in the attributes it knows about. Your CSV import knew its location and asset tag. Kandji knows the operating system and RAM. A discovery scan knows when the machine was last seen on the network.

Most attributes are filled in by only one source, so there is no conflict. When two sources sync the same attribute, the value from whichever source first reported the asset is retained. If an attribute was imported via CSV and an integration later syncs it, the integration's value takes over.

Rules defining attribute values:

• Only one source syncs it → that source's value
• More than one source syncs it → the value from whichever source reported this asset first
• No source syncs it → value can be added manually

The Unified view is what the rest of Atomicwork uses too. Search, filters, reports, workflows, approvals, and Atom all operate on it. There is only ever one record to assign, link to a ticket, or report on.

Hover over any locked attribute to see which source it came from:

So if Operating system looks stale, the tooltip tells you Kandji is the tool to go and fix it in. A locked attribute with no value yet reads Synced from external source.

Source-specific views

When an asset has more than one contributing source, a source selector appears at the top of the Asset details view. Single-source and manually created assets don't have the selector.

Atomicwork stores every value each source reports, not just the value shown in the Unified view. Switching the source selector to a specific source lets you see when that source was last synced and what it reported for each attribute:

Select Kandji and the page becomes Kandji's view of this asset: only the attributes Kandji reports, with Kandji's own values, including attributes where another source won in the Unified view.

Individual source views are read-only in full. They are the record of what that tool reported, not a place to make changes. Switch back to the Unified view to edit.

The Activity tab follows the selector as well. In a source view it shows that source's activity with its icon on each entry. In the Unified view it shows all activity with no source icon. In addition, deduplication itself is recorded in the timeline, so you can see when a source was matched to the asset and when its data was merged in.

A worked example

Here's one MacBook that was reported in three ways:

• Imported via CSV in January
• Synced from Kandji in February
• Scanned by Atomicwork Discovery in March

Read the Unified view column top to bottom and you have the whole record: mostly Kandji, one attribute from Discovery, three attributes from the CSV import.

Things to note:

1. Your CSV values for Display name and Operating system were replaced. Both are attributes Kandji syncs, so Kandji owns them from the moment it connects. It reads the machine on every sync, and your January spreadsheet doesn't. Your Location, Asset tag, and Cost centre are untouched, because no tool reports those.

2. Atomicwork Discovery's older OS version does not appear in the Unified view. You see one value per attribute, not a list to pick from. Discovery's value still exists. Switch to the Discovery view if you want to see exactly what it sent.

Which attributes you can edit

Every attribute is either locked or editable, depending on whether a connected source syncs it:

• Attributes a connected source syncs are locked. The source owns them and overwrites them on every sync.
• Attributes not synced from any source are editable. You can manually update these at any time: asset tag, location, cost centre, notes, custom attributes, and manually added tags.

An attribute locks as soon as a connected source is configured to sync it, even before it sends a value. So you may see a locked attribute that's still empty. It's waiting on the source and will fill in on the next sync.

What happens when a source goes away

• If other sources still report the asset, the attributes only the departing source provided are cleared. Values other sources report, and anything you entered manually, are kept.
• If it was the only source reporting the asset, and the asset originally came from an integration, the asset is removed from your inventory along with it. There's nothing left reporting it.
• Assets you originally added yourself are always kept, whether you added them manually, by API, or by CSV. They stay even after every integration reporting them is disconnected. Your record was there first and stays.
• If a connected source stops sending an attribute it used to send, the last value it reported remains on the Unified view.

Frequently asked questions

Do I need to configure or enable anything? No. Deduplication runs automatically as each integration syncs. There are no matching rules to set up.

What happens to duplicates that already exist in my inventory? Newly synced records are matched as they arrive, so duplicates stop being created. For duplicates already in your inventory, talk to Atomicwork support about the best way to consolidate them.

Can I choose which source wins for a particular attribute? Not today. When two sources report the same attribute, the one that reported the asset first wins, automatically.

Will my manually entered data be overwritten? Only for attributes a connected source syncs. Attributes no source syncs, like asset tag, location, cost centre, notes, and your custom attributes, are never changed by a sync, which is why they stay editable in the Unified view.

Why does an asset show only one source when two tools have it? Either the second tool hasn't completed a sync yet, or the two records don't share any of the four identifiers (serial number, hardware UUID, IMEI, MEID). A scan that couldn't read the serial number is the most common reason. It usually resolves itself once that tool reports one.

Why weren't my applications deduplicated? Applications are deliberately kept separate per source, because software has no reliable unique identifier. See What gets deduplicated above.

Can I split an asset if two records were linked incorrectly? Reach out to support@atomicwork.com if you think records have been linked incorrectly. Incorrect links are unlikely, since matching requires an exact hardware identifier match.

Where to go next