A colleague was making a change in a customer’s Qlik Cloud environment. Due to an error in the load script, the data was not loaded incrementally but was reloaded in full into another space. As a result, Data for Analysis usage rose to 54.27 GB, while the customer has a capacity of 50 GB.

We discovered the error and corrected it within about two hours. But that was not the end of the matter. Even a brief capacity overage can result in overage charges in Qlik Cloud.

We have been aware of this risk for some time and actively monitor our customers’ capacity usage. Even so, we could not prevent this overage.

In this case, we will cover the bill. The mistake was ours, and the cost is relatively modest. But what if the overage had not been 5 GB, but 50 or even hundreds of GB?

How does Qlik Cloud overage work?

With Qlik Cloud’s capacity-based subscriptions, you pay for a certain amount of Data for Analysis. If you exceed that amount, your environment continues to operate. The additional capacity is billed afterward.

Qlik calculates this based on the highest capacity measurement of the month. Whether you exceed your capacity for two hours or the entire month makes no difference to that month’s bill.

Not everyone may be aware of how high that bill can be.

According to the public price list, Qlik Cloud Premium starts at $2,750 per month, including 50 GB of Data for Analysis. AWS Marketplace also lists an overage rate of $344 per 5 GB.

Based on that public rate, we can make the following calculation:

These are indicative calculations based on the public AWS Marketplace price. Actual costs depend on the applicable agreement.

Why the last 450 GB? Because Qlik allows you to use up to ten times your purchased capacity. With a 50 GB subscription, that means a maximum of 500 GB in total, of which 450 GB is overage.

That means a theoretical bill of more than $30,000 for a single month at the minimum capacity of a Qlik Cloud Premium subscription.

Why can’t customers set their own limit?

What I miss most in the current model is the ability to set your own limit on capacity consumption.

Qlik Cloud Starter has a hard capacity limit: once it’s used up, that’s it. With Standard and Premium, you can consume up to ten times your purchased capacity. So mechanisms to limit consumption already exist, but customers cannot set that limit themselves.

During a Techspert Talks session on capacity monitoring in May 2026, Qlik confirmed that customers cannot set their own limits on Data for Analysis consumption. We also raised this question directly with Qlik and received the same confirmation.

I understand the reasoning behind overage. You want to prevent a production environment from unexpectedly stopping because it has reached a capacity limit. But not every organization will want to make the same trade-off. One customer may prefer maximum continuity, while another would rather limit the risk of unexpected costs.

Customers should be able to make that choice themselves.

What can you do yourself?

Of course, you can take steps yourself to limit the risk.

At Bitmetric, we have been taking this into account for some time. For example, we are cautious about recommending a move to capacity-based subscriptions when data volume is not sufficiently predictable or manageable.

Qlik also provides options for monitoring your capacity consumption. According to the Qlik Cloud Administrator Playbook, the Service Account Owner receives warnings when consumption reaches 80%, 90%, and 100% of the purchased capacity. However, neither the thresholds nor the recipients of these notifications can be configured.

This is an important limitation. The Service Account Owner is not necessarily the person responsible for technical administration. It might be someone in management who cannot immediately assess the impact of a warning or take the necessary action. Especially when consumption increases rapidly, these alerts need to reach the right people without delay.

For more detailed insights, Qlik provides the Detailed Consumption Reports. These show how your capacity is being used and which processes contribute to that consumption. With Qlik Automate, you can also have the reports distributed automatically.

In addition, we use CloudScan for Qlik to monitor how our customers’ capacity consumption develops. We analyze the growth trend and issue a warning when a tenant is expected to reach its capacity limit. This allows you to take timely action.

But monitoring has its limitations. The capacity information provided by Qlik is not updated in real time. Moreover, consumption can increase so rapidly during a reload that warning thresholds are crossed before anyone has a chance to intervene. By the time you detect an unexpected overage, the costs may already have been incurred.

An overage does not necessarily have to result from an error, either. Many Qlik environments use incremental loads to limit data consumption. But sometimes a full reload is necessary, for example after a change to the data model or a correction to historical data. Because loaded data also counts toward Data for Analysis, a routine maintenance task like this can be enough to cause a capacity overage.

So you can develop, test, and monitor carefully, but that will not prevent every incident.

And who pays the bill?

There is also an uncomfortable commercial side to this story, especially for Qlik partners.

When licenses are provided through a partner, the overage bill may go to that partner. The partner must then agree with the customer on who will cover the costs.

In our case, it is clear. We made the mistake and will cover the costs.

But what if the cause is less clear? For example, when one of the customer’s employees unintentionally loads far more data than expected. Or when the bill amounts to thousands rather than hundreds of dollars?

The customer agreed to the subscription terms, but may not always be willing to pay unexpected costs. A technical incident can therefore also put the relationship between customer and partner under strain.

According to its public product terms, Qlik waives overage charges during the first six months of an initial capacity-based subscription. We have not yet found a standard goodwill policy for occasional overages after that period. We have asked Qlik about this.

Of course, you can purchase additional capacity. But that mainly makes sense when you need it on an ongoing basis, not when an incorrect reload puts you over your limit for two hours.

Give customers a choice

Qlik presents its capacity-based model on its website as a way to provide predictable costs. That is indeed one of the benefits of this model, but unexpected overage charges can put that predictability under considerable pressure.

I understand why Qlik allows overage. It prevents processes from being interrupted unexpectedly when the available capacity is exceeded. At the same time, I would like customers to be able to decide for themselves how much additional usage they want to allow.

For example, this could be done by offering a configurable limit of 100%, 110%, or 125% of the purchased capacity, with the option to retain the current limit of ten times the capacity.

A more flexible approach to brief, occasional overages would also be welcome.

We have now submitted a feature request in Qlik’s Ideation Portal, titled Configurable Data for Analysis Overage Limits in Qlik Cloud, and have also raised the issue directly with Qlik.

We have since learned that Qlik is working on new functionality called Usage Bank. It was also announced in Qlik’s October 2026 product update. This may offer ways to better limit capacity usage. However, it has not yet been confirmed whether Usage Bank will actually provide configurable limits for Data for Analysis overage. We are discussing this with Qlik Product Management.

I hope this development will ultimately give customers more options to make their own trade-off between continuity and financial risk.

We are closely monitoring developments around Usage Bank and the options for limiting overage. As soon as Qlik provides more clarity, we will update this article.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years as a developer, architect, trainer, and consultant. He likes solutions that fit the organization and that people actually use. He is a former Qlik Luminary and Qlik Partner Ambassador. A long time ago, he co-authored QlikView for Developers.

Outside of work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that receive varying levels of enthusiasm from his family.

The post Qlik Cloud overage: who decides how much risk you face? appeared first on Bitmetric.

Agentic development: building faster, but not without a developer

One of the most interesting developments is the expanded support for agentic development in Power BI. With MCP servers and other AI integrations, developers can increasingly delegate tasks to AI assistants. These include setting up data models, writing DAX measures, and building and formatting reports.

In October, the Power BI Report Authoring Skill was expanded to support custom visuals and made generally available. This allows AI agents to add custom visualizations, connect them to data, format them, and validate them. As a result, more and more parts of a report can be developed automatically.

At Bitmetric, we use Claude through an MCP connection to create initial versions of Power BI solutions.

This saves a considerable amount of time. As one of our consultants puts it: “No more spending two days just getting the padding right on every page.”

The results are particularly impressive when quickly building a proof of concept. At the same time, we find that refining an initial version can sometimes take a surprising amount of time.

We previously wrote about the possibilities of MCP servers for Power BI. We are now seeing how this technology is changing day-to-day development work.

Our view: AI is taking over more and more hands-on development work. As a result, the developer’s role is shifting toward understanding business requirements, designing good data models, and evaluating results. That is precisely where the added value lies.

More information: Power BI October 2026 Feature Summary.

Fabric Data Agents: better answers start with better definitions

Microsoft has made advanced SQL and DAX generation for Fabric Data Agents generally available. This enables agents to better determine which tables, relationships, and calculations are needed to answer questions about business data.

This is an important improvement, because a technically correct query doesn’t necessarily produce the right business answer.

Suppose someone asks about revenue in Germany. What exactly do we mean by revenue? Does it include returns? Does it exclude certain suppliers? And which date determines the reporting period?

With the improved query generation, an agent can take this kind of context into account more effectively, provided that the information is available.

Our view: the semantic layer is becoming even more important. Business definitions must be clearly documented and properly maintained. We also recommend testing agents using historical data for which the correct answers are known. This allows you to verify that an agent not only gives convincing answers but also produces the correct figures.

More information: Advanced NL2SQL and advanced DAX generation.

Project Osmos: AI will also perform data engineering

With Project Osmos, Microsoft is introducing a new AI agent for data engineering in Fabric. At FabCon Europe 2026, we already saw how Microsoft is placing an increasing emphasis on AI within the data platform. Project Osmos is the next step in that development.

Instead of working out every step yourself, you describe the desired outcome. The agent can then explore the data, generate code, prepare pipelines, and perform checks.

This could significantly speed up development, but it also requires clear rules and safeguards.

One of our consultants puts forward a clear guiding principle:

“The agent may prepare the change, but must not implement it until explicit approval has been given.”

That approval must be based on a review of the generated code and validation results. Clear rules are also needed for access permissions, development and production environments, schema changes, monitoring, and error handling.

Our view: the more autonomous agents become, the more important it is to define in advance what they may and may not do. Automation without control is not progress.

More information: Introducing the data engineering agent for Fabric.

Capacity management: sometimes a failed refresh is good news

Not every interesting update revolves around AI.

Microsoft has improved surge protection for Power BI semantic models. This allows the system to intervene sooner when processing operations are at risk of exceeding configured capacity limits. The improvement is applied automatically, so you do not need to change any settings.

This may mean that a refresh is rejected sooner. But that is not necessarily a disadvantage.

A failed refresh is visible and can be investigated. Unexpectedly high capacity usage, on the other hand, can have financial consequences.

We also see frequent rejections as a useful signal: it may be time to optimize the data model or processing.

Our view: effective capacity monitoring is not only about performance, but also about predictable costs. Of course, it remains important to actively monitor refreshes.

More information: Power BI October 2026 Feature Summary.

Two technical changes to keep in mind

In addition to these developments, there are two changes that will have an immediate impact on some organizations.

Databricks: from ODBC to ADBC. The new connector for Power BI and Fabric is generally available. Microsoft expects existing functionality to remain available, but organizations that use Databricks as a data source would be wise to test the transition in good time.

More information: Databricks ADBC connector for Power BI and Microsoft Fabric

Fabric Data Agents in Microsoft Foundry. The existing integration through a custom tool was phased out on November 6, 2026. Developers who use this integration must switch to the new integration through Fabric IQ.

More information: Retiring the Fabric data agent custom tool in Microsoft Foundry

Our conclusion: value is shifting from building to understanding

October’s developments show how quickly Microsoft is integrating AI into Fabric and Power BI. Work that previously required manual development can increasingly be prepared or carried out by an agent.

This also changes where a BI specialist adds value.

An agent can write a DAX measure. But does it understand why an organization calculates revenue in a particular way? Does it know which data is reliable? And can it assess whether a dashboard actually helps people make better decisions?

Those questions will only become more important.

Our advice: make sure the foundation is sound before deploying AI broadly. Document business definitions, establish governance and set clear guidelines for the use of data and AI.

Get more from your data with Power BI and Fabric?

Power BI Consulting & Implementation

From smart dashboards and reliable data models to advanced analytics, our Power BI consultants help you make information accessible and turn insights into better decisions.

View Power BI Consulting

Microsoft Fabric Consulting & Implementation

Want to bring data sources together, automate processes or develop a future-proof data platform? Our Fabric consultants support you from architecture and implementation through optimization.

View Fabric Consulting

The post Microsoft Fabric and Power BI: The Most Important Updates from October 2026 appeared first on Bitmetric.

We discussed the key updates with several of our Qlik consultants. What is new, what does it actually add, and what should you keep in mind?

Semantic Models: centralized management of your KPIs at last

Anyone who develops multiple Qlik applications will recognize the problem. You have a revenue definition that is used in five applications. The definition is then updated, but not everywhere. Before you know it, the same concept shows different figures in different dashboards.

Of course, we have had solutions for this for years, such as shared scripts, QVDs, and shared conventions for master items. But keeping everything consistent requires discipline.

With the new Semantic Models in Data Products, Qlik now offers a more structured solution.

You define relationships, dimensions, and measures centrally in a Data Product. Applications can then reuse these definitions without rebuilding them each time. Central dimensions and measures appear as read-only master items. If you want to change something, you do so centrally.

This is particularly useful for organizations with multiple applications that use the same business concepts. For developers, it also means less duplicated work.

Qlik also makes it possible to extract a Data Product from an existing application. This allows you to reuse existing data models and master items instead of starting over.

This extraction feature is still in Public Preview and has limitations. For example, extraction does not currently support applications using Section Access, or cyclic and drill-down dimensions.

There are practical questions as well. For example, how do semantic models fit into an existing development, testing, acceptance, and production pipeline? Can you easily move definitions from development to production? We want to investigate this thoroughly before adapting existing development processes around it.

And then AI enters the picture

With the introduction of Agentic Semantic Modeling, AI agents can help build and maintain semantic models through Qlik Answers or the Qlik MCP server.

That is an interesting development. For example, you can ask an agent to create relationships between tables, define dimensions, or modify existing measures.

But an AI agent does not automatically know what your data means. What exactly does a particular order status mean? When can a field be used, and when should it not be used? That information is often not stored in the database.

AI can speed up the technical work, but the business knowledge still has to come from somewhere. We previously discussed the role of a semantic layer in AI in our article about the semantic layer as an API for AI.

Clear rules are particularly important when multiple developers and AI agents are working on the same semantic model. Who is allowed to modify definitions, what instructions does the AI agent receive, and how do we review the changes? Without those agreements, you risk losing the very consistency you are trying to achieve with a centralized semantic model.

In our view, semantic models are the most important development from October. Not only because they enable reuse across applications, but also because they provide a foundation for AI applications that work with the same business definitions and rules as your dashboards.

Qlik Code: developing in VS Code

The new Qlik Code extension lets you develop and manage Qlik load scripts directly from Visual Studio Code.

For developers who already use VS Code, this is a welcome improvement. You can use the editor you are familiar with, manage scripts more easily with Git version control, and use AI tools such as GitHub Copilot or Claude during development.

Several of our consultants have now tested the extension and are enthusiastic about how it works.

However, there is an important caveat. Qlik Code currently supports only the load script. Other parts of an application, such as measures, dimensions, and visualizations, are not yet included.

Full version control for Qlik applications has, of course, been possible for some time with other solutions. But if you manage your scripts through VS Code and Git while handling the other application objects through a different route, you risk fragmenting the development process.

So the question is not only whether Qlik Code is easy to work with, but also how it fits into your existing development workflow.

For teams that work primarily with scripts, the extension offers immediate benefits. For organizations with a mature development and deployment process, it makes sense to first assess how this new way of working fits into that process.

Data preparation becomes more accessible

Qlik also continues to develop its data preparation capabilities.

Data Flow now supports manual data entry and a Map Fields processor. This allows you, for example, to create reference tables and map codes to readable descriptions without writing scripts.

In addition, Table Recipe now lets you view the results after each processing step and give steps recognizable names.

Our consultants are positive about these features, although experienced Qlik developers often still prefer to write scripts themselves.

The main benefit is accessibility. Not everyone who wants to perform a simple data transformation needs to learn Qlik scripting.

Want to know how Data Flow works and when it is better to use Qlik scripting? In our article Qlik Data Flow: Simplifying Data Transformation Without Code, we discuss its capabilities and limitations.

For organizations where the heavy transformation work already takes place in another data platform, such as TimeXtender, these are useful additions.

Direct Access gateway 1.8.1: keep your environment up to date

Not every important update introduces new functionality.

In addition to enhancements for container deployments, the new Direct Access gateway 1.8.1 also includes several bug fixes.

One of these deserves extra attention: Qlik has fixed an issue where overlapping reload requests could, in rare cases, lead to silent data loss. This is a particularly troublesome category of errors because you may not immediately notice that data is missing.

According to Qlik, this issue occurred only in exceptional circumstances. So there is no reason to panic, but it is a useful reminder of the importance of systematic gateway management.

In practice, we regularly see gateway updates being postponed. The gateway runs on the customer’s infrastructure, but it is not always clear who is responsible for maintenance. Agree on who owns this and make sure updates are installed on time. CloudScan for Qlik checks your gateway versions daily and flags when an update is needed.

What are our key takeaways from October?

Qlik continues to invest heavily in Data Products and AI. Semantic models make it easier to centrally manage and reuse definitions, both in dashboards and AI applications.

In our view, this is the most important development this month, especially for organizations with multiple Qlik applications or plans to use Qlik Answers.

Qlik Code is also a valuable step forward for developers, although you need to carefully consider how it fits into your existing development process.

Meanwhile, it remains important to keep an eye on the less exciting updates too. A gateway update may not make the front page, but it can certainly affect the reliability of your environment.

Not every new feature needs to be implemented immediately. But October brought several developments that are worth exploring further.

Want to get more from your Qlik environment?

Qlik Consulting & Implementation

Whether you want to take advantage of new capabilities, improve existing dashboards, or modernize your data architecture, our Qlik consultants help you move from idea to working solution.

Explore Qlik Consulting

Qlik Support & Management

From updates and gateways to monitoring, backups, and user management, we help you prevent problems, resolve incidents, and keep your Qlik environment in good condition.

Explore Qlik Support & Management

The post Qlik Cloud Update October 2026: Semantic Models, AI, and Modern Development appeared first on Bitmetric.

Somewhere in your dashboard is a number nobody has checked against the total it came from. Mine was in a side project on 120 years of Himalayan climbing data, and it said hired staff reach the summit almost twice as often as climbing members. Counted properly, the gap nearly disappeared. Here’s how that happened, and how to find your own version of it.

The number that was wrong

Before we set off

It was convincing, it was on the screen, and it was wrong.

At Bitmetric, many of us run a data project of our own next to client work. It’s how we keep sharpening the saw: new techniques on data we’re curious about. This time I tried a Python pipeline, version control for the model and Power BI’s Key Influencers visual.

The dataset: the Himalayan Database, with 120 years of expeditions from 1905 to 2025. Behind every row is a real person, and not all of them came home.

This post follows that Sherpa headline from start to finish: how it ended up on my screen, how I caught it, and how you can catch the same kind of mistake in your own dashboard. At the end you’ll find five questions to test whether your numbers can be trusted.

Base camp: understand and prepare the data

Every expedition starts with preparation: understand first, then touch.

Every Bitmetric project runs through the same six steps, in the same order:

The Himalaya data is unusual. The approach isn’t.

Step 1, question.

You’re planning an expedition. Which peak, which season, and with or without oxygen?

Step 2, explore.

The data: 11,690 expeditions on 490 peaks, loaded into SharePoint by a Python script and picked up by Power Query.

Before fixing anything, I checked what it really records:

• A “member” is one person on one expedition, not a unique person. Climb Everest five times and you’re five rows.
• Whether an expedition followed a commercial route is missing for 84% of expeditions.
• Most fields are number codes, and the oxygen fields contradict each other.

That sounds specific to mountaineering. It isn’t.

Picture this: you want to know which customers bring in the most. Your ERP holds one row per order line, not per order. The “customer segment” field only became mandatory a few years ago, so it’s empty for older orders. And credit notes live in a separate system. The dashboard on top of that looks fine, until someone asks why revenue per customer doesn’t add up to the annual accounts.

Before you trust that dashboard, ask the same three questions I asked of the Himalaya data:

1. What does one row mean?
2. What does empty mean?
3. Do the details add up to the total?

All three come back below.

Step 3, clean.

About two-thirds of this project went into bringing in, understanding and cleaning the data. Two principles guided it. Empty is not “no”, and a zero can mean “unknown”: a missing commercial-route flag becomes “Route classification not recorded”. And every label must be defensible: “Non-commercial, hired support”, not an attractive but unprovable “semi-guided”.

Name fields are removed and each climber is a key: pseudonymised, not anonymised, since the public source can still link a key to a name.

Four real expeditions: raw codes on the left, readable labels on the right, empty values shown as “not recorded”.

For the techies: Transformations live in Power Query, not DAX: almost 90% of the logic I wrote sits there, where the data comes in, so the model stays readable. Step names say what the step does, so the next developer can follow along without asking me, and the report is saved as .pbip, so every change goes through version control.

Two steps from the model:

// FACT_Expeditions: a 0 in days or team size
// means "not recorded", not zero
#"replace 0s with null" = Table.ReplaceValue(
    #"Changed Type1",
    0,
    null,
    Replacer.ReplaceValue,
    {"SMTDAYS", "TOTDAYS", "TOTMEMBERS"}
),

// FACT_Members: an empty nationality becomes
// "Unknown", not a blank that disappears
#"null nationality = unknown" = Table.ReplaceValue(
    #"insert summit month",
    each [CITIZEN],
    each if [CITIZEN] = "" or [CITIZEN] = null
        then "Unknown"
        else [CITIZEN],
    Replacer.ReplaceValue,
    {"CITIZEN"}
),

Set the route: model and definitions

One truth per number

Step 4, model.

If two reports show a different success rate, nobody trusts either of them. So every number in this model has one definition, written once as a measure and reused everywhere. The success rates for hired staff and for climbing members build on the same base measure, not on two lookalikes.

Facts and assumptions never mix silently. Every member row is labelled “Listed” (in the source) or “Derived” (reconstructed from expedition totals; part 5 explains why). Click “Listed” under “Data scope” and the overall success rate moves from 36% to 43%. Same data, a different question, and you can see which one you’re answering.

Where the model makes assumptions, you have to be able to back them up when someone asks how. The dashboard rates every peak with a Risk Band from “Low” to “Extreme”. Behind it is the risk-matrix approach from risk management (ISO 31000 and its companion standard IEC 31010): mortality and success stay two separate axes instead of being blended into one score, and their combination sets the band. The cut-offs are fixed at 1% and 3% for mortality and 30% and 60% for success.

Same dashboard, two scopes. All records: 109,997 member records, 36% success, 1.07% mortality. Listed only: 92,731 records, 43% success, 1.27% mortality.

The summit: the dashboard, live

Every visual answers a question from step 1

Step 5, dashboard.

Every visual title is a question the planner would ask, such as “Summit Rate: Who Reaches the Top?” or “Peak Selection: Mortality Risk vs Summit Reward”. That’s the difference between a wall of charts and a dashboard people actually use: you open it with a question and find the answer, without a manual or an analyst next to you.

Colleagues tested it as stand-in users and told me where they got lost. With a client, that’s the people who make the decisions.

Don’t take my word for it. The dashboard is live, so click through it yourself:

Three things to try:

• Click “Listed” under “Data scope”, top right, and watch the success rate move.
• Pick a peak you know in the “Peaks” filter.
• Hover over a dot in “Peak Selection” to see that peak’s details.

The main page, filtered to climbing members, leaders and deputies.

One page is missing from the live version: Key Influencers, which ranks the factors that make an outcome more likely. Microsoft doesn’t support it in a public “Publish to web” embed, so here it is as a screenshot. Behind a normal login it works as usual.

Key Influencers page. It only uses Listed records, the people with personal attributes, as its subtitle says. The factors show patterns in the records, not causes.

The descent: checking, correcting, limitations

Why the Sherpa number was wrong.

Step 6, check.

In the Himalaya, more people die on the descent (347) than on the push to the summit (128). Data projects go wrong in the same place: the dashboard is finished, it looks good, and nobody checks it again. Check is the last of our six steps, and the first one to get squeezed when a deadline gets close. That’s exactly why it’s on the list. Back to the opening headline: I compared the people listed individually with the totals each expedition reports.

The deaths among hired staff matched. The people didn’t: only just over half of the hired staff the expeditions report appear as individuals, and the missing ones mostly never reached the summit. Leave them out and the success rate looks far better than it is.

Counted correctly, the hired staff on the mountain (the “Sherpas” of my headline) reach the summit 40% of the time, against 36% for climbing members. Still higher, but not twice as high. And because the gap in the records changes from period to period, the trend over time was partly a trend in record-keeping too.

Left: the hired-staff summit rate counted on listed staff only (72%) and on everyone the expeditions report (40%), next to climbing members (36%). Right: the share of hired staff not individually listed, by period.

The fix follows the same principle as the cleaning: missing people are added only from the source’s own totals, labelled “Derived”, with no invented details. Then I checked again, and the fix had created its own counting effect: Key Influencers mistook the empty new rows for a pattern. Every fix gets checked again.

One thing I deliberately left at base camp: the route names, which need alpine expertise I don’t have. For a client, I’d bring a domain expert to the table, because we’d rather name a limitation now than have it surprise you later.

So what does this mean for you? Your dashboard probably has its own Sherpa number: a margin, a conversion rate or a revenue per customer that looks convincing because nobody has checked it against the total it came from.

A wrong headline in a board meeting costs more than one extra check. It can steer a decision the wrong way, and once one number turns out to be wrong, people stop trusting the others too. Checking before any questions come up is cheap. Winning back trust after they do isn’t.

Back in the valley

Going live is only halfway

Going live is the summit. What comes after decides whether a dashboard gets used: maintenance, adoption and trust in the numbers.

Trust starts with five questions for your own dashboard:

1. What does one row in your data actually represent?
2. What do blanks, zeros and missing values actually mean?
3. Could you explain and defend this number in a board meeting?
4. Which numbers are facts, and which are derived, assumed or classified by you?
5. Do the numbers still add up when you check them another way?

Sherpa is the name of a people before it’s a job title. In this data, they did much of the carrying and were counted the least. So I use the comparison with respect, and for exactly that reason: the work that makes a number trustworthy rarely shows in the final total. You know which summit you want to reach. Checking a number against the total it came from is that kind of work: slow, invisible, and the reason the result holds.

I took on 120 years of mountaineering data because I was curious. That curiosity comes along to your project too.

Want to discuss what we can do for your environment? Let us know; we’d be happy to help you think it through.

Sophie Jongedijk

Sophie is a Data & Analytics Consultant working in Power BI, Microsoft Fabric and Qlik, including sustainability reporting for a global retailer. Before Bitmetric, she built financial analysis used at board level by an international trust company and led a client analytics team across four countries, building a capacity model to balance its workload.

She enjoys turning business questions into data models people and AI tools can trust, with a keen interest in statistics.

Outside work, she tracks her goals in a personal Power BI dashboard, trains for alpine climbs, skydives and loves opera.

The post Your dashboard looks right. Is it? appeared first on Bitmetric.

The list is too long to cover in full, and not everything is equally relevant to every organization. We reviewed it with one question in mind: what will change for the people who will be back at work on Monday, dealing with their semantic models, pipelines, and capacity? Here is our selection.

The common thread: your semantic model is now your AI interface

In our view, the biggest announcement is not a single feature, but the overall direction. Fabric IQ is now generally available (GA, Generally Available) in Microsoft Copilot Chat and Cowork, rather than only in preview. Users can ask business questions there, with answers based on your existing Power BI reports and semantic models. With no additional cost for AI tokens. This aligns exactly with a development we wrote about earlier: your semantic layer is becoming the API for AI.

The Fabric IQ MCP server and Fabric data agents in Copilot Studio are also GA, including visualizations in data agents. Ontologies, semantic views, and the ability to bring DAX measures into ontologies will follow in preview.

IQ sharing is also coming in preview. It lets you share not only governed data, but also business context such as agent instructions and ontologies with other teams, partners, and ecosystems. Support for Fabric IQ ontologies and Power BI semantic models is on the roadmap. This increasingly turns semantic context within Microsoft Fabric into something you can reuse and share, rather than something confined to a single workspace or application.

Sounds good. But it also means every messy model will suddenly reach a much wider audience. That measure called “Measure 3,” the column without a description, the relationship only the original developer understood: Copilot will work with them just as readily as it does with your best-documented model. An AI assistant is only as good as the model it relies on.

For everyone who has spent years emphasizing naming conventions and documentation: this is your moment. Enjoy it

Governance: finally, control over what Copilot can see

Good news, because with the previous point in mind, this is exactly what you need. Microsoft is introducing two layers of control:

• Restrict from Copilot: administrators decide which semantic models can participate in AI experiences at all.
• A setting for each semantic model that enables or disables read-only access through Power BI Copilot, Microsoft 365 Copilot Chat, Cowork, data agents, and remote MCP servers.

Note that the second setting is enabled by default. Users with existing read access can therefore use the model through supported Copilot and MCP experiences unless you explicitly restrict it.

Sensitivity labels, DLP policies, and information protection now also carry over to Copilot. With DLP restrict access, Purview can limit access to a Fabric item as soon as sensitive data is detected. Also new are the Govern experience in the OneLake catalog, outbound access protection for OneLake shortcuts, and, in preview, Policies in Fabric with attribute-based controls.

Capacity: more flexibility, but read the fine print

Capacity overage is GA. When your capacity is full, you automatically purchase additional compute instead of being throttled. Useful, but the price is three times the pay-as-you-go rate, with a configurable rolling 24-hour overage limit in CU-hours. It is enabled by default for newly created capacities. So check which threshold is configured in your environment before the first invoice does it for you. We include settings like these as standard in our Fabric management.

Workspace-level surge protection is now available in preview and is being rolled out further. It lets you isolate a runaway workspace while keeping business-critical workspaces unaffected. This addresses a problem we regularly encounter in practice, where a single experimental notebook drags down reporting across the entire organization.

At the other end of the spectrum, the F0 SKU with on-demand billing is coming: no prepaid compute, with charges per CU-hour without smoothing and a rolling 24-hour limit. This could be useful for small environments and development work. But pricing has not yet been announced, so I would not overhaul your capacity strategy just yet. For those looking to move in the opposite direction, F4096 and F8192 are now available as well.

Fabric Apps in Power BI

Fabric apps in Power BI will enter preview for Power BI Pro and Premium Per User over the coming weeks, with up to 1 GB of Fabric Database per app at no additional cost. In Power BI Desktop, you will soon be able to have a Fabric app built from a semantic model by describing what you want in natural language, then view, modify, and publish it.

We are curious to see how this holds up in practice. The barrier to building something will be much lower, which is exactly why it makes sense to decide in advance who is allowed to publish what. Otherwise, a year from now, you may have fifty Fabric apps and no one will know who manages them.

For data engineers

Less in the spotlight, but perhaps the most useful category for day-to-day work:

• Copy job now supports change data capture and audit columns. SCD Type 2 is now generally available. That saves a lot of custom-written boilerplate.
• Mirroring for Google BigQuery and SharePoint Lists is GA. Dynamics 365 Business Central and a bidirectional connection to Salesforce Data Cloud 360 will follow in preview.
• Git and CI/CD: compare and commit, selective branching, and bulk import/export APIs are GA. Deployment plans and file-level commits are coming to preview.
• Warehouse: custom SQL pools are GA. GPU-accelerated query execution and a node-based billing model (pricing is not yet known) are in preview.
• The data engineering agent (Project Osmos), now in preview, assists with migrations, schema harmonization, and ETL on Fabric Spark, and can be controlled from tools including GitHub Copilot, VS Code, and Claude Code.
• Observability: unified workspace monitoring, an updated Monitor Hub, job alerts through Activator, and an operations agent that is the first to investigate pipeline failures.

In October, Microsoft shared more details about Project Osmos. In our October 2026 Power BI and Fabric update, we explore what this means for data engineering and the practical considerations organizations should keep in mind.

Migrating from Azure Data Factory or Synapse

Still using ADF or Synapse? View in Fabric brings your existing environment into a Fabric workspace while ADF remains the source of truth. A new assessment tool shows how ready each pipeline is for migration. And the Migration Assistant now supports Teradata in preview.

That is a sensible approach: first see what you have, then move it.

Planning, Copilot, and database updates

• A Native Planning Engine is in preview, with Microsoft claiming up to 10x better performance and scalability. I am curious to see how that holds up in a real-world environment. Planners can also use their own identity to work with semantic models through Fabric IQ.
• Microsoft 365 Copilot in Power BI is in preview, disabled by default, and separate from the existing Power BI Copilot setting.
• On the SQL side: DiskANN vector indexes, SQL Server on Azure Local, a Database Hub in Fabric (public preview) providing a single overview of Azure SQL, PostgreSQL, Cosmos DB, and SQL database in Fabric, plus database agents that analyze performance issues.
• Microsoft reiterated its support for Apache Ossie, an open standard for exchanging semantic metadata. A small update, but a good sign.
  
  

What we recommend

1. Get your semantic models in order. Use clear names and descriptions, certified measures, and a sound security model. And make a deliberate decision for each model about whether it should be available to Copilot, rather than letting the default setting decide.
2. Check your capacity overage setting. It is enabled by default, at three times the standard rate.
3. Start collecting your capacity metrics now. Once pricing for F0 and on-demand is available, you’ll want to compare using real figures rather than a gut feeling.
4. Run the assessment on your ADF or Synapse environment, even if migration is not yet on the roadmap. At least then you’ll know where you stand.

Want to discuss what this means for your environment? Let us know; we’d be happy to help you think it through.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He favors solutions that fit the organization’s context and that people actually use. Long ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY, and pursuing hobby projects that his family embraces with varying degrees of enthusiasm.

The post FabCon Europe 2026: the Fabric updates that really matter appeared first on Bitmetric.

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.

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

The business context: Fashion Analytics

Some context on the business first, because the questions later in this article only make sense once you know how this company works. Our customer is a fashion company: it designs collections, presents them to retailers per season, and collects orders for production. That makes the season calendar the backbone of every analysis.

A pre-order, a re-order and a returns period each run on their own rules, and a jacket that proves itself gets carried over to the next collection under the same article name, redesigned to the trends of that season.

Most of the questions in this article are the ones a buyer or an account manager actually asks:

“Which articles grow from one season to the next?”

“How does the current season compares to the previous one?”

And that is exactly why it is a good test for Qlik Answers: the questions are easy to say out loud, but answering them means knowing which season, which article name and which measure belong together, and none of that is obvious from the data alone.   

The data set we used is the Sales model. It is a star schema with a concatenated fact table. That detail matters, because it means a naive Sum(Sales) returns the wrong number. To get a correct answer, the AI must use the master measures. Any approach that lets it invent its own aggregation is going to fail here, and it will fail quietly. 

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. 

Tom Maarsen

Tom joined Bitmetric in April 2023, bringing with him years of experience in returns logistics, including extensive work with Qlik. Over the years, he has developed dashboards for productivity tracking and near-real-time inventory insights. At Bitmetric, Tom has deepened his expertise in Qlik, TimeXtender, and Qlik Automate. As an automation expert, he spoke at the Masters Summit for Qlik, sharing insights on optimizing workflows. In his free time, Tom enjoys gardening and spending time on the water on his boat.

The post Qlik Answers review: What we learned from real-world testing appeared first on Bitmetric.

Give a language model access to a database, tell it which tables are in it, and ask what last month’s revenue was. There is a good chance it will produce a well-formed query and a convincing answer within seconds.

But that still does not tell AI what your organization means by revenue.

Does it mean booked revenue, invoiced revenue, or delivered revenue? Are credit notes included? What about intercompany revenue? Which date determines the month? And if someone asks about revenue in the Netherlands, do we mean the customer’s country, the delivery address, or the sales organization?

That is not a SQL problem. It is a semantic problem.

And that is precisely why a concept that has circulated in business intelligence for decades is suddenly receiving so much attention again: the semantic layer.

In fact, I think its role is fundamentally changing.

Until now, we mainly built semantic models to provide dashboards and reports with consistent business logic. Soon, AI agents will use that same layer to understand our organizations.

From BI layer to interface for AI

The semantic layer is not new

Anyone who has worked in Business Intelligence for some time will recognize the idea. In the traditional BI world, a semantic layer was standard practice. A well-known example is the BusinessObjects Universe. A Universe placed a business-friendly layer over the technical database structure. Users worked with familiar concepts, dimensions, measures, and hierarchies without needing to know exactly how the underlying tables and joins were structured.

SAP still describes a Universe as a collection of metadata objects that allows users to analyze data in non-technical, understandable business language. (SAP Help Portal)

Cognos had a similar concept with Framework Manager.

The idea was simple and actually very sensible:

The database tells you how data is stored; the semantic layer tells you what that data means.

Of course, there was also a downside.

These traditional BI environments could become quite cumbersome. Before a user could build a report, a data warehouse often had to be designed, a central model built, a Universe configured, and someone had to grant permission to use it.

That was not exactly agile.

Then came self-service BI

Starting around the second half of the 2000s, the landscape began to change.

Products such as QlikView, followed later by Qlik Sense and Tableau, made it much easier to work with data quickly. Instead of spending months designing a central BI layer, an analyst or developer could load, model, and visualize data and deliver something useful almost immediately.

That was a major step forward.

I worked with Qlik for years myself, and that speed and freedom were a large part of its appeal.

But this shift also had a consequence: the explicit, centrally managed semantic layer began to fade from view.

That does not mean Qlik, Tableau, or later Power BI contained no semantics. Quite the opposite. A Qlik data model contains relationships and business logic, Tableau has logical models, and Power BI now offers extensive semantic models.

But in practice, that meaning often became scattered across different layers. Especially in Qlik, much of the business logic was captured not only in the data model, but also in variables, set analysis, master measures, script logic, and even individual object expressions.

That worked well as long as experienced developers knew where everything was and why it had been built that way. But it made the business meaning less explicit, less centralized, and harder to reuse outside the original application.

As a result, the semantic layer received far less attention as an architectural principle in its own right.

We increasingly began capturing business logic wherever we needed it at the time:

• In a Qlik app
• In a Tableau workbook,
• In a Power BI semantic model,
• In a SQL view,
• In a DAX measure,
• In an ETL script.

And sometimes in several places at once.

Self-service made analytics more accessible, but it also made it very easy to create multiple versions of the same truth.

Ultimately, we ran into the same problem

As long as an organization has a limited number of dashboards, the problem is manageable. But as self-service BI becomes successful, dozens or hundreds of models, apps, and reports emerge. Then the familiar debates begin.

What is striking is that these are roughly the same problems the classic semantic layer was originally designed to solve.

And so the concept returned.

Power BI now explicitly refers to semantic models. Looker built much of its platform around LookML. dbt developed its Semantic Layer and MetricFlow. Data platform vendors are increasingly talking about metrics, data products, ontologies, and semantic layers.

I sometimes look back on BusinessObjects with a certain nostalgia. Universes were not such a bad idea after all. But the renewed appreciation for the semantic layer is mainly driven by our rediscovery that access to data is not the same as agreement on what it means.

And that is where AI comes in.

AI makes the problem much bigger

Consider that question again:

“What was our revenue last month?”

A human data analyst who lacks sufficient context can ask follow-up questions:

An analyst can also recognize when a result seems strange. If revenue is normally around five million and the query suddenly returns 28 million, that will probably set off alarm bells.

An AI agent does not automatically have that intuition.

It can find a table with a Revenue column, join it to another table, generate a plausible query, and confidently present the wrong answer.

Maybe the join is wrong. Maybe it uses bookings instead of revenue. Maybe every order line is counted three times. Maybe it is unaware of an exception from Finance.

The answer can still look excellent, which makes this more dangerous than a standard error message.

The challenge is no longer making data discoverable

Over the past twenty years, we have invested enormous effort in making data accessible.

Cloud data warehouses, lakehouses, APIs, ELT, notebooks, and self-service BI have made it increasingly easy to access data from a technical perspective.

Generative AI takes this a step further. Soon, users may not even need to know where the data is stored. They can simply ask a question. This shifts the problem. The question is no longer just:

“Can AI access our data?”

The more important question becomes:

“Does AI know how our organization interprets that data?”

That is where the semantic layer comes back into play.

The semantic model as a contract

I find it useful to think of a good semantic model as a kind of contract. It defines:

Technically, such a model can consist of measures, dimensions, relationships, calculated fields, hierarchies, metadata, and security rules, but functionally it does something more important. It captures part of the business language in a form that software can use. Until recently, dashboards were the primary consumers of that contract. Now, an entirely new type of consumer is emerging: the AI agent.

Microsoft is already explicitly building toward this

Microsoft Fabric clearly shows where this development is heading. Fabric Data Agents can answer questions about different types of enterprise data, including warehouses, lakehouses, and Power BI semantic models.

Microsoft has even published separate guidelines for making Power BI semantic models AI-ready. In these guidelines, Microsoft emphasizes the importance of clear names, descriptions, correct relationships, and reducing ambiguity in the model, among other things. According to Microsoft, the quality of a Data Agent’s answers depends heavily on how well the data sources and semantic models it uses have been prepared.

That is telling.

For years, we often viewed metadata as documentation—something we should really maintain, but rarely have enough time for in practice. For AI, metadata shifts from documentation to “runtime context.” A measure’s description is then useful not only to the next developer. An agent actually uses that description to determine what the measure means and when it should be applied.

And then MCP enters the picture

Microsoft also supports using a Fabric Data Agent as a Model Context Protocol server, which is currently still in preview. Through MCP, such an agent can make its data and query capabilities available to external AI systems.

MCP is a standard that allows AI applications to discover and use tools, context, and data sources in a consistent way. The interesting part is not so much MCP itself. Perhaps MCP will be replaced by something better in a few years. What is interesting is the architectural principle behind it.

The application where someone asks a question no longer needs to be the same application where the business logic is managed. An AI assistant can run elsewhere and still access a governed data or analytics layer. This suddenly makes the semantic layer much more than the backend of a dashboard.

It becomes a service.

Qlik is moving in the same direction

Qlik is now doing something similar.

Qlik has made its MCP Server generally available and uses it to give external AI assistants access to Qlik’s analytics capabilities and governed data products. This allows the underlying Analytics Engine and existing business logic to be used without requiring the end user to work in Qlik itself.

That is an interesting development. A traditional discussion would be:

“Do we use Qlik or Power BI?”

But with this architecture, you can ask a different question:

“Where do we manage the trusted analytical context that our users and agents need?”

For example, an organization could use Power BI as its primary reporting tool while certain governed data or analytical logic is managed elsewhere.

Or an AI assistant could access Qlik without the user ever opening a Qlik dashboard. That makes platform boundaries less clear-cut.

TimeXtender perhaps makes the idea even more explicit

TimeXtender has explicitly built its MCP architecture around “governed semantic models for AI agents.”

In this approach, the semantic model is presented to an AI client as a contract. Among other things, the model describes entities, relationships, metrics, hierarchies, and relevant context. As a result, the AI does not need to infer what the business means from a technical database schema.

TimeXtender describes the problem well: without this context, an AI system may select a field that sounds logical, miss an exception rule, or create a join that is technically valid but wrong in business terms.

And that actually brings us back to the BusinessObjects Universe. Once again, we are placing a business-friendly layer between the physical data and the consumer. But this time, the consumer is not necessarily a reporting user. It can also be software.

One semantic layer, multiple consumers

I see that as the fundamental shift. For a long time, we viewed a semantic model as something tied to a BI tool. A Power BI semantic model belongs with Power BI reports. A Qlik model or Master Items belong with Qlik visualizations. A Universe belongs with Web Intelligence (or Deski).

But imagine an architecture in which the same governed business logic is used by:

• Dashboards;
• Excel;
• Operational applications;
• APIs;
• Copilots;
• Chat interfaces;
• AI agents;
• Autonomous processes.

That considerably changes the economic value of the semantic layer. The dashboard becomes one of its potential users, rather than necessarily being the end product around which everything is built.

AI makes good modeling more important, not obsolete

There is also an opposing line of thought. If AI can write queries itself, why should we still spend so much time on models, measures, and business logic? Can’t the model simply figure that out?

Technically, it increasingly can, but from a business perspective, that is exactly what you do not want.

The easier it becomes to query any data, the more important a reliable semantic layer becomes.

Ten employees looking at the same dashboard at least see the same revenue. Give each of those same ten employees an AI agent that independently generates SQL against a complex data warehouse, and you may suddenly get ten different answers.

AI democratizes access to data. Without governance, it also democratizes the ability to produce different versions of the truth at scale. That makes well-modeled and governed semantics more important than ever.

This also changes the work of BI teams

If this development continues, some of the work of analytics teams will shift. Today, BI teams still receive many requests like:

When users can use AI to ask their own follow-up questions, some of that work will likely disappear. But that does not mean the work itself will disappear. Someone will still need to determine:

• What KPI definitions mean exactly;
• Where the official definition is maintained;
• Which relationships are correct;
• Which data is reliable;
• Which exceptions apply;
• Which information someone is allowed to use;
• Which models are authoritative;
• How changes are tested;
• How lineage and ownership are documented.

The value shifts from visualizing every question to structuring meaning people can trust. For data and analytics professionals, that strikes me as a healthy development. Although we should be honest: documenting definitions and maintaining metadata is usually a little less fun than building a polished visualization.

And our semantic models are often far from ready for that

There is just one problem. Many existing semantic models were designed for human developers.

A Power BI developer may know exactly what a measure named [NS Adj LY %] means. An AI agent does not.

A Qlik developer knows why a particular set analysis expression applies an unusual selection. An agent that only sees the end result has no idea why.

As a result, things we once easily considered “nice to have” become important for AI-ready semantic models.

These are not exotic AI techniques. They are largely the same disciplines we have always needed for good BI. AI simply raises the cost of carelessness.

From semantic layer to business infrastructure

That is why I believe we need to rethink how we view semantic models. Not as a technical component of Power BI. Not as something that exists only in Qlik apps. Not as an additional modeling tool layered on top of the data warehouse.

A well-designed semantic layer is essentially a machine-readable description of how an organization views its own data.

That is a valuable business asset. Perhaps even more valuable than many of the dashboards built on top of it. Dashboards come and go, but the definitions of revenue, customer, margin, inventory, occupancy, or churn should be much more stable. When that meaning is properly managed, more and more applications can connect to it. Power BI today, a Copilot tomorrow, and the day after that, an agent that automatically investigates anomalies or suggests actions.

We’re almost back to the Universe, but not quite

There is something ironic about this development. After twenty years of innovation, we are partly returning to an idea that BusinessObjects introduced a long time ago:

Put a semantic layer between the technical data and whoever wants to use it.

But we are not simply back where we started. The first generation of semantic layers was primarily intended to make it easier for people to build reports. The new generation needs to work for both people and machines.

And that brings different requirements.

The semantic layer needs better documentation, must be programmable and accessible through standardized interfaces, and must provide sufficient governance for automated systems to work with it. That is fundamentally different.

So don’t start with the chatbot

Many organizations looking to experiment with AI and data understandably start with the visible technology. Which LLM will we use? Microsoft Copilot? ChatGPT? Claude? Our own agent? Which vector database? Do we need MCP?

If the goal is to get reliable answers about your own business operations, I would start by asking a different question:

Where have we actually defined what our data means?

Where is the official revenue definition? Which customer classification is authoritative? Where does the gross margin logic reside? Are those definitions known only to a few experienced developers? Are they scattered across SQL, Power BI, Qlik, and Excel? Or do they actually exist as reusable, governed business logic?

If the answer is unclear, your primary problem is not yet an AI problem. It is a semantic layer problem. AI simply makes that problem suddenly very visible.

The semantic layer is becoming business infrastructure

Dashboards are not going away. For many forms of communication, a purpose-built visualization simply remains better than a chat window. But the dashboard is increasingly becoming less of the sole destination of our data architecture. The same business context can soon be used by reports, applications, and AI agents.

This turns the semantic layer from a component of the BI stack into part of the company’s infrastructure. A place where we define not only where the data is located, but, more importantly, what the data means. And once machines start using that meaning directly, the semantic model takes on an entirely new role: it becomes the API through which AI learns to understand your organization.

Is your data foundation ready for AI?

Becoming AI-ready does not start with choosing a language model. It starts with reliable data, clear definitions, and well-governed business logic.

Want to know whether your current data architecture, semantic models, and governance are ready? With our AI Readiness Assessment, we identify the most important gaps and the steps needed to enable AI to work reliably with business data.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He favors solutions that fit the organization’s context and that people actually use. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and pursuing hobby projects that his family is enthusiastic about to varying degrees.

The post Your semantic layer is becoming the API for AI appeared first on Bitmetric.

It really can work. Anthropic recently published an article explaining how they built this internally: 95% of all internal analytics questions automated, with approximately 95% accuracy. Interestingly, a controlled experiment at a medical clinic reached almost exactly the same conclusions. But what went wrong along the way is at least as instructive.

So the question is not just whether your AI tool is good enough, but more importantly: is your data ready for AI?

The real problem is not the technology

The core problem with analytics agents is not writing queries. It is correctly matching a question to the right table, the right definition, and the right filter.

“How many active users did we have last month?” sounds simple. But an agent needs to know which table you mean, what “active” means in your context, which time window you use, and whether certain user groups should be excluded. If any of that is unclear, the agent will provide an answer that is technically correct but substantively wrong. And no one notices, because it looks perfectly normal.

A concrete example: a field named slot_status with the values Open and Filled. The agent is asked about available slots, searches for slot_status = 'Available'—a value that does not exist—and neatly returns zero results. No error message. No indication that anything went wrong. An experienced analyst would probably have checked which values actually occur first.

What doesn’t work, but is still widely attempted

Automatically deriving definitions

Have an LLM automatically generate your data catalog from your tables and query logs. Many tooling vendors are actively building this into their solutions right now.

Anthropic tried it. It didn’t work. Automatically generated definitions look complete, but they encode exactly the ambiguity you are trying to eliminate. The difference is in the details. An automatically generated description says:

“The status of the order.”

A useful description says:

“The lifecycle status of the order. Use this field for revenue analysis. Do not use this field to determine whether inventory has been reserved; use allocation_status for that.”

The first description identifies the field. The second teaches the agent how the domain works. Use AI to draft documentation, but have a person establish the definition.

Providing thousands of reference queries

Anthropic gave the agent access to thousands of historical SQL files. Accuracy barely improved. In 80% of the cases where the agent was wrong, the correct answer was already in those queries. It just couldn’t find it. The bottleneck was not access to data, but structure.

Choosing a better or more expensive model

In the experiment at the medical clinic, the model was never changed. Accuracy rose from 0% to 92% purely through better context. The model is rarely the bottleneck.

All three cases revealed the same problem: the agent did not need more information, but better information and structure.

What does work

A solid data foundation

Not fifty tables that all have something to do with “revenue,” but one place that everyone knows is the source. Clear ownership, documented definitions, and explicit decisions about what is and is not included. This is not a new lesson: it is exactly what you also need for reliable dashboards. An AI agent simply makes it more obvious when something is wrong.

Is AI part of a broader effort to develop your data environment? A data strategy helps you address architecture, ownership, definitions, and priorities as a whole.

The instruction layer that makes the difference

A semantic layer helps. In Power BI, it is explicitly part of the semantic model. On other platforms, the same principle exists under different names, such as curated datasets, business logic, and centralized definitions. That resolves ambiguity at the metric level. But an agent needs more: it must know which data sources to consult, what the pitfalls are, and how to clarify a vague question. That context is not part of your semantic model.

Anthropic builds that context into manually created instruction documents that it calls “skills.” ChatGPT has the same concept under the name “GPTs,” while Gemini calls them “gems.” Without that layer, its agent achieved only 21% correct answers. With well-designed skills: above 95%.

The knowledge these documents need to contain is domain expertise that cannot simply be written down. It resides in the minds of the people who have worked with the data for years: why a particular table exists, which filters always apply, and which exceptions were once built in after a painful mistake. These people are not the data engineers, but the analysts and domain experts. They are also the only ones who can assess whether an answer is substantively correct; domain expertise is the real differentiator.

The agent is never finished

Anthropic saw accuracy fall from 95% to 65% within one month after it stopped maintaining the agent. There are two reasons for this. Tables are renamed, definitions shift, new sources are added, and the context an analytics agent relies on changes constantly, so the instruction documents gradually become inaccurate. But it also works the other way around: you fix a bug in your data model or add a better filter, while the workaround you documented earlier remains in place. The agent then applies it unnecessarily or does something that is now actually wrong.

Anthropic sees the same pattern found in every data project: the build gets attention and budget, but subsequent maintenance does not. With a dashboard, you notice when someone complains that the figures are incorrect. With an AI agent, nobody notices because it simply keeps providing answers.

Where do you start?

A handful of well-documented datasets, a few dozen test cases, and a simple instruction layer already deliver most of the gains. But first, answer three questions honestly: is your data model documented well enough for an agent to navigate it without guidance? Is someone responsible for maintaining the instruction documents when something changes? And do you have domain experts who are willing to write down their knowledge and can assess whether the answers are correct?

If the answer to any of those questions is “not really,” that is no reason to stop. But it is a reason to improve your data foundation first.

Want to know whether your data is ready for AI?

In our AI readiness assessment, we review your data models, definitions, documentation, and ownership. Afterward, you will know where you stand, what is already usable, and what needs to happen first.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in Data & Analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He likes solutions that fit the organization’s context and that people actually use. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that his family is enthusiastic about to varying degrees.

The post Putting AI to work on your data works. But not like this. appeared first on Bitmetric.

License costs are rising—not with just one vendor, but across the market. According to research by Zylo, 79 percent of IT leaders now face price increases at renewal. Vertice puts SaaS inflation in the first quarter of 2026 at over 13 percent, nearly two percentage points higher than a year earlier.

You feel it most when you receive a renewal proposal that looks markedly different from the last one.

So what do you do? You have a few options.

Simply renew

You can sign. It works, and continuity is assured. Sometimes that is simply the right choice.

Negotiate

You can negotiate. A renewal is not a foregone conclusion. There may be room to negotiate, especially if you have a partner who knows the vendor and can handle the discussion effectively. It does not always lead to an adjustment, but if you do not ask, the answer is always no.

Review the contract model

You can review the contract model. Most platforms offer several options, and the combination that worked two years ago may no longer be right today. We recently saved a large Dutch representative body more than 30 percent by migrating it from on-premises to the cloud. It was a logical step it had wanted to take for some time, with a welcome side effect on the invoice. That does not even include the hardware savings.

Switch platforms

Sometimes the conclusion is that another platform is a better fit. An independent BI tool selection lets you compare the options based on usage, functionality, costs, architecture, and management. Switching is not always easy, but with the right guidance, it does not have to be a leap into the unknown. We are currently going through exactly that process with several clients.

But there is another question that I find at least as interesting.

Does the platform still align with where you want to go?

Vendors continuously add functionality, which partly justifies changes in pricing. In our experience, however, many organizations use only a fraction of what is available. That means you are not only paying more, but also failing to make full use of what you already have. This is especially true of the AI capabilities added to almost every platform in recent years.

A renewal is therefore not just a time to look at the invoice. It is also a time to assess whether your analytics environment still fits your organization’s needs—not what was purchased two years ago, but what you actually want now.

Would you like an independent assessment of the renewal proposal and your current direction? A Second Opinion Data & Analytics gives you insight into what is sound, where the risks lie, and which alternatives are realistic.

Sometimes renewing makes sense. Sometimes optimization is enough. And sometimes switching is the wiser choice.

Would you like to discuss your upcoming renewal, or more broadly how your Data & Analytics platform aligns with your organization? Schedule a call with us.

Eric van Gils

Eric is Commercial Director at Bitmetric and has worked in IT for more than 20 years, most of that time in data and Business Intelligence.

During that time, he has seen one thing again and again: organizations are not looking for attractive dashboards; they want answers to questions that truly matter. Clearly defining those questions is often the hardest part.

His guiding principle: “If you don’t know what to ask, you’ll never get the right answer.” Eric helps clients discover what they really want to know and ensures that Bitmetric delivers the solutions that make this possible.

The post Your analytics contract is expiring. Look beyond the invoice. appeared first on Bitmetric.

We took a look. What we found was an environment without a single line of documentation. There were dozens of apps, some of them nearly identical copies with only minor differences. No one knew why they existed or which one was correct. There was no architecture documentation and no version control. Year after year, changes had been made directly in production—patch upon patch—until whatever structure may once have existed had disappeared completely. The environment was running, but it was hanging by a thread.

This is the scenario many organizations fear but rarely take active steps to prevent: dependence on one person and a vulnerability that only becomes visible when that person leaves.

I have seen this pattern recur in Qlik environments for almost twenty years. In this guide, I explain what effective Qlik management looks like, what goes wrong without structured maintenance, how proactive work differs from reactive fixes, and when it is better to bring in a partner than to handle it yourself.

In short: Qlik environments grow on their own. Manageability does not. Without structured maintenance, technical debt accumulates more quietly than you might think, until a departure, migration, or release exposes it. Proactive management keeps your environment usable and ensures that every change remains manageable instead of becoming increasingly burdensome.

Table of Contents

• What are Qlik support and management?

• What goes wrong without management?

• Proactive vs. reactive: the difference in practice

• Qlik Cloud vs. on-premises: what changes?

• Governance: how do you stay in control as the environment grows?

• Performance: where are the real bottlenecks?

• When should you bring in a support partner?

• What should Qlik support cost, and what value does it deliver?

• Frequently Asked Questions

What are Qlik support and management?

Qlik management is about more than calling a help desk when something breaks. It covers everything needed to keep a Qlik environment healthy, manageable, and reliable: monitoring environment health, app maintenance, governance, release analysis, performance reviews, and user management.

That is fundamentally different from generic IT support. An IT generalist resolving a ticket does not have the expertise to diagnose a silent error in an incremental load routine. Nor can they assess whether a new Qlik Cloud feature release affects the custom extensions you use, the visualizations that have been phased out, or the API integrations that depend on your environment.

The distinction I always make is:

Reactive management: you resolve problems after they become visible. Users report that a dashboard is inaccurate. You investigate, fix it, and wait for the next report.

Proactive management: you monitor, analyze, and maintain the environment systematically, preventing problems from occurring—or at least from coming as a complete surprise.

That sounds logical. In practice, many organizations still choose the first approach, simply because it feels more tangible: you pay for what is broken, not for what does not break. The irony is that reactive management is consistently more expensive. Not on the monthly invoice, but in the cumulative cost of incidents, recovery time, and the technical debt that builds up step by step.

What goes wrong when you neglect Qlik management?

Based on the environments we have encountered over the past few years, we see the same problems recurring. Not always all seven at once, but rarely fewer than three.

1. An (incremental) load that silently fails

A QVD load routine runs every night but has not loaded fresh data for weeks. The error message disappears into a log file that nobody reads. Users see data from three weeks ago as “current.” This is one of the most dangerous problems because it remains invisible until someone compares the figures with another source.

These kinds of errors can be completely prevented with a simple monitoring alert. But someone has to configure that alert first.

2. Knowledge that leaves with your people

The architect who built the data models has left. What he built works, but no one knows why it was set up that way. There is no documentation, no comments in the scripts, and no architecture description. Every change is now a gamble because you do not know what you can touch without breaking something else.

The example from the introduction is the extreme case. But I see a milder version in almost every new client environment.

3. Hardcoded reference data

Product categories, cost centers, region codes: hardcoded in the script or loaded from an Excel file maintained by a single colleague. That colleague has left. The Excel file is somewhere on a shared drive. Or perhaps it is no longer there.

This sounds trivial until the organization restructures and the cost center codes change. Then you discover that thirteen apps each contain their own version of that table.

4. Uncontrolled growth of apps and sheets

I call this Qlik sprawl, after the familiar spreadsheet sprawl: the same uncontrolled growth, but now in apps and sheets instead of Excel files. It starts with apps: at some point, every department has its own report built. But with the arrival of self-service analytics, it goes further: anyone can create sheets, duplicate visualizations, and save their own versions. That is an advantage of the platform. The problem is that no one ever cleans up.

The result is an environment full of overlapping apps and sheets, with slightly different definitions of the same concepts. “Revenue” in the financial dashboard is calculated differently from “revenue” in the sales dashboard. And no one knows which version is correct anymore, or which sheets are still actively used.

5. Silent changes in source data

The data source changes. A field gets a new value. A table is renamed. A new option is added to a drop-down list. Qlik does not display an error: the data simply loads, but the results are no longer correct.

This is more insidious than a hard error. A hard error is noticeable. A silent discrepancy can go unnoticed for weeks or months, until someone compares the figures with an external source.

6. Missing documentation

The environment is running. But why a specific data model is structured the way it is, which decisions were made when configuring spaces, and who has access to which data source and why: none of this is documented. With every change, you have to figure it out all over again, and mistakes happen because you lack the context.

7. Governance gaps: access and user management

Who has access to which data? Is that access still appropriate after the latest reorganization? Do any users have overly broad permissions? And, perhaps more urgently, do former employees still have active accounts in the environment?

User management is an aspect of governance that is often overlooked. People who change roles, move to another department, or leave the company are not always removed from Qlik. This is not only inefficient; it also creates a compliance risk.

Proactive vs. reactive: the difference in practice

Proactive Qlik management consists of a set of specific activities that you perform systematically, regardless of whether anything is currently broken. It follows a clear schedule.

To illustrate, this is how we approach it at Bitmetric, organized by frequency.

Continuously and when incidents occur

Handling support requests, investigating errors in apps and reloads, supporting data sources and automations, escalating platform issues to Qlik Support when necessary, and restoring objects from backup.

Weekly

Identifying new apps, spaces, data connections, automations, and tasks. Reviewing changes to access permissions and licenses. Analyzing recurring reload and automation errors. Reviewing open support tickets.

Monthly

Analyzing usage and configuration with the Qlik Analyzers: App Analyzer, Reload Analyzer, Data Connection Analyzer, and Entitlement Analyzer. Checking whether apps comply with tenant standards. Cataloging unused apps, spaces, alerts, subscriptions, automations, data connections, and tasks. Reporting on incidents, findings, and areas for improvement.

Quarterly

Reviewing extensions and themes for usage and necessity. Analyzing app and sheet adoption. Identifying unused sheets. Optimizing reload schedules and batch windows. Assessing QVD performance. Discussing recurring support findings and prioritizing improvement proposals.

Annually

Assess the tenant architecture. Evaluate scalability in relation to users, apps, and data volume. Review governance, roles, and responsibilities. Reassess licensing and capacity requirements. Update the disaster recovery plan and practice the recovery procedure, including a restore test using the Qlik Cloud backup.

This is what proactive management means in practice. No vague promises about “proactively helping you think ahead,” but a structured approach with a cadence that suits the nature of the platform.

Qlik Cloud vs. on-premises: what changes in management?

A common assumption is that Qlik Cloud is SaaS, so the vendor handles its management. That is partly true. The infrastructure is indeed Qlik’s responsibility: servers, availability, and updates to the core software.

But managing the environment is still your responsibility.

Moreover, Qlik Cloud Analytics is a considerably richer platform than Qlik Sense on-premises ever was. Every feature you use also requires management. Qlik Automate introduces automations that can fail and need to be monitored. Reporting introduces subscriptions and distribution schedules that need to be maintained. Qlik Predict introduces AutoML deployments with their own life cycles. And then there are API integrations and third-party connectors.

In my experience, Qlik Cloud shifts the management burden but does not reduce it. Responsibility for the infrastructure disappears, but it is replaced by a broader functional scope that must be actively managed.

Other key differences:

Release cadence

Qlik Cloud publishes weekly feature releases, generally on Tuesdays, in addition to ongoing technical updates. That is significantly more frequent than the semiannual releases of on-premises Qlik Sense. Each release can affect existing apps, visualizations that have been phased out, or extensions that are no longer supported. Proactive release impact analysis is therefore not a luxury but an ongoing management activity.

Data Gateway

On-premises, the data was located close to the Qlik server. With Qlik Cloud, you need a Data Gateway to access on-premises data sources. That gateway has its own life cycle and requires monitoring and maintenance.

Backup and recovery

On-premises, the Qlik environment was often simply included in existing server backups: the file system, QVDs, and the repository database. Qlik Cloud recently introduced soft delete for apps: a deleted app can be recovered for up to fourteen days. This does not apply to configurations and other artifacts, which are lost immediately after deletion. This shifts most of the responsibility for a comprehensive backup and recovery strategy to you or to the provider managing the environment for you. If you do not want to depend on manual exports and separate recovery procedures, our Backup for Qlik Cloud service provides daily managed backups of apps, configurations and tenant metadata, with long-term retention and recovery support.

A good backup also includes more than just app files. It should also cover configurations, connections, automations, permissions, and other metadata needed to reconstruct the environment. Read more about what a good Qlik Cloud backup should include.

For organizations considering a move to Qlik Cloud: plan for a management transition, not just a technical migration.

Considering a move to Qlik Cloud? Read our guide to Qlik Cloud migration or explore our Qlik Consulting service for guidance throughout the process.

Governance: how do you maintain control as the environment grows?

Governance in Qlik concerns who is allowed to view, modify, and publish what; who is responsible for data quality; and whether all of this is properly embedded in the environment’s configuration. In an environment with five users and ten apps, you can manage this informally. With fifty users and a hundred apps, that is no longer responsible.

But governance is not a standard formula that you apply the same way everywhere.

The right governance setup depends on several factors: who develops solutions and for whom, who uses the environment and at what level, who owns the data and who owns the analytics, how mature the data culture is, and how sensitive the data is. Company-wide financial data requires stricter governance than a local marketing analysis.

Four patterns, increasing in complexity

In practice, I distinguish four common patterns:

Personal BI
The creator answers their own questions. Little or no sharing, and no formal publishing. Flexible and informal. Works well for individuals, but does not scale.

Team BI
A group of colleagues shares analyses in a shared environment. Developers are often subject-matter experts who provide access to their own data. Processes are informal, but the approach works for the group.

Departmental BI
A small team within the department builds analytics for all users in that department. Quality standards are higher, and publishing is more formal. This is where lifecycle management becomes important: users are not intimately familiar with the apps, so the apps need to speak for themselves.

Enterprise BI
A central team, often a CoE (Center of Excellence) or BICC (Business Intelligence Competency Center), is responsible for all analytics. It has a high level of technical expertise, formal processes for requirements and delivery, and mandatory lifecycle management. It is often also responsible for providing self-service datasets for departmental and team BI.

The dominant pattern in your organization determines the governance structure you need. But an organization does not have to operate at the same level everywhere. Some departments work well with Team BI, while the finance department requires Enterprise BI governance.

Who manages what: data and analytics

A second dimension is how responsibilities are divided between the business and IT.

In a fully decentralized model, the business manages both the data and the analytics. It is flexible, but difficult to scale and sustain.

In a “middle-out” model, IT manages the data layer and the business manages the analytics. This provides a good balance between governance and self-service and is a commonly chosen approach in practice.

In a fully centralized model, IT or a CoE manages everything. This provides tighter governance and more control, but also less flexibility for the business and greater dependence on the central team.

The best-fit model depends on the organization’s size, data culture, data sensitivity, and the capacity of both IT and the business.

One warning

Overly strict governance is counterproductive. If you regulate self-service out of existence, people will work around the system. Excel, their own tools, shadow IT. The environment you carefully control is bypassed by a shadow environment you cannot see. Choose a baseline that fits the dominant patterns in your organization, and allow room for exceptions where they make sense.

Practical governance elements

Regardless of the chosen pattern, several elements are always relevant:

• Space structure: a clear structure with clearly defined ownership for each space

• Access model (RBAC, Role-Based Access Control): documented, reviewed periodically, and updated after personnel changes

• Data ownership: every dataset has an owner in the business, not in IT

• Section Access: for row-level security, but only robust if the logic remains up to date after organizational changes

• Change management: who is allowed to change what in production, and through which process

Governance is not a one-time project. It is an ongoing process that requires consistent maintenance.

Governance starts with a clear data and analytics strategy. Read more about our Data Strategy service.

Performance: what is really causing the pain?

Performance issues in Qlik Cloud are almost never caused by the infrastructure. Qlik manages the servers, capacity is sufficient in most cases, and “Large Apps support” is rarely what you actually need.

The performance issues I encounter are almost always found in one of the following four layers. And they compound each other.

The data model

A poorly designed data model is the most common cause. Tables that are too wide and contain fields that are never used, redundant joins, unnecessary intermediate tables. The result: longer load times and a larger memory footprint.

But the real problem is the cascading effect: a poor data model forces developers to use workarounds in front-end expressions to produce the required calculations. Those workarounds slow down the app, leading to the assumption that more infrastructure is needed. Yet the solution lies in the data model.

The load script 

Scripts that have been expanded over the years without refactoring. Dead code, duplicate transformations, variables that no longer reference anything. Tasks that run sequentially even though they could easily run in parallel. And the most common issue: no incremental load for tables that could support one, meaning every reload fully reloads data that was largely already present.

Load processes and scheduling

Reload tasks that are not scheduled optimally. Dependencies that are not configured properly, causing one delayed task to trigger a chain of problems. Batch windows that are not aligned with the available capacity. This is operations work, not development work.

Front-end expressions

Inefficient Set Analysis expressions. Calculations that run again with every user interaction because the underlying data structure does not support them. Aggregations in visualizations that should actually be part of the data model.

The solution is the same in every case: periodic maintenance and review. Not hardware or a license upgrade, but someone who reviews it regularly and has enough technical knowledge to identify the cause.

If such a review shows that the data model, load script, or architecture needs to be structurally rebuilt, Qlik Consulting is the logical next step.

When should you engage a Qlik support partner?

Not every organization needs an external Qlik support partner. If you have a well-structured internal team with sufficient Qlik expertise and capacity for proactive maintenance, you can manage it perfectly well yourself.

But there are situations where outsourcing makes more sense than handling it yourself.

Signs that partner support is worthwhile

• No one internally has the in-depth Qlik knowledge needed to analyze release notes or diagnose data model issues
• The environment is too large for one person to keep up with alongside their day-to-day responsibilities
• A Qlik Cloud feature release has already caused unexpected issues in production
• A key person has left without transferring their knowledge
• You are preparing for a migration, an ERP change, or a major architecture change
• Analytics downtime has a direct impact on operational decisions

What to look for when choosing a partner

A good Qlik support partner does more than resolve tickets. Check whether they perform a release impact analysis for every update, whether they know your environment so they do not have to familiarize themselves with it each time, and whether they are willing to challenge you. If a partner always says yes and never pushes back, that is not a good sign.

Also be wary of partners whose attention wanes after the initial implementation. Support is the work that starts after implementation, not before. Always ask what specifically will be done in the first six months after go-live, and by whom.

Are you unsure not only about the support partner, but also about the current setup, management arrangements or proposed approach? A Second Opinion Data & Analytics provides an independent assessment of these choices.

How much should Qlik support cost, and what value does it deliver?

Much of the value of professional Qlik management lies in what does not happen: incidents that are prevented, releases that bring no surprises, and an environment that remains usable without each change requiring more effort than the last.

That last point may be the best indicator of management quality: the effort required to implement a change. In a well-managed environment, that effort remains stable. In a neglected environment, it increases with every addition, as technical debt and a lack of clarity about the existing structure make each step more difficult. Eventually, no one dares touch anything.

What determines the cost?

The price of a support contract depends on several factors: the size of the environment (apps, users, data volume), the complexity of the architecture (on-premises data sources, legacy integrations, custom extensions), the required SLA (incident response time, availability outside business hours), and whether proactive maintenance is included or only break-fix service.

At Bitmetric, proactive Qlik Cloud management starts at €950 per month.

Would you rather manage your Qlik Cloud environment yourself, but still be kept informed daily about risks and anomalies? With CloudScan for Qlik, you can do that from €125 per month per tenant.

A good partner clearly sets out the scope and cost in advance. Vague hourly-rate arrangements without a clear scope are a sign that you do not know what you are buying—or what the final bill will be. At Bitmetric, the Bitmetric Blueprint underpins our entire service offering, not just Qlik Cloud Analytics.

Frequently asked questions

Conclusion

Keeping a Qlik environment running well takes quite a bit of work. Unfortunately, that work is usually invisible: as long as everything is running smoothly, you do not notice it. That is precisely what makes it vulnerable—you only realize something was missing when it stops working.

Structured Qlik management does not guarantee that nothing will ever go wrong. It does guarantee that you will see issues coming sooner, respond faster, and be less affected by surprises that would otherwise build up unnoticed and surface in production.

The choice between in-house management and outsourcing depends on your expertise, capacity, and the complexity of your environment. Both can work. What does not work is avoiding the choice and hoping everything will keep running smoothly on its own.

Want to know where your Qlik environment currently stands? I would be happy to discuss it with you, with no obligation. Use the button below to schedule a call with me via Teams at a time that works for you.

Barry Harmsen

Barry is the founder of Bitmetric. He has worked in data & analytics for more than twenty years, in roles ranging from hands-on development to architecture and strategy. He favors solutions that fit the organization’s context and that people actually use. Barry was a Qlik Luminary and Qlik Partner Ambassador for many years. A long time ago, he wrote QlikView for Developers.

Outside work, Barry spends his time with his family, rowing, doing DIY projects, and working on hobby projects that his family is enthusiastic about to varying degrees.

The post Qlik Support & Management: The Complete Guide (2026) appeared first on Bitmetric.