Accept an existing trusted correlation value or create one at the integration boundary.
Enterprise Messaging · Message Construction
Correlation Identifier
Carry a stable identifier that lets the receiver match a reply or related message to the originating request and trace a distributed interaction.
How does a requestor that has received a reply know which request this is the reply for?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Correlation Identifier works
A stable identifier travels across synchronous and asynchronous boundaries so distributed work can be reconstructed as one integration conversation.
Related operations
Propagate correlation
Traceable conversation
Propagate the same identifier through headers, message properties, workflow state and downstream telemetry.
Log it together with platform trace identifiers so operators can query one value and reconstruct the complete path.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use a stable correlation identifier to connect related requests, messages and downstream operations into one traceable integration conversation.
- One business transaction crosses process, queue, API or workflow boundaries.
- A request produces later asynchronous work or multiple downstream calls.
- Operators need to reconstruct an end-to-end path from distributed telemetry.
- A platform trace identifier already provides the exact business-level correlation semantics you need and is propagated everywhere.
- A new identifier is generated at every hop, destroying continuity instead of adding it.
- The chosen value contains sensitive business data that should not be copied into logs and headers.
Correlation resetHigh impact
Generating a new identifier at intermediate hops prevents end-to-end investigation.
Multiple competing IDsReview
Using several undocumented correlation headers makes support teams unsure which value is authoritative.
Missing propagationHigh impact
A good identifier is useless if one connector, mapper or asynchronous hop drops it.
- Accept an existing trusted correlation value when appropriate, otherwise create one at the integration boundary and propagate it consistently.
- Keep business correlation separate from platform trace identifiers when their lifecycles differ, but log both together.
- Use message/application properties for brokered messaging rather than embedding operational identifiers only inside opaque payloads.
What this pattern helps you decide
Carry a stable identifier that lets the receiver match a reply or related message to the originating request and trace a distributed interaction.
Where is correlation first created and which value is authoritative?
Does every synchronous and asynchronous hop preserve it?
Can an operator search one value and reconstruct the full integration path?
Where you may see it
- Service Bus CorrelationId
- x-correlation-id header
- BizTalk correlation sets
How the analyzers can surface it
- APIM correlation header
- BizTalk context properties and filters
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
Source, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.