Normalising IDs Across Systems: Map source and destination IDs with explicit crosswalks; Preserve original formatting; only normalise where contracts allow; Use idempotency keys to prevent duplicates on retries
Image: Workflow Automation Guide

Data Mapping

Part of Workflow data mapping

Normalising identifiers across connected applications

Two applications can refer to the same customer, order or case with different identifiers.

Desk Integration · · 3 min read

Two applications can refer to the same customer, order or case with different identifiers. A workflow that assumes the IDs are interchangeable may update the wrong record or create duplicates. Normalising identifiers means defining which ID belongs to which system and how the workflow resolves one into another.

Classify each identifier

List the source system ID, destination system ID, any customer-facing reference and the event ID. Give each a separate field name in the mapping. An order number on a receipt may be meaningful to people but not unique across stores or years; a database ID may be unique only inside one tenant. Record the scope and stability of each value before using it as a lookup key.

Do not remove leading zeros, change case or strip punctuation merely to make IDs look alike. Those characters may be significant. If a system treats an identifier case-insensitively, document that rule and apply it consistently. Normalise formatting only where the source and destination contracts support the same identity.

Identifier Stability and Scope Across Systems

Source System ID
Unique within tenant; stable over time
Destination System ID
Generated on creation; unique across system
Customer-Facing Reference (e.g. Order Number)
May not be unique across stores or years; case-sensitive
Event ID
Unique per event; used for idempotency

Maintain an explicit crosswalk

When an object is first created in the destination, store the returned destination ID alongside the source ID and tenant or channel. On later events, look up that crosswalk rather than searching by a mutable name or email.

Define what happens when the mapping is missing, points to a deleted record or produces more than one result. Those should be handled as exceptions, not guessed into a match.

A hypothetical example: a customer changes their email address after their first order. If the integration uses email as the sole identity key, the next event may create a second customer. A stable source ID and recorded destination ID allow the workflow to update the same record, assuming the provider's contract permits it.

Safe Crosswalk Maintenance Workflow

  1. Create new object in destinationStore source ID, destination ID, tenant/channel
  2. On subsequent eventsLookup crosswalk instead of using mutable fields
  3. Handle missing or invalid mappingsRaise exception; do not guess match
  4. Update record if permitted by contractUse stable IDs to maintain entity identity

Make retries and corrections safe

Keep event identity separate from entity identity. The same customer can produce many events; the same event may be delivered again after a timeout.

Use an agreed idempotency strategy for operations that create records so a retry does not create a duplicate. A correlation ID can trace the route through services, while a processed-event record or provider-supported idempotency key controls repeat processing.

Test cross-system mapping with a new object, an existing object, a changed display reference, an unknown ID and a repeated event. Review the destination state after each case. The objective is a reproducible identity decision, not a plausible-looking string.

Testing Data Normalisation Scenarios

  • Test with a new objectVerify correct crosswalk creation
  • Test with an existing objectEnsure update occurs on correct record
  • Test with changed display reference (e.g. email)Confirm identity preserved despite change
  • Test with unknown IDValidate exception handling
  • Test with repeated eventEnsure no duplicate records created

More from Data Mapping