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 admin settings are in place and the right permissions have been configured, the next step is up to the app developer: creating insight triggers. This is where the Discovery Agent moves from potential to practice.

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

In this blog, we 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 app, on a sheet in edit or analysis mode. You don't need to leave the app or navigate to a separate admin interface. The insight trigger panel is accessible from the sheet toolbar, provided you have the right permissions.

An app 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 apps and measures you want to instrument first.

The four components of an insight trigger

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

• The time dimension is the date or timestamp field the Discovery Agent uses to track how your measure changes over time. It is the backbone of every trigger. There are two strict requirements for this field. First, it must contain real date or timestamp values, not text strings that look like dates. If your load script loads a date field as plain text rather than with a date function, the Discovery Agent cannot use it. Second, master dimensions are not supported as a time dimension. You have 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 metric the Discovery Agent monitors. This can be a master measure defined in the app, 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 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 monitoring only total revenue, you could, for example, monitor revenue per product category, per sales region or per account manager. You can add up to 3 breakdown dimensions per trigger, and each breakdown dimension can contain up to 50 values. The total measure across all values is always calculated alongside the per-value calculations, so you don't lose the aggregated picture 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 is often fine for small dimensions, but for a dimension with hundreds of values it can lead to 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. Once you understand how each type works, you can make the right choice for every measure.

Spike detection (Spikes up / Spikes down)

Spike detection looks for individual data points that deviate sharply 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 from the historical data and calculates how much variation is normal for this measure. A data point has to 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 by 20% week over week has to move far more dramatically to trigger a spike insight than a measure that is usually very stable.

The minimum data requirement is just 4 data points for weekly and coarser aggregations, and 7 for daily ones. This relatively low threshold reflects the fact that spike detection is about comparing individual points to the local pattern, not about fitting a complex model over a long history. That 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 prone 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 in the available history. No statistical model is required, which explains why the minimum data requirement is as low as for spike detection: 4 data points for non-daily aggregations and 7 for daily ones.

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 is not triggered by a single bad data point or a temporary spike; it looks for the moment the measure changes course. A measure that was slowly declining starts to rise. Growth that was accelerating begins to level off.

To detect a meaningful change in trend, the algorithm needs enough history to establish what the trend looked like before the change. That is why change in trend requires a minimum of 20 data points, regardless of the aggregation period. For monthly data, that is almost two years of history. For weekly data, it is roughly five months. If you enable this type on a dataset with too few data points, the algorithm cannot distinguish a real change in trend 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, settled at a new average of 650. That structural shift is what this type flags.

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, because accurately characterising the old baseline requires sufficient history.

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

Above model / Below model

These two types are the most advanced. Rather than comparing values with a simple historical average, the Discovery Agent builds a predictive model from the historical data and evaluates whether the actual values come out significantly higher or lower than that model's prediction.

The model takes patterns in the data into account, including underlying trends and recurring cycles, when generating predictions. That makes above model and below model particularly valuable for measures with seasonal behaviour. A spike detection algorithm might flag a peak in retail sales in December as anomalous without realising that December is always high. A model-based approach builds 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 ones, the same as spike detection. The model can be built from a relatively small amount of data, but more history naturally produces better predictions. If your data has a strong seasonal component and you find that spike detection produces too much noise, switching to above/below model is the logical next step.

Data volume requirements at a glance

Before you create your first trigger, it pays to understand 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 hard 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 app data changes as a result of a reload. If an app is reloaded several times a day, only the first reload of that day triggers the insight evaluation.

There is 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 last seven data points. For a daily trigger, that is seven days; for a monthly trigger, 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 reload daily, each daily reload only generates insights for that day's new data.

This has a practical implication: if you create a trigger today on an app that has been running for years, your users won't immediately see a backlog of historical insights. They will see insights for the last seven data points, after which new insights 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 is over. This makes sense, but it's easy to forget when you're testing a newly created trigger and wondering why nothing shows up.

Tips and tricks

Start with Spike detection

When you set 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 start

Before creating triggers, check that the date fields you want to use as a time dimension are actually loaded as date values in the data model. Open the data model viewer, find the field and check that its type is shown as date or timestamp rather than as a text string. If it is 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 hard 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 cluttered feed. Think about what each measure actually means. For a stable operational measure such as average order value, spike detection and above/below model make sense. For a strategic KPI such as net promoter score, change in baseline and change in trend are probably what you're after. Choose the types that match the question you are really 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 every evaluation now runs 51 calculations: 50 individual values plus the total aggregate. That is 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 inside an app, but they are not carried over in every scenario. When you publish an app to a managed space, the triggers have to be recreated in the published version. The same applies when you duplicate an app, or export and re-import it: triggers do not survive duplication.

Moving an app between spaces is the only scenario in which 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 app uses section access for row-level security, insight triggers are not available for that app at all. This is a fundamental limitation of the current version of the Discovery Agent, not a configuration issue you can work around. Take this into account if section access is a requirement in your environment.

In the next part

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