Synthetic Keys in Qlik: Stop Panicking. Start Understanding.
This comes up constantly. And in the age of Qlik Answers and agentic AI, it matters more than ever.
You load a couple of tables, open the data model viewer, and there it is, a grey $Syn table staring back at you. The instinct? Kill it immediately.
That instinct will get you into trouble.
What is a synthetic key?
Qlik creates a synthetic key when two or more tables share more than one common field. Rather than allowing multiple direct associations between those tables, Qlik generates a composite key, a hidden intermediary table joining those fields together. It appears in your model as $Syn 1, $Syn 2, and so on.
It is Qlik being transparent with you. The question is whether you're listening.
Why they can be a problem
Synthetic keys aren't inherently wrong. But chained or nested synthetic keys will quietly wreck a model. Performance degrades as the associative engine works to resolve increasingly complex relationships. Debugging becomes a guessing game. And when you're building for Qlik Answers, where the AI engine needs to navigate your data model to answer natural language questions, an opaque, tangled model produces unreliable, sometimes nonsensical results.
This is the part that has changed. A messy data model used to be a developer problem. Now it is a user-facing AI problem. The engine is only as good as the structure beneath it.
Clarity in the data model is not optional anymore. It is load-bearing.
What people get wrong
Some synthetic keys are correct.
If your source data genuinely has a composite key, say OrderID + LineNumber together uniquely identify a row, then Qlik surfacing a synthetic key is telling you the truth about your data. Blindly resolving it by concatenating fields or renaming columns doesn't fix the underlying relationship. It just hides it from the model viewer and from you.
The developers who get themselves into the most trouble are the ones chasing green lights in the data model viewer without understanding why the warning appeared in the first place.
The real skill: know your data first
Before you reach for Concatenate, AutoNumber, or a field rename, ask yourself one question:
Why do these tables share multiple fields?
There are two possibilities:
1. It's a genuine composite key. The source data actually uses a combination of fields to identify rows uniquely. In this case, Qlik is correctly reflecting reality. Build the composite key explicitly, document it, and move on. Don't hide it.
2. It's a naming collision. Both tables happen to have a Date field and a Status field, but they mean entirely different things in each context. This is an accidental join. Resolve it properly by renaming or qualifying the fields so the model reflects what the data actually means.
One of these requires a data modelling decision. The other requires a tidy-up. They are not the same problem, and the solution to one is wrong for the other.
Why this matters even more for Qlik Answers
When a user asks a natural language question in Qlik Answers, the AI needs to traverse your data model to find the right tables, fields, and relationships to construct an answer. Synthetic keys introduce ambiguity at exactly the point where clarity is most critical.
A well-structured star or snowflake schema, with deliberate single-field associations and clearly named dimensions and facts, gives the engine the best possible foundation. It can focus on answering the question, rather than first solving the puzzle of how your tables connect.
If you are building for agentic use cases, treat your data model as an API. The AI is a consumer of it. Design accordingly.
The rule
Understand first. Resolve second. Never rename a field just to make the warning go away.
Know your data. Everything else follows from that.
