The Qlik Cloud Discovery Agent – Part 2: Insight Triggers That Actually Work

In part 1 of this series we covered what the Discovery Agent is and how to prepare your environment. Now that the administrator settings are done and the right permissions are in place, the next step is up to the application developer: creating insight triggers. This is where the Discovery Agent goes from potential to practice.

An insight trigger is the instruction you give the Discovery Agent: monitor this measure, over this time dimension, and tell me when something interesting happens. Get this right, and your users will receive genuinely useful insights in their feed after every refresh. Get it wrong, and they'll see nothing at all, or worse: a stream of notifications they quickly learn to ignore.

In this blog we'll cover everything you need to know to create well-functioning insight triggers: the four components, the eight insight types, the data volume requirements, and the pitfalls most people run into.

Where do you create insight triggers?

Insight triggers are created and managed directly within a Qlik application, on a sheet in edit or analysis mode. You don't need to leave the application or navigate to a separate administration interface. The insight trigger panel is accessible from the sheet toolbar, provided you have the right permissions.

An application can have a maximum of 50 insight triggers (active and inactive combined). Across the entire tenant, the maximum is 200 insight triggers. Keep this in mind when planning which applications and measures you want to instrument first.

The four components of an insight trigger

Every insight trigger consists of four components. Two of these components are required, two are optional. Below we explain all four.

• The time dimension is the date or timestamp field that the Discovery Agent uses to track how your measure changes over time. It's the backbone of every trigger. There are two strict requirements for this field. First, it must contain actual date or timestamp values, not text strings that resemble dates. If your load script loads a date field as plain text instead of using a date function, the Discovery Agent won't be able to use it. Second, master dimensions are not supported as a time dimension. You need to select a field directly from the data model, even if that same field is part of one or more master dimensions elsewhere in the app.
• The measure is the value the Discovery Agent monitors. This can be a master measure defined in the application, or an inline aggregation based on a field in the data model. Common examples are Sum(Sales), Sum(Margin), Count(Orders), or Sum(Cost). If you use a master measure, the Discovery Agent applies it exactly as defined, including any set analysis or complex expressions. If you define an inline aggregation, keep it simple. Very complex expressions can behave unpredictably in the context of insight calculations.
• A breakdown dimension instructs the Discovery Agent to calculate insights not only for the measure as a whole, but also separately for the values within a dimension. Instead of only monitoring total revenue, for example, you could monitor revenue per product category, per sales region, or per account manager. You can add a maximum of 3 breakdown dimensions per trigger, and each breakdown dimension can contain a maximum of 50 values. The total measure across all values is always calculated alongside the per-value calculations, so you don't lose the aggregated view by adding a breakdown. When configuring a breakdown dimension, you have four options for which values to include:
  • Values: manually select the specific values you want to track
  • Search: include values based on a text pattern
  • Condition: include values where the associated measure meets a condition, for example only categories with revenue above a certain threshold
  • Top/bottom: include only the N highest or lowest values based on their measure

  If you add a breakdown dimension but don't select specific values, the Discovery Agent uses the first 50 values in the dimension. That's often fine for small dimensions, but for a dimension with hundreds of values this can produce unexpected results. Be explicit about which values matter.

The eight insight types

Each insight type uses a different algorithm and suits a different analytical question. Understanding how each type works helps you make the right choice for each measure.

Spike detection (Spikes up / Spikes down)

Spike detection looks for individual data points that deviate strongly from the surrounding pattern and then return to normal. The key word is temporary: a spike is a one-off outlier, not the start of a sustained change.

Behind the scenes, the Discovery Agent establishes a dynamic baseline based on historical data and calculates how much variation is normal for this measure. A data point must fall significantly outside that expected range to qualify as a spike. The threshold is adaptive rather than fixed, meaning the algorithm adjusts to the natural volatility of the measure. A measure that normally fluctuates 20% week over week needs to move much more dramatically to trigger a spike insight than a measure that's typically very stable.

The minimum data requirement is just 4 data points for weekly and coarser aggregations, and 7 for daily. The relatively low threshold reflects the fact that spike detection is about comparing individual points to the local pattern, not fitting a complex model over a long history. This makes spike detection the best starting point if you're working with a dataset that doesn't yet have many months of history.

Use Spikes up and Spikes down for measures that are generally stable but sensitive to occasional outliers, such as error rates, returns, or call volumes.

Record high / Record low

These two types are conceptually the simplest: they check whether the most recent data point is the highest or lowest value ever recorded in the available history. No statistical model is needed, which is why the minimum data requirement is as low as for spike detection: 4 data points for non-daily aggregations and 7 for daily.

The insight is straightforward: your revenue last month was the highest in the dataset. Use these types for measures where records are meaningful, such as revenue, number of customers, or units sold.

Change in trend

This type looks for a significant shift in the direction or slope of the measure over time. It's not triggered by a single bad data point or a temporary spike; it looks for the moment when the measure's trajectory changes. A measure that was slowly declining starts to rise. Growth that was accelerating starts to flatten out.

To detect a meaningful trend change, the algorithm needs enough history to determine what the trend looked like before the change. That's why change in trend requires a minimum of 20 data points, regardless of the aggregation period. For monthly data, that's almost two years of history. For weekly data, it's about five months. If you enable this type on a dataset with too few data points, the algorithm can't distinguish a real trend change from normal fluctuation, and no insights will be generated.

Use this type for strategic KPIs where direction matters more than individual data points, such as market share, net promoter score, or employee turnover.

Change in baseline (New baseline)

Where change in trend detects a change in direction, change in baseline detects a sustained shift in the average level of the measure. Think of it as a measure finding a new normal. Your average daily order count sat consistently around 500 for six months and, after a product launch, stabilized at a new average of 650. That structural shift is what this type signals.

The algorithm compares recent values with the established historical average and determines whether the difference is large enough, and sustained enough, to represent a genuine new baseline rather than temporary noise. Like change in trend, this type requires 20 data points, since accurately characterizing the old baseline requires sufficient history.

Use this type for operational measures where the normal range itself is what matters most, such as average handling time, base conversion rate, or average order value.

Above model / Below model

These two types are the most advanced. Instead of comparing values to a simple historical average, the Discovery Agent builds a predictive model based on historical data and evaluates whether the actual values are significantly higher or lower than that model's prediction.

The model accounts for patterns in the data, including underlying trends and recurring cycles, when generating predictions. This makes above model and below model particularly valuable for measures with seasonal behavior. A spike detection algorithm might flag a spike in retail revenue in December as anomalous without realizing that December is always high. A model-based approach factors that seasonal pattern into the prediction and only triggers an insight if December is exceptionally high, even by December standards.

The minimum data requirement is 4 data points for non-daily aggregations and 7 for daily, the same as spike detection. The model can be built on a relatively small amount of data, but more history naturally produces better predictions. If your data has a strong seasonal component and you notice that spike detection produces too much noise, switching to above/below model is the logical next step.

Data volume requirements at a glance

Before creating your first trigger, it's worth understanding the minimum data requirements. Creating a trigger on a measure with insufficient data doesn't produce an error, but no insights will ever be generated either. That can be tricky to diagnose if you don't know what to look for.

When are insights generated?

The Discovery Agent evaluates insight triggers at most once a day, whenever the application data changes as a result of a refresh. If an application is refreshed multiple times a day, only the first refresh of that day triggers the insight evaluation.

There's an important distinction between the first evaluation and all subsequent ones:

• First evaluation: when you create a trigger and the data is updated for the first time, insights are calculated over the past seven data points. For a daily trigger that's seven days; for a monthly trigger that's seven months. Historical data beyond those seven points can be used as analytical context, but insights are only generated for the most recent seven.
• Subsequent evaluations: after that first update, the Discovery Agent only looks at data points that are new since the last evaluation. If you refresh daily, each daily refresh only generates insights for that day's new data.

This has a practical implication: if you create a trigger today on an application that's been running for years, your users won't immediately see a backlog of historical insights. They'll see insights for the past seven data points, and new insights will then appear as fresh data comes in.

One more timing detail worth knowing: current and future time periods are always excluded from insight calculations. A monthly trigger won't generate insights for the current month until that month has ended. This makes sense but is easy to forget when testing a newly created trigger and wondering why nothing appears.

Tips and tricks

Start with spike detection

When setting up triggers for the first time, start with Spikes up and Spikes down. They have the lowest data volume requirements and start generating insights quickly. Once you've confirmed the pipeline works end to end, you can gradually add more insight types.

Check your date fields before you begin

Before creating triggers, check that the date fields you want to use as the time dimension are actually loaded as date values in the data model. Open the data model viewer, find the field, and check whether its type shows as date or timestamp rather than as a text string. If it's a text string, update your load script with date() or timestamp() functions. This is one of the most common reasons a newly created trigger produces no insights, and it can be tricky to diagnose if you don't know what to look for.

Be deliberate in your choice of insight types

Enabling all eight insight types for every trigger feels thorough, but it results in a busy feed. Think about what each measure actually means. For a stable operational measure like average order value, spike detection and above/below model make sense. For a strategic KPI like net promoter score, change in baseline and change in trend are probably what you're looking for. Choose the types that match the question you're actually trying to answer.

Use breakdown dimensions strategically

Breakdown dimensions multiply the number of calculations and the number of insights in the feed. Adding a breakdown dimension with 50 product values means each evaluation now performs 51 calculations: 50 individual values plus the total aggregate. That's powerful, but only if the product-level breakdown is genuinely useful to your users. Start without breakdown dimensions, let users work with the aggregated insights first, and add breakdowns once you know which dimensions they actually want to filter on.

What publishing and duplicating do to your triggers

Insight triggers live within an application, but they're not carried over in every scenario. When you publish an application to a managed space, the triggers need to be recreated in the published version. When you duplicate an application, or export and re-import it, the same applies: triggers don't survive duplication.

Moving an application between spaces is the only scenario where triggers are preserved. Keep this in mind when planning your development and deployment workflow, especially if you maintain a development version of an app that you periodically publish to production.

Section access is a hard blocker

If your application uses section access for row-level security, insight triggers are not available for that application at all. This is a fundamental limitation of the current version of the Discovery Agent, not a configuration issue you can work around. Keep this in mind if section access is a requirement in your environment.

In the next part

Now that your insight triggers are configured and your refresh schedule is set, the Discovery Agent will start populating your users' feeds after the next data update. In part 3 of this series we'll switch perspective to the end user and look at how to effectively read and navigate the feed, how to use filters to cut through the noise, and how to use Qlik Answers to dig deeper into an insight that catches your attention.