Qlik Sense exception dashboard

Publications

Qlik Sense Exception Dashboard: Show Only What You Need to Decide

Hector Pincheira

Hector Pincheira

CIO | CTO
Digital Strategy & Technology Innovation

items

A manager opens their dashboard and finds 34 indicators lit up. Greens, reds, yellows, arrows going up and down. And then what no board of directors will ever confess out loud happens: they close the screen and make a decision with their gut. Not for lack of data, but because of an excess of it. The Qlik Sense exception dashboard it is born precisely from that wound. It is the discipline of showing only what demands a decision, and hiding everything that is under control. Because a good dashboard is not measured by how much it shows, but by how much it saves you from looking at.

QlikSense threshold exception dashboard

Research is uncomfortable. Human working memory saturates at around 7±2 items at a time (Miller's Law, confirmed by modern resonance studies). Push beyond 9 data points and decision quality plummets. Yet, we still design dashboards like display cases. In this article, I show you how to build a dashboard in Qlik Sense that decides with you, not against you.

The real problem: you are data-rich and decision-poor

There is a paradox that defines most companies that «invested in BI»: they have more data than ever and make worse decisions than before. KPI overload turns the dashboard into noise. When a CEO faces a screen with 30 flashing red and green lights, the brain spends all its energy deciding where to look, and has none left to think strategically.

The numbers confirm it. A KPMG study revealed that 35% of customer experience professionals waste excessive time navigating through dashboards overloaded with information, which leads to fatigue and low productivity. The consequence is predictable: leaders fall back on «gut feelings» because the data is too noisy to interpret.

💡 Key point: A dashboard does not compete for attention by showing more. It competes by showing less, but exactly what matters. The ideal executive view does not exceed 3 to 5 critical KPIs; the rest live in the drill-down.

Here is the underlying truth: data-driven organizations multiply their return by 3.8 compared to those that decide by intuition. But that return doesn't come from accumulating metrics. It comes from filtering the world until only the signal remains. And that is, technically, the essence of an exception dashboard.

The solution with QlikSense: manage by exception

The idea is simple to state and powerful in practice. Instead of showing all products, all branches, or all customers, the dashboard shows only those that broke the norm. What is within the expected range stays quiet. What deviated, screams. This is called management by exception, and QlikSense implements it with three pieces: flags in the script, thresholds governed by variables, and Set Analysis expressions that isolate the deviation.

Step 1: create the exception flag in the script

It all starts at loading. Instead of calculating the exception on every object (expensive and fragile), we flag it once in the model. We load actual sales against their target and precalculate the relative deviation.

// Tolerance threshold controlled by the script
SET vTolerance = 0.10;   // 10% acceptable deviation
Facts:
LOAD
    Product,
    Branch,
    Actual,
    Target,
    // Relative deviation, protected against division by zero
    If(Target = 0, Null(), (Actual - Target) / Target)  AS DeviationPct,
    // Exception flag: 1 if the deviation exceeds the tolerance
    If(Target > 0 and
       Fabs((Actual - Target) / Target) > $(vTolerance), 1, 0) AS ExceptionFlag
RESIDENT Sales;

Let's analyze each part. The variable vTolerance centralizes the threshold: if tomorrow the board decides that 8% is the new limit, you change one number and the entire dashboard adjusts accordingly. The function fabs() take the absolute value, because an exception can be either in excess or by default. And FlagException already precalculate a 1 or a 0 that we will use later to filter without recalculating anything on screen.

Step 2: isolate the exception with Set Analysis

With the flag in the model, the header KPI stops counting everything and only counts what deviated. This expression answers a specific executive question: how many sales are out of control right now?

// Sales amount during the state of emergency
Sum( {} Actual )
// Number of product-store combinations that deviated
Count( DISTINCT {} Product & '|' & Store )

The modifier {} It is the heart of the pattern: it tells QlikSense to ignore everything under control and operate only on the exceptions, while also respecting the selections the user has already made. It is a filter that coexists with the analysis, rather than replacing it.

Step 3: show only offenders with AGGR and Rank

A directory doesn't want a 400-row table. It wants the five that matter. We combine Aggr() to calculate the deviation by entity and Rank to keep only the worst cases, in a calculated dimension.

// Calculated dimension: only the top 5 with the highest absolute deviation
If(
   Aggr(
      Rank( Sum({} Fabs(Actual - Target)) )
   , Product)  <= 5,
   Product
)

The expression sorts the products by the magnitude of the deviation and returns the name only if it is among the five worst; the rest are collapsed. The result is a table that never grows: it always shows the five most urgent decisions, regardless of whether your catalog has 50 or 5,000 SKUs.

⚠️ Common error: Use the object's calculation condition to «hide» rows. That hides them visually, but QlikSense still calculates everything in the background. Filtering with Set Analysis and script flags is faster and scales better.

Business impact: from report to decision

When a dashboard is redesigned by exception, the change is not aesthetic; it is economic. The time a management committee spends «understanding the screen» drops noticeably, and that time is reinvested in discussing what to do. The meeting stops being a tour of charts and turns into a short list of decisions.

Furthermore, the well-designed exception shortens the distance between the event and the action. A deviation that was previously discovered at month-end now lights up as soon as it crosses the threshold. That speed is money: every day a product operates out of control is margin leaking away without anyone watching. The exception dashboard doesn't report faster; it decides faster.

Common Mistakes and How to Avoid Them

The first is confuse exception with alarm. If everything is marked as an exception, nothing is. The threshold must be strict enough that a red light truly means «act today.».

The second is encode thresholds within expressions. When the limit lives repeated in twenty objects, changing it is a nightmare. Govern it from a single variable, as we did with vTolerance.

The third is overuse color. If the board has red, green, yellow, blue, and orange, color ceases to be a signal and becomes decoration. Reserve red for what requires action and leave the rest in neutral tones.

The room is forget the drill-down. Showing a little above does not mean hiding the detail. The board sees the five exceptions; the analyst, with one click, sees the forty metrics that explain them.

Best practices from experience

Design from top to bottom: first the question the leader must answer, then the data that answers it, and only at the end the chart. If an object doesn't change any decision, remove it. It's painful, but every element you remove makes the remaining ones more valuable.

Precalculate everything you can in the script. Exception flags, status flags, and classifications belong to the model, not the visual layer. Your dashboard will be faster and your expressions more readable. And document every threshold: a limit without an owner or a rationale is a decision disguised as data. If you want to dive deeper into how these principles connect with your company's data strategy, check out the rest of the content at hectorpincheira.com.

Strategic conclusion

A dashboard does not exist to show how much data you have. It exists to reduce the uncertainty of the decision-maker. Qlik Sense exception dashboard invert the logic we were taught: instead of asking «what can I show?», ask «what does it need to see to take action?». And in that inversion lies the difference between a team that looks at reports and one that makes decisions.

The next time you open your dashboard, count the lit-up lights. If they are more than the ones you can decide on in a meeting, you don't have a data problem. You have a design problem. And now you know exactly how to solve it.

Most Read

Pasajero mira un tablero de salidas en un aeropuerto, metafora de la dependencia de proveedores de IA
El Calendario Ajeno: la Dependencia de Proveedores de IA que Nadie Negocia
SAP Business One Procedimientos Almacenados: Reportes Reutilizables - imagen destacada del tutorial
SAP Business One Stored Procedures: Reusable Reports
SAP Business One Pending Orders - featured image of the tutorial
SAP Business One Pending Orders: SQL Query to Control Your Backlog
QlikSense yield analysis: breakdown of the loss
QlikSense Yield Analysis: the Waste Nobody Is Watching
QlikSense mobile dashboard: the three screens
QlikSense Mobile Dashboard: the Three Screens People Actually Open
SAP Business One Bank Deposits - featured image of the tutorial
SAP Business One Bank Deposits: Manage Checks and Collections Step by Step

RELATED ARTICLES