Two objects have the same ID

Examples are fictional local conventions. Unless another location is shown, the scope is DC01 / H1. Keep that scope with shortened identifiers.

When to use

Use this guide for repeated physical labels or duplicate search results. Keep the disputed identifier in a collision register until the object-to-record relationship is resolved.

ServiceNow separates rules that identify records from rules controlling which sources may update their attributes. That distinction is useful when deciding whether a collision came from duplicate objects or conflicting records. This guide's physical-label workflow is an editorial application. ServiceNow identification and reconciliation

What to gather

Collect the complete scoped IDs, record references, visible physical identifiers, recent import or change history, and the naming-policy owner.

Method

Open one collision entry for each disputed scoped ID. Preserve the exact spelling of every observed value; use normalized copies only for comparison.
Compare the physical evidence and record histories. Classify the issue as one object with two records, two objects with one label, or an unresolved identity.
Ask the record owner to decide which record and identifier remain authoritative. Reserve any replacement ID through the normal issuance process before preparing labels.
Prepare a crosswalk from old references to the approved result. Include dependent work orders, connection schedules, test records, and saved reports that require correction.
Complete authorized label and record corrections together. Search the current inventory again and retain the collision history so an old import cannot silently recreate it.

Classify the collision before deciding what to change

A duplicate search result is a symptom, not a diagnosis. Begin by separating three questions: how many physical objects have been observed, how many records describe them, and how many distinct identifiers appear on those objects. Two records can describe one asset. Two assets can carry one duplicated sticker. One asset can carry a current label and an old alias. Each case needs a different correction.

Check scope before declaring a collision. The same short rack or cable number may be permitted in separate halls under the site's policy. Compare the complete scoped values in the records and in the work context. If a report removed the hall column, repairing that report may resolve the apparent duplication without relabeling anything. If the complete issued ID is duplicated inside its required uniqueness boundary, continue with a collision case.

Also compare the original strings with the displayed search values. Leading zeros, punctuation, or case may have been changed during import or export. Preserve both the source value and the transformed value so the owner can identify where the difference occurred. A normalization rule is useful for finding candidates; it does not establish that the candidates are the same object.

If the physical evidence is incomplete, classify the case as unresolved. Do not turn an uncertain inventory comparison into a destructive record merge. State what observation or authoritative history is missing and which role can obtain it.

Build an evidence set that distinguishes the objects

Give the collision case its own reference so the investigation does not depend on either disputed record remaining active. For each candidate, capture the unchanged visible identifier, complete location context, distinguishing physical reference, record key, and observation date. Use only evidence that the site permits you to collect. A restricted photo can be replaced by an approved observation record if that record still explains what was compared.

Record where each fact came from. A serial copied from the same disputed database is not an independent physical observation. A recent work order may explain why a value changed, but it may describe a planned move rather than a completed one. Identify which statements were observed, which were supplied by a record owner, and which remain historical clues.

For cables, endpoint relationships can distinguish candidates when supported by the approved identification process. For assets, a readable manufacturer reference or another controlled identifying record may help. The evidence appropriate to one object class should not be assumed sufficient for another. Describe why the selected evidence distinguishes these particular candidates.

Where a location has been reused, compare the dates of the observations and events. Two records at one rack position may describe successive occupants rather than one duplicated asset. A current location is a useful search clue, but it is not a durable physical identity.

Choose the correction branch

For two physical objects with one issued label value, request an allocation decision. The owner identifies which object, if either, retains that value and reserves a replacement for the other. Base the decision on issuance history and the local policy. “First in the spreadsheet” and “newest photo” are not allocation rules. Prepare the crosswalk before producing replacement labels.

For one physical object with two records, route the record correction through the inventory system's approved process. List the relationships that each record carries: work orders, connection references, ownership information, tests, or location history. The retained record must preserve the relationships that still belong to the object. The exact merge, redirect, or retirement operation depends on the system and its permissions; this guide does not prescribe database commands.

For one object with two physical identifiers, establish which is current under the policy. The second value may be a manufacturer reference, a customer tag, or a historical internal identity rather than an accidental duplicate. Keep distinct identifier types in distinct fields. If an obsolete internal tag must be removed or replaced, retain its history and complete that physical work through the applicable process.

For an apparent duplicate caused by report formatting, repair the display or transformation and repeat the lookup. Record the cause so the same shortened export is not mistaken for an issuance failure next month.

Trace the dependencies before making the change

Start with the systems and documents that actually reference the disputed value. Ask the work-order owner whether open jobs use it. Ask the connection-record owner whether either candidate appears in endpoint schedules. Check whether a test result or handoff register uses the record key, the physical label, or both. These dependencies determine what must move with a correction.

Create one outcome for each affected reference: corrected to the retained identity, redirected through an approved alias, retained as historical evidence, or unresolved with an owner. A long list of source documents is not enough if nobody can tell whether their references were repaired. Where access belongs to another team, record that team's completion evidence instead of claiming the update on its behalf.

Control old exports and print files as part of the correction. Identify the file or integration that created the duplicate and ask its owner how it will stop recreating the same value. A corrected active record can be overwritten later if an unchanged source still publishes the disputed identity. The review should establish which source is allowed to update the relevant fields and how this case is represented there.

Keep the physical-label change and record update connected to the same decision. If they occur at different times, state the interim relationship and the remaining work. “Record corrected” and “label replaced” are separate facts.

Scenario: a duplicate sticker on two newly received assets

In a separate fictional case, DC01 / H1 receives two assets carrying AST-G02-301. The first is observed at DC01/H1/R301/U10 with serial DEMO-G02-S301; the second is at DC01/H1/R302/U10 with serial DEMO-G02-S302. Their receiving records show different physical units. The collision is therefore two assets with one internal label value, not two records of the same unit.

The investigator opens case DUP-G02-301 and preserves both receiving entries. The allocation owner checks the issued register and decides that the first unit retains AST-G02-301. AST-G02-302 is reserved and then issued to the second unit under the fictional policy. The investigator records this as an owner decision rather than deriving it from the order of the observations.

The correction pack includes a replacement proof for the second asset, its inventory record key, the receiving checklist, and the open installation work order. The printer owner finds that the second sticker was produced from a copied row whose identity field had not changed. That stale print row is removed from the active batch according to the team's normal controls.

After authorized replacement, the reviewer checks each physical asset against its serial and retained or replacement identity. Searching the two current IDs returns the intended two assets. Searching the former duplicated value also exposes the collision history so an old work order is not silently assigned to the wrong unit. Closure records the physical correction, dependent work-order update, and print-source repair.

Handle legacy inventories and new installations differently

In an existing facility, the most difficult dependencies may be historical names in active documents. Preserve the route from those documents to the correct current object. Avoid a bulk cleanup that discards old keys before the service teams have resolved their open references. Use bounded cases or groups whose physical evidence and dependencies can actually be reviewed.

In a new installation, inspect the issuing and printing workflow when several collisions share a batch. The common cause may be a copied reservation list, a reprint that was not accounted for, or separate subcontractor ranges that overlap. Resolve the affected physical items individually while correcting the process that produced them. A process correction does not prove that every existing sticker was repaired.

When multiple parties own their own tags, define the relationship between identifier types rather than forcing them into one field. The facility's asset identity, the customer's tag, and a manufacturer's serial can coexist if the record identifies which is which. A repeated value across different identifier types is not automatically a collision under the same allocation policy.

Prove the correction survived its normal inputs

Repeat the lookup after the authorized changes, using both the current issued IDs and the historical disputed value. Confirm that current searches select the intended objects and that history remains interpretable. Review the relevant source export or integration result with its owner when that input was part of the cause. Do not declare prevention complete merely because a manual edit currently looks right.

Have a reviewer who did not choose the retained record follow the crosswalk. Give them an old reference and ask which physical object it now identifies. If they must ask the investigator for an unwritten explanation, the case needs a clearer dependency outcome or alias rule.

Close only the work that the evidence supports. A case can have resolved identity but pending physical replacement, or completed relabeling but an unresolved external record. Describe those states separately, name the remaining owner, and keep the case available to the teams whose work could still select the wrong object.

Worked example

Fictional investigation: matching label text does not establish that these are the same cable.

SCOPE DC01 / H1 / CABLES
Observed ID   Record   Physical endpoints
CAB-0042      REC-A    R014/PP01/07 -> R021/PP02/19
CAB-0042      REC-B    R018/PP01/03 -> R022/PP01/09
Proposed result: REC-A retains CAB-0042
                 REC-B receives reserved CAB-0098

A real replacement needs the site's allocation decision; CAB-0098 is reserved only within this fictional example.

Common mistakes

Merging records because their names match.
Removing the old reference before dependent records are traced.
Treating a replacement ID as issued because it appears in a draft.

Verification

Physical objects and records are distinguished.
Replacement IDs are reserved without collisions.
The decision has a named owner.
Dependent references have a correction outcome.
A fresh lookup resolves each issued scoped ID once.

Worksheet: Identifier collision register

Fields define one row; sample values are fictional. Leave working-sheet dates blank until their recorded event occurs. Sample status: Example only.

Field	Definition	Filled example
Scope	Site and object class being compared.	DC01/H1 / cables
Observed ID	Unchanged disputed label text.	CAB-0042
Record A	First record and distinguishing evidence.	REC-A; R014 to R021
Record B	Second record and distinguishing evidence.	REC-B; R018 to R022
Classification	Physical or record collision finding.	Two cables; one ID
Decision	Proposed resolution and retained identity.	REC-A retains existing ID
Replacement ID	Reserved identifier for the other object.	CAB-0098; fictional reservation
Owner	Role accountable for reconciliation.	Inventory steward
Evidence	References supporting the distinction.	DEMO-COLLISION-02
Verifier	Person checking the resolved lookup.	Example reviewer
Verification date	Date the resolution was checked.	2026-09-12
Status	Current review state.	Example only

Frequently asked questions

Can we resolve this by adding a site prefix?

Only if the approved scope and dependent systems support that change. A prefix cannot resolve two different objects within the same scope by itself.

What if we cannot prove which record is correct?

Keep both observations, mark the identity unresolved, and assign an evidence-gathering action. Do not invent a merge decision.

Should the newer record always survive?

No. A newer record can be a duplicate import with less useful history. Ask the record owner to decide based on the system's identification rules, relationship history, and verified physical identity. Preserve the reasoning with the collision case.

Can we change the duplicate by adding a suffix?

Only after the allocation owner confirms that the proposed value fits the local policy and is available in the required scope. A convenient suffix typed into a worksheet is a proposal, not an issued replacement. Check dependent systems before releasing its label.

What if the same duplicate returns after correction?

Reopen the source or transformation question. Compare the returning record with the preserved case evidence and identify which import, integration, or print source republished it. Keep current identity decisions intact while the responsible owner repairs that input; repeated relabeling alone will not explain the recurrence.

More worked label examples

Two additional ways to apply this guide. Keep the exact identifiers and relationships consistent with your own approved records.

GUIDE 02 / EXAMPLE 1

Two physical assets carry the same sticker

Use separate physical observations and serial references to document an actual label collision before recording the approved correction.

SCOPE: DC01 / H1; collision case DUP-G02-101
BEFORE
R101 / U10: [AST-G02-101]  serial DEMO-G02-A101
R102 / U10: [AST-G02-101]  serial DEMO-G02-B101
             SAME TEXT         DIFFERENT ASSETS

ILLUSTRATIVE OWNER DECISION: retain first; reissue second
AFTER LABEL FACES
+-------------------+  +-------------------+
| AST-G02-101       |  | AST-G02-102       |
| DC01-H1-R101 U10  |  | DC01-H1-R102 U10  |
+-------------------+  +-------------------+
RECORD PAIRS
DEMO-G02-A101 -> AST-G02-101 -> R101/U10
DEMO-G02-B101 -> AST-G02-102 -> R102/U10
Old ID on second asset -> collision history, not active ID

FICTIONAL EXAMPLE / NOT TO SCALE

Use your reliable distinguishing evidence, such as an observed manufacturer serial or another controlled asset reference. Location alone is insufficient if either asset may have moved.
Have the identifier owner decide which issued ID survives. Link work orders and dependent records to the correct physical asset before retiring the duplicate sticker value.

GUIDE 02 / EXAMPLE 2

One asset has two database records

This case resolves duplicate records for one observed asset without inventing a second physical identity.

SCOPE: DC01 / H1; collision case DUP-G02-201
OBSERVED LABEL FACE
+----------------------+
| AST-G02-201          |
| DC01-H1-R201 / U22   |
+----------------------+
OBSERVED SERIAL: DEMO-G02-S201

RECORD REC-G02-201 ----+
ID AST-G02-201        +--> One observed physical asset
RECORD REC-G02-202 ----+    serial DEMO-G02-S201
ID AST-G02-201

OWNER DECISION EXAMPLE
REC-G02-201 = retained record
REC-G02-202 = duplicate; redirect relationships to retained
Physical label = AST-G02-201; no reissue required here