A customer recently asked a deceptively simple question: “How can we find every Qlik application that uses a particular field or calculation?”

Qlik already provides strong lineage and impact-analysis capabilities, and its APIs expose a wealth of information about applications, tables and fields. The difficulty appears when you want to bring that information together across a large Qlik estate and let users explore it as a single dataset.

That is the problem we have been working on in DevFulfilled. Rather than trying to replace Qlik’s own capabilities, we collect and enrich relevant metadata, expose it through a secure public API, and then use Qlik itself to analyse the result.

What are we trying to answer?

Imagine an organisation with tens or hundreds of Qlik applications. Before changing a source field or redefining a KPI, the analytics team may need to know:

• Which applications contain this field?
• What was the field called in the original source?
• Which master measures reference it?
• Are similar KPIs being calculated differently across applications?
• Which dashboards could be affected by a change?

The underlying metadata exists in several places, but answering estate-wide questions generally requires extracting, connecting and presenting it in a consistent form.

Storing the metadata in DevFulfilled

When DevFulfilled scans an application, it stores a structured representation of the application metadata. For fields, this can include the Qlik table name, original field name, alias, source type, source name and whether the field is acting as a key.

We also retain usage information across master dimensions, master measures, object dimensions, object measures and filters. Master measure records include details such as their title, label, description, tags and expression.

This gives us a useful layer above the individual application: metadata can be associated with its application, project and release, then searched across the wider estate.

Making the data available through an API

To make this information usable outside DevFulfilled, we introduced a versioned public API. The initial endpoints are:

GET /api/public/v1/applications
GET /api/public/v1/lineage/fields
GET /api/public/v1/master-measures

Requests are authenticated using a Bearer token in the standard HTTP Authorization header:

Authorization: Bearer YOUR_API_KEY

The key itself is shown only when it is generated. DevFulfilled stores a hash of the key, records when it was last used and allows an administrator to revoke it. This means the API can be consumed by tools such as Qlik without embedding a user’s DevFulfilled login details in a connection.

Responses are returned as JSON. For example, the applications endpoint provides the DevFulfilled application ID, Qlik application ID, name, description, status and last synchronisation time. The master-measures endpoint adds application, project and release context to each measure.

API Documentation 

Loading the API data into Qlik

Qlik’s REST Connector is a natural way to consume the API. A connection is configured with the DevFulfilled endpoint and an Authorization header. Pagination is enabled, and WITH CONNECTION can be used in the load script to call each endpoint through the same connection.

A simplified pattern looks like this:

RestConnectorMasterTable:
SQL SELECT
    "id",
    "qlik_app_id",
    "name",
    "description",
    "status",
    "last_synced_at"
FROM JSON (wrap on) "applications"
WITH CONNECTION (
    URL "https://your-domain/api/public/v1/applications"
);

Applications:
LOAD
    id              AS ApplicationID,
    qlik_app_id     AS QlikAppID,
    name            AS ApplicationName,
    description     AS ApplicationDescription,
    status          AS ApplicationStatus,
    last_synced_at  AS LastSyncedAt
RESIDENT RestConnectorMasterTable;

DROP TABLE RestConnectorMasterTable;

The precise generated SQL SELECT will depend on the JSON structure and REST Connector version, but the approach is straightforward: load each endpoint, give the fields consistent names, and associate them through the application ID.

Why put the result back into Qlik?

Because Qlik is exceptionally good at associative exploration. Once applications, fields, sources and measures are in one data model, users can select a field and immediately see the related applications, sources and calculations. They can start with a master measure and work in the opposite direction, or filter the estate by application, source type or project.

Our first DevFulfilled Lineage Explorer app provides overview metrics and searchable views for applications, fields, data sources and master measures. It is deliberately built as a Qlik application, so teams can extend it with their own sheets, visualisations and governance requirements.

Complementing Qlik rather than recreating it

The important architectural decision was to use Qlik’s capabilities first. DevFulfilled is not attempting to build another analytics engine or claim that Qlik has no lineage functionality.

Instead, DevFulfilled acts as the connecting layer: collecting metadata during the release workflow, retaining additional project and release context, and making the combined dataset easy to consume. Qlik then becomes the interface through which users investigate their own Qlik estate.

This first version already makes cross-application discovery much easier. The same foundation also creates opportunities for impact analysis, calculation standardisation and automated regression testing between environments—all starting from better visibility of what is actually inside each application.