Qlik Answers review: What we learned from real-world testing

What we learned testing Qlik Answers on a live customer dashboard, August 2026.

Over the past few months we tested Qlik Answers on a dashboard of one of our customers. We had already run plenty of tests on small, simple apps. Those results were promising and the user experience was good, but small apps are not where analytics gets difficult. So we moved to a real use case: a production sales model, with the data quality issues and modelling choices that come with it. 

AI tooling moves fast, so treat this as a snapshot. This review describes how Qlik Answers behaved in July 2026. The agentic experience was not brand new by then. Qlik took it generally available in February 2026 and expanded the agent set at Qlik Connect in April. What we cannot tell from the outside is which underlying model updates landed in between. 

Why Qlik Answers and not Claude, ChatGPT or Gemini 

Together with the customer we set two hard requirements: EU-only, and no training on our data. That is worth spelling out, because the agentic Qlik Answers experience does not stay inside your tenant region by default. You have to opt in to cross-region inference, which lets Qlik send the inference request to the AWS region where the model is available. For tenants in the EU, Qlik states that an EU cross-region inference profile is always selected, so the request stays within EU AWS regions, and that enabling it does not give Qlik or AWS access to your data.  On the training question the documentation is explicit: Qlik states it does not use customer data to train any AI model outside the customer’s own tenant. 

For the other models we could not get that same guarantee, so the choice was made for us before we compared a single answer. 

So how does Qlik Answers compare?

We did run the same questions on our own test dashboards with Claude, ChatGPT and Gemini. In our opinion those answers were better, with one caveat we ran into straight away: on the small Haiku model Claude got it wrong, and only on Opus was it clearly ahead of Qlik Answers. The frontier models bring a wider set of skills to the problem, which simply gives them more to work with.

That is an observation on test data rather than a benchmark, and it did not change the decision here: the EU requirement was not negotiable.

This is not necessarily an either-or choice, though. Qlik also exposes its analytics capabilities through the Qlik MCP Server, which means you can use clients such as Claude or ChatGPT to work with governed Qlik data and master items. In that setup, the external model does the reasoning while Qlik provides governed access to the data. The trade-off is that data passed to the model is then processed under that provider’s policies, so for this customer it did not solve the EU-only requirement.

The test dashboard we used is called ThermoThuis, a demo application we built with public data for all addresses in Aalsmeer, where our office is located. It brings together information such as energy labels, WOZ property values and other housing characteristics to help identify where sustainability investments are likely to have the greatest impact and return.

Below you can see what Qlik Answers and Claude made of the same prompts.  
 
My first reaction was that Qlik Answers had won this round, because Claude on Haiku returned the wrong answer. Then we switched Claude to Opus, and honestly, I found Claude the stronger of the two. Its charts made the point, and the counts differ slightly because Qlik Answers picked a different measure than Claude. The visuals from the second prompt are where that gap is clearest. 

Prompt: Visualize some key trends

Qlik Answers:  

Prompt: Can you see a relation between year built and energy labels?

The model matters, the context decides. 

While we were setting this up, we read several sources making the same point: context does more for accuracy than model choice does. The table below comes from one of them. The same question was asked at every iteration, and the only thing that changed was how much context the model had to work with.

Iteration	What changed	SQL generation	Accuracy
1	Raw tables	0%	0%
2	Modelled table, no context	38.5%	0%
3	Column descriptions	100%	15%
4	Business rules and instructions	100%	77%
5-6	Metrics, verified queries, eval refinement	100%	92%

Source: Datacult, The Boring Work That Makes AI Analytics Actually Work. 

Accuracy climbs from 0% to 92% without ever swapping the model. In our experience that pattern holds outside the lab too: the model matters, but the context decides. Give a frontier model a dashboard without context and it will still hand you the wrong number, confidently.

This review is our attempt to test that on a real dashboard. First we walk through the five things we changed to make the answers reliable. Then we look at where it runs into its limits today, and what would take it further: context organized per analysis rather than per dashboard.

The model we tested on

Step 1: Fill the logical model 

The first thing we did was make the app available to Qlik Answers so it could be indexed. That went fine. A short wait, and we could start asking questions. 

The answers were wrong. Qlik Answers was inventing its own measures instead of using ours, which on a concatenated fact table produces numbers that look plausible and are not. 

The cause turned out to be the logical model. Qlik Answers reads the logical model and reasons over it, and our master measures were not in there. So it filled the gap itself. That is consistent with what Qlik documents. Master measures and dimensions are evaluated before raw fields, and items defined by the developer count as the trusted source. But that only applies to master items that actually sit in the logical model. Ours did not, so there was nothing to respect and it wrote its own expression instead. We added the measures to the logical model, and Qlik Answers immediately started answering with the master measures instead. 

View of the logical model 

Step 2: Describe your master measures 

In step 1 our questions were phrased to steer Qlik Answers towards a specific master measure. That works for a test, but it is not how anyone actually uses a dashboard. You want a colleague in sales to be able to ask a question in their own words and get the right answer. 

That means better context. Three things in particular: synonyms for the terms people actually use, an explanation of what each measure means, and per measure a note on when it should be used and when it should not. 

Following Qlik’s own guidance on writing descriptions, we went through every master measure and filled the description field with its real business meaning rather than a restatement of the expression. We used an LLM for the first pass: we handed it our naming conventions and let it draft a description for every master measure, then checked each one against what we actually meant. In the same round we marked which measures are technical building blocks for the underlying calculation and which ones end users are supposed to reach for. The model can phrase it, but only we know which measure is the one people should use. 

The answers got better. Accuracy went up, and Qlik Answers became able to map a question to the right master measure on its own. Not perfectly, but the difference between a filled description field and an empty one is large enough that we would not skip this step again. 

Step 3: Read the reasoning 

Next we asked whether Customer A had ordered more or less than in the same period last year. After a short wait we got visualizations based on the number of orders. We followed up by asking for the same comparison in euros. 

The reasoning Qlik Answers exposed for that follow-up looked like this. Customer names, field names and figures have been replaced to anonymise our customer’s data, but the structure of the output is untouched: 

It works. But it picked Gross COST PRICE, and we expected Gross Amount for this question. Interesting detail: Gross Amount is not the measure that came back in the reasoning at all.  

The generated measure looked like this:

{<[Customer]={'123456 - DO NOT USE - CUSTOMER A','324567 - CUSTOMER A','456789 - STOCK ORDER CUSTOMER A'},[Date Order]={">=$(=01-01-26 12:00:00[.000000])<=$(=30-06-26 12:00:00[.000000])"}>} [Gross COST PRICE] 

Look at that customer selection. It includes an account literally named DO NOT USE. No orders sit under it, so the number is still correct, but the AI had no way of knowing it should be excluded. Two options: explain in the context that Customer Status must be filtered to active customers only, or remove the account from the dashboard entirely so nobody, human or machine, can pick it by accident. In our experience the second option is the one that actually sticks. 

The date filter is worth a second look too. It filtered on [Date Order], while the model also exposes a plain Date field, and Date is the more logical one to filter a period on. Same root cause as the customer selection: nothing in the context told it which of the two to prefer, so it picked the one whose name looked closest to the question. Two fields that sound alike and behave differently are exactly the kind of thing your colleagues learn once and never write down. 

The knowledge gap is in the context

This is where the gap sits. An experienced user pulls the right answer out of a dashboard because they know which fields to avoid. That knowledge lives in their head, not in the app. An AI only has what is written down. Everything a colleague knows through experience has to become explicit context, or it does not exist. 

It helps a lot that Qlik Answers shows this level of detail. You can see how an answer was built and, more importantly, where to sharpen the context to get a better one. An answer without visible reasoning would have looked perfectly fine here. 

So read the reasoning, and read Qlik’s own explanation of what each agent in the chain does. It is worth the twenty minutes. The Semantic Search Agent picks the master items it thinks your question needs, the Data Analyst Agent turns those into an analysis package, and master measures and dimensions are evaluated before raw fields. Once you know that, the reasoning output stops being a log and becomes a diagnostic. If it reached for the wrong measure, the problem is your description, not the question. Every improvement in the rest of this article came out of reading that output and working backwards to the context that caused it. 

Reasoning of Qlik Answers. Key information has been removed. We keep a set of measures ending in TOTAL for use in share measures: the same calculation as the regular measure, but with TOTAL in the expression. In this reasoning one of them scores high on similarity, which is exactly why it pays to check that only the measures the AI should use actually are exposed in the logical model.  

Step 4: Ask the question a business user would ask 

By this point the mechanics were in place. The real test is whether someone outside the BI team can get an answer. We tried a genuine analytical question: 

“Jackets repeat across seasons on Article Name. A given jacket name appears in SEASON 25 and in SEASON 24, for example. Can you analyse this and work out which jackets will perform best in SEASON 26? Best means highest growth. Please filter on [Article Season] <> CERTAIN VALUE. Relevant fields: Article BrandGroup, the brand of the season. Season Year, the year of the season. Block, the block within the season.” 

The results were good. We got a list of jackets ranked on growth, and a second list built the same way. 

Now look at how much we had to put into that prompt. It carries a lot of developer knowledge and field-level detail. It is also shorter than we wanted it to be: Qlik Answers caps a question at 500 characters, and we sat there cutting words to get under it. There was more we would have explained if there had been room. If you have to know the field names before you can ask anything, and then edit yourself down to fit the box, the tool is not doing its job yet. So that became the next step: stop relying on the person asking to know the model, and describe the dimensions the way we had described the measures. 

Step 5: Describe your master dimensions 

Same treatment as the measures. We described every dimension, pulled the raw fields from the data model out of the logical model, and left only the master dimensions exposed. That forces Qlik Answers to work with the dimensions and measures we want it to use, and keeps everything else hidden. It also closed the Date Order gap from step 3. With only the master date dimension left exposed, there is no near-identical raw field for it to reach for by mistake, so we did not have to write a description explaining which of the two to prefer. Removing the wrong option turned out to be cheaper than describing it. 

There is a rule of thumb here, and it is more mechanical than it sounds.

• Hide the key fields
• Hide the fields you only use inside measures
• Hide the flag fields

Leave the dimension fields visible, because those are what Qlik Answers needs to slice on. Qlik’s preparation guide points at the same lever: set those fields to Hidden under Visibility in the logical model, or prefix them with % in the load script so they hide automatically. 

This costs your end users nothing. The logical model governs what Qlik Answers is allowed to see, not what someone can select and filter on in the dashboard. Hiding a field there does not take it away from anybody. 

The answers improved again, and it stopped reaching for raw fields. This is the point where we would say the setup was genuinely usable: with enough context work, and a question written by someone who knows the model, Qlik Answers gives useful answers. Neither of those conditions is something you can expect from a business user on day one. 

Room for improvement: the visualizations 

This is where Qlik Answers still has the most ground to make up. Picking the right chart for the story you are telling is hard, and we can say that from years of building them by hand. During testing we saw plenty of visualizations where we questioned whether they made the point at all. 

Take the chart below. It came back after this question: 

“I want to see the key trends for Article Season > CURRENT and PREVIOUS. I want the differences per article category. Use the Sales EDI measure, specifically Sales EDI Qty and Sales EDI Amount.” 

Looking at the result, there are two choices we would not recommend regarding the visual: 

• Putting the amounts in a single column. You lose every basis for comparison that way. 

• A combo chart. We can argue about those in general, but putting Qty on the secondary axis and then also putting it in the bars does not make it better. 

Figure 1: the chart as Qlik Answers generated it, labels and values removed to anonymise our customer’s data  

To be fair: you can name the chart type in the question and Qlik Answers will build what you asked for. So this is not a complaint about what it can do, it is a comment about what it chooses. The default is where the problem sits, and the default is what a business user gets, because a business user typically does not know to ask for a grouped bar chart. 

With more prompting we did get to the right measure and could pull the right tables out. The honest conclusion: clicking through the dashboard would have been faster. 

Room for improvement: nowhere to put analysis knowledge 

At the same time, we cannot fit everything into a prompt. We have industry-specific constructs that we tried to explain to Qlik Answers and could not. To use a dashboard properly, an AI has to be taught how that dashboard works. This is a broader semantic-layer problem: AI needs more than access to fields and measures, it needs explicit business meaning and context. We wrote more about why the semantic layer is becoming an interface for AI here.

One example: we built a solution where selecting a value in an island table changes a variable, and that variable decides whether quantities are shown packed or unpacked. We have not been able to explain that to Qlik Answers. A second one: filtering to real articles only, leaving ledger and promotional articles out until you actually need them in the analysis. That did not land either. Default filters matter in the same way when you have several calendars in one dashboard. 

We also tried pointing Qlik Answers at a default bookmark, so you at least know it starts from the right point. In our tests it did not pick the bookmark up. 

For end users that separation already exists in the dashboard. We enforce it with separate sheets, each with its own filters, so a returns analysis cannot be run with the settings that belong to a pre-order. Qlik Answers has no equivalent. Every analysis draws on the same undifferentiated context. 

What we want is a short AI skill instruction: how certain steps and analyses work, which fields to use, what a correct answer looks like. And not one per dashboard, but one per analysis. A returns analysis runs on the same dashboard as a pre-order or a re-order analysis, and all three need different instructions: different default filters, different measures, a different idea of what a correct answer looks like. That is missing, and without it a user cannot reliably get good answers. 

The verdict 

So how do you get correct and consistent answers out of Qlik Answers?

Everything that worked for us came down to writing down what people already knew: measures in the logical model, descriptions on measures and dimensions, and default filters that put every question on the same footing. That last one matters more than it sounds, because it lets an end user check an answer against the dashboard they already use. Without that check, they will not trust it. 

What is missing is a place to put the rest. We want one skill instruction per analysis, not per dashboard: the standard filters, the measures that matter, how the packed and unpacked logic works, which article types to leave out. A returns analysis and a re-order analysis sit on the same model and answer to different rules. Right now that knowledge either goes into every single prompt or it goes nowhere. Bookmarks would have been a workaround, but they did not get picked up in our tests. 

That brings us back to the table at the top of this article. Accuracy went from 0% to 92% there without changing the model once, and our experience matches it: every improvement we got came from better context, not from a better engine. So we stand by the point, in its sharper form: the model matters, but the context decides.

The same principle applies beyond Qlik Answers. Reliable AI analytics starts with the data, metadata and context underneath it. We explore that broader data foundation for AI analytics here.

Take that further than this one tool. Whether you start asking AI questions next quarter or decide never to, the work in front of you is the same: get your data quality in order and write down the context that currently only lives in people’s heads. Every model that arrives after this one will need exactly that, and it is not wasted effort if you never point an AI at it, because it is the same documentation your own colleagues have been missing for years. In our experience this is the part organizations postpone, and it is the part that determines whether any of this works.

Want to see what Qlik Answers can do with your own environment?
We can help you assess your Qlik model, logical model, measures and semantic context, and identify what needs to change to make AI-assisted analytics more reliable.

> Talk to our Qlik consultants

Where Qlik Answers still falls short?

But we should be equally honest about the other half. If what we tested here had been the state of things two years ago, we would have been impressed. And we were not catching a first release early. Measured against what other models do today, and how they combine skills, it falls short. The reasoning it exposes is genuinely good, better than most tools give you, and it is the reason we could debug our own context at all. The visualization choices are not there yet, and neither is the ability to teach it how a specific dashboard works. 

Would I recommend it?

If your data has to stay in the EU, Qlik Answers is a reasonable choice and we certainly expect that it will get better. But do not buy it expecting the context work to disappear. That work is the job. The tool just makes it very obvious whether you did it.