If you manage a BI environment with dozens or even hundreds of dashboards, you have probably asked yourself at some point: Which apps are actually using this data source? It sounds like a simple question, but without the right tools or processes in place, finding a reliable answer can take far longer than it should. Understanding dashboard data source dependencies is one of those things that feels optional—until something breaks in production.

This article walks through the key questions around tracking data source usage across dashboards, from what it actually means to how you can do it efficiently. Whether you work with Qlik Sense, QlikView, Qlik Cloud, Power BI, or SAP BusinessObjects, the underlying challenge is the same: maintaining visibility into your BI app dependency structure so you can make changes with confidence.

What does it mean for a dashboard to use a data source?

A dashboard uses a data source when it actively loads, reads, or connects to an external file, database, or data layer to populate its visuals and metrics. In Qlik environments, this typically means the app’s load script references a QVD file, a database connection, or a flat file such as an Excel or CSV file. The data source is the origin of everything the dashboard displays.

In practice, a single dashboard can use multiple data sources simultaneously. One app might load customer data from a QVD, pull product information from a database, and reference a configuration file stored as an Excel sheet. Each of these connections represents a dependency. If any one of them changes, moves, or disappears, the dashboard is affected.

Understanding this relationship is the starting point for any serious approach to dashboard management. A dashboard is not a standalone object. It is the end result of a chain of data dependencies, and knowing where that chain begins matters enormously when you need to make changes or troubleshoot issues.

Why is tracking data source usage across dashboards important?

Tracking which dashboards use a specific data source lets you understand the impact of any change before you make it. If a QVD file is being restructured, renamed, or moved to a new location, knowing which apps depend on it tells you exactly what will break and what needs to be retested. Without that visibility, changes become guesswork.

There are several practical reasons why this kind of tracking matters for BI teams:

• Impact assessment: Before modifying a shared data source, you need to know how many dashboards rely on it and which teams or users those dashboards serve.
• Migration safety: When publishing apps from a development environment to production, or migrating from on-premises to Qlik Cloud, you need to confirm that all required data sources exist in the destination environment.
• Governance and compliance: In regulated industries such as healthcare or finance, being able to demonstrate that your data sources are correctly mapped and controlled is often a compliance requirement.
• Reducing production errors: Many production incidents originate from an unexpected dependency that no one tracked. Visibility prevents these surprises.

The more dashboards and data sources your environment contains, the more this tracking becomes a necessity rather than a nice-to-have. A small team with five apps can manage informally. A BI team managing hundreds of apps across multiple environments cannot.

How can you find which dashboards use a specific data source manually?

Manually finding which dashboards use a specific data source means reviewing the load scripts of individual apps one by one and searching for references to the data source in question. In Qlik Sense or QlikView, this involves opening each app’s data load editor and scanning the script for file paths, QVD references, or connection strings that match the source you are investigating.

This approach works for small environments but quickly becomes impractical. Here is a rough process for doing it manually:

1. Identify the data source you want to trace, for example, a specific QVD file path.
2. Open each app in your BI platform and navigate to the load script.
3. Search for the file name or path within the script.
4. Document which apps contain a reference to that source.
5. Determine whether the app is loading from the source, storing to it, or both.

The obvious limitation is time. In a deployment with fifty or more apps, this process can take hours. It is also error-prone. Scripts can reference the same file using different relative or absolute paths, making it easy to miss a dependency. There is also no easy way to track cross-app dependencies, for example, when a QlikView app creates a QVD that a Qlik Sense app then loads.

Manual tracking also produces a snapshot that becomes outdated the moment a developer modifies a script. For anything beyond a very small environment, an automated approach is worth considering.

What tools can automatically map data source dependencies in BI platforms?

Tools that automatically map data source dependencies in BI platforms work by extracting metadata from your apps and analyzing the load scripts or model definitions to identify which files, databases, and data layers each app references. This process is often called data lineage, and it gives you a structured, searchable view of your entire dependency landscape without requiring manual script reviews.

In the Qlik ecosystem, the options for this kind of automated mapping are limited within the native platform. Qlik Sense and QlikView do not offer built-in dependency tracking across apps out of the box. This is where Application Lifecycle Management tools fill the gap. A good ALM solution for Qlik will:

• Automatically extract metadata from all apps in your environment
• Identify which QVD files, Excel files, text files, and database connections each app uses
• Show which apps store QVDs and which apps load from them
• Surface cross-platform dependencies, for example, between QlikView and Qlik Sense apps
• Flag missing dependencies before a deployment reaches production

For Power BI and SAP BusinessObjects environments, similar principles apply. The goal is always the same: replace manual investigation with an automated, always-current map of how data flows through your BI landscape. Having this map available at any moment is what makes confident, low-risk changes possible. You can explore the full range of supported BI platform solutions to see how this applies to your specific environment.

How does PlatformManager show which dashboards use a specific data source?

We offer a data lineage feature that automatically maps QVD usage across your entire Qlik deployment, covering QlikView, Qlik Sense, and Qlik Cloud in one integrated view. You can see which apps are loading from a specific QVD, which apps are storing to it, and whether the paths are consistent across your environment. The information is extracted automatically from your apps, so there is no manual work involved.

Here is what you can find out directly through our data lineage view:

• Which apps are using a specific QVD file
• Which apps are storing (creating) a QVD file
• What the dependencies are between QlikView and Qlik Sense apps
• Whether QVDs are being loaded from the same location where they are being stored
• Which apps use Excel or text files as data sources

We also provide a Global Search function that lets you search for QVD files across all apps, even when you are not sure where they are being used. This is particularly helpful when you suspect a file is referenced somewhere but cannot locate it quickly. You can filter results at different levels to narrow down your analysis, and the Metadata dashboard gives you a high-level overview of all QVDs in use across your deployment.

When you publish an app from development to production, our platform also checks whether all required data sources are available in the destination environment. This prevents the common scenario where an app deploys successfully but fails to reload because a QVD it depends on does not exist in the target location. Extensions and reload tasks are treated as dependencies too, giving you a complete picture of what each app needs to function correctly.

When should you audit data source dependencies in your BI environment?

You should audit data source dependencies whenever a change is about to affect a shared resource, before any major deployment, and as a routine part of maintaining a healthy BI environment. The most common trigger is a planned change to a data source, such as restructuring a QVD, renaming a file, or moving data to a new server or cloud environment.

Beyond reactive audits, there are several situations where a proactive dependency review is worth scheduling:

• Before migrating to Qlik Cloud: Confirming that all data sources used by your on-premises apps are also available in the cloud environment prevents reload failures after migration.
• After onboarding new developers: New team members may create apps that reference data sources in inconsistent ways. An audit helps catch path mismatches or duplicate QVD usage early.
• During compliance reviews: If your organization operates under HIPAA, Sarbanes-Oxley, or similar frameworks, demonstrating that you know where your data comes from and how it flows through your dashboards is part of meeting governance requirements.
• When decommissioning a data source: Before retiring a file or database connection, verify that no active dashboards still depend on it.
• As part of release management: Before grouping apps into a release and pushing them to production, confirm that all dependencies are intact and consistent.

The frequency of these audits depends on how actively your BI environment changes. Teams that release new app versions frequently benefit from having dependency tracking built into their deployment workflow rather than treating it as a separate periodic task.

How PlatformManager helps you track dashboard data source dependencies

PlatformManager gives BI teams a clear, automated view of which dashboards use which data sources, without any manual script digging. Our data lineage feature extracts metadata directly from your Qlik Sense, QlikView, and Qlik Cloud apps and presents it in a structured, searchable format. Here is what we offer:

• Automated QVD usage mapping across QlikView, Qlik Sense, and Qlik Cloud in a single integrated view
• Global Search to find any QVD file across all apps, including ones you are not sure about
• Dependency checks before deployment to confirm that all required data sources exist in the destination environment
• Metadata dashboard for a high-level overview of all data sources in use across your deployment
• Support for Excel and text file dependencies alongside QVD tracking
• Extension and reload task management as part of your full dependency picture

All of this is available from a single PlatformManager installation, and all users are licensed to work with every supported BI solution without additional costs. The best way to see it in action is to start a free three-day trial with full access to our cloud server and a demo set of apps and data. No risk, no setup complexity—just a clear look at what your BI environment could look like with proper dependency tracking in place.