QlikToDax

Scheduled reloads, reload tasks and task chains

Reload schedules and tasks in Power BI

A Qlik reload becomes a semantic model refresh in the Power BI service. On-premises sources need an on-premises data gateway. Chained tasks (load QVDs, then the app) become a Fabric Data Factory pipeline or an API-driven sequence.

Partial / different approach Power BI service Fabric

Short answer: In the workspace, open the semantic model's Settings → Scheduled refresh, set the times and time zone, and map data sources to a gateway connection if needed. Pro allows up to 8 scheduled refreshes a day; Premium/Fabric capacity allows up to 48. For "refresh A, then B" use a Fabric pipeline with the semantic model refresh activity.

What it does in Qlik

In Qlik Cloud you schedule an app's reload or chain reloads with tasks. In client-managed Qlik Sense, the QMC holds reload tasks with triggers on another task's success.

Qlik example

Qlik script
// Task 1: Extract.qvf  → stores QVDs (daily 05:00)
// Task 2: Model.qvf    → loads QVDs (trigger: on Task 1 success)
// Task 3: Dashboard.qvf → binary load of Model (on Task 2 success)

Power BI equivalent

Scheduled refresh

Semantic model → Settings → Refresh: turn on, add times, pick the time zone, and set failure notifications. Dataflows have the same setting; refresh the dataflow before the model.

Chained refresh (Fabric)

Build a Data Factory pipeline: a Dataflow Gen2 or notebook activity first, then a Semantic model refresh activity, connected on success. Schedule the pipeline instead of each item.

Gotchas and behaviour differences

  • A scheduled refresh on Pro has a 2-hour time limit; on Premium/Fabric capacity it is 5 hours. Very long Qlik reloads need to be split or moved upstream.
  • The gateway machine must be able to reach the source and stay on. It is the most common cause of failed refreshes after a migration.
  • After several consecutive failures the service turns scheduled refresh off. Set failure notifications to a monitored mailbox.
  • A thin report on a shared semantic model needs no refresh of its own. Only the model refreshes.

Official documentation

Related pages

WHERE Modified >= '$(vLast)' ... Concatenate ... WHERE NOT Exists(ID); STORE ... INTO x.qvd QVD incremental load The QVD incremental pattern (load the changes, append the old QVD rows not in the change set, store) has no file-level equivalent in Power BI. Use the incremental refresh policy on the semantic model, or in Fabric land the data in a Delta table with MERGE. Partial / different approach Extract.qvf → QVD layer 1 → Transform.qvf → QVD layer 2 → app QVD layers (extract, transform, model) to Fabric The classic multi-tier QVD architecture maps to Fabric's medallion lakehouse: raw data (bronze) → cleaned (silver) → modelled star schema (gold), with a semantic model on top. Without Fabric, Power BI dataflows are the reuse layer, but they are not a full QVD replacement. Partial / different approach STORE Orders INTO [lib://Data/Orders.qvd] (qvd); STORE INTO (writing QVDs) Power Query in Power BI Desktop can't write files. A query only feeds the model. Qlik's STORE pattern, transforming once, saving a QVD and reusing it, maps to Fabric: a Dataflow Gen2 with a data destination such as a Lakehouse table, a notebook writing Delta tables, or a Power BI dataflow that other models connect to. A Power BI dataflow (Gen1) only needs Pro licences, but it stores its output internally, not as files you manage. Without Fabric, the most robust answer is to store in your database or SQL views. Partial / different approach

Spotted an error or a better pattern? QlikToDax is maintained by a working BI consultant; corrections are welcome via the About page. Last reviewed 2026-10-25.