Documentation / Platform glossary / Correlation ID
A correlation ID is a unique reference attached to a request and carried through every service that handles it. It turns "something failed somewhere" into a single retrievable thread, which is what makes diagnosis possible once a request touches more than one component.
The identifier is generated at the entry point — or accepted from the caller if one was supplied — and propagated with every downstream call the request causes. Each component includes it when recording activity, so records belonging to one logical operation can be gathered afterwards even though they were produced independently.
Two related identifiers are worth distinguishing. A correlation ID spans a whole logical operation, including asynchronous continuations such as a queued job triggered by the original request. A request ID identifies a single call. A long-running operation can therefore have one correlation ID and many request IDs.
The property that makes a correlation ID useful in support is that it is safe to share. It is an opaque reference containing no personal data, no tenant name, and no system detail, so a customer can quote it in a ticket without disclosing anything. This is a meaningful improvement on the common alternative, where a user pastes a screenshot or an error page containing information that should not travel by email.
Returning the identifier to the caller is what completes the mechanism. An identifier recorded internally but never surfaced cannot be cited by the person reporting the problem.
In a distributed system, time-based correlation does not scale: under load, many requests share a timestamp, and clock differences between components make ordering unreliable. An explicit identifier removes that guesswork.
It also shortens support cycles measurably. A reported symptom with a correlation ID is a lookup; the same symptom without one is an investigation.
QueryTek attaches a correlation reference to requests and returns it in responses, including error responses, so a customer can cite it and support can retrieve the corresponding activity. Log field names and pipeline structure are not published.
