To expedite the investigation for Qlik Data Gateway - Direct Access cases, the following information is required.

Pre-requisites

• Verify the current installed version is the latest available from QMC in QCS. The version history is documented here:  Upgrading Qlik Data Gateway - Direct Access 
• Verify DG server specifications RAM\CPU meet minimum requirements. Setting up Qlik Data Gateway - Direct Access
• Confirm that the DG is a dedicated server and that no other Qlik or third-party products are installed. General limitations and considerations 
• Verify your DAG is in the best condition Qlik Data Gateway Direct Access: Basic Health Check

Mandatory Information

Without this information, Qlik Support cannot begin reviewing the issue.

• Tenant ID
• Data Gateway Logs (Ensure to zip and upload the entire logs folder)

C:\Program Files\Qlik\ConnectorAgent\data\logs​

• A copy of the configuration.properties file found in:

C:\ProgramData\Qlik\Gateway

• Windows Application and System event logs (Logs should cover the timeframe of the reported error, No other filtering should be applied). Events should be saved in .evtx format. How To collect Windows Event Logs
• The output from msinfo32 in .nfo format: How to gather additional hardware and system information from a Windows system by using MSInfo32
• If specific to an app, provide:
  • Tenant ID
  • App ID(s)
  • Reload ID(s)
  • Script logs from the specific app can be obtained from Reload History > Details from the hub
    Refer to How to find reload logs in Qlik Cloud for details on determining Reload IDs and collecting reload logs.
  • If multiple Qlik Data Gateways are configured, provide the Data Gateway ID from the Qlik Cloud Management Console.
• If specific to an incident (multiple app failures for a given time), indicate the date and time when the issue occurred. 

Environment

• Qlik Data Gateway - Direct Access,  all versions.

Qlik Sense Enterprise Client-Managed offers a range of Monitoring Applications that come pre-installed with the product.

Qlik Cloud offers the Data Capacity Reporting App for customers on a capacity subscription, and additionally customers can opt to leverage the Qlik Cloud Monitoring apps.

This article provides information on available apps for each platform.

Content:

• Qlik Cloud
• Data Capacity Reporting App
• Access Evaluator for Qlik Cloud
• Answers Analyzer for Qlik Cloud
• App Analyzer for Qlik Cloud
• Automation Analyzer for Qlik Cloud
• Entitlement Analyzer for Qlik Cloud
• Reload Analyzer for Qlik Cloud
• Report Analyzer for Qlik Cloud
• How to automate the Qlik Cloud Monitoring Apps
• Other Qlik Cloud Monitoring Apps
• OEM Dashboard for Qlik Cloud
• Monitoring Apps for Qlik Sense Enterprise on Windows
• Operations Monitor, License Monitor, and Content Monitor
• App Metadata Analyzer
• The Monitoring & Administration Topic Group
• Other Apps

Qlik Cloud

Data Capacity Reporting App

The Data Capacity Reporting App is a fully supported app distributed within the product. For more information, see Qlik Help.

You can automate daily distribution of the latest app using the Capacity consumption app deployer template in Qlik Automate.

Access Evaluator for Qlik Cloud

For more information, see Qlik Cloud Access Evaluator.

Answers Analyzer for Qlik Cloud

For more information, see Qlik Cloud Answers Analyzer.

App Analyzer for Qlik Cloud

For more information, see Qlik Cloud App Analyzer.

Automation Analyzer for Qlik Cloud

For more information, see Qlik Cloud Automation Analyzer.

Entitlement Analyzer for Qlik Cloud

The Entitlement Analyzer is a Qlik Sense application built for Qlik Cloud, which provides Entitlement usage overview for your Qlik Cloud tenant for user-based subscriptions.

The app provides:

• Which users are accessing which apps
• Consumption of Professional, Analyzer and Analyzer Capacity entitlements
• Whether you have the correct entitlements assigned to each of your users
• Where your Analyzer Capacity entitlements are being consumed, and forecasted usage

For more information, see The Entitlement Analyzer.

Reload Analyzer for Qlik Cloud

For more information, see Qlik Cloud Reload Analyzer.

Report Analyzer for Qlik Cloud

For more information, see Qlik Cloud Report Analyzer.

How to automate the Qlik Cloud Monitoring Apps

Do you want to automate the installation, upgrade, and management of your Qlik Cloud Monitoring apps? With the Qlik Cloud Monitoring Apps Workflow, made possible through Qlik's Application Automation, you can:

1. Install/update the apps with a fully guided, click-through installer using an out-of-the-box Qlik Application Automation template. 
2. Programmatically rotate the API key that is required for the data connection on a schedule using an out-of-the-box Qlik Application Automation template. This ensures that the data connection is always operational. 
3. Get alerted whenever a new version of a monitoring app is available using Qlik Data Alerts. 

For more information and usage instructions, see Qlik Cloud Monitoring Apps Workflow Guide.

Other Qlik Cloud Monitoring Apps

OEM Dashboard for Qlik Cloud

For more information and to download the app and usage instructions, see Qlik Cloud OEM Dashboard & Console Settings Collector.

With the exception of the Data Capacity Reporting App, all Qlik Cloud monitoring applications are provided as-is and are not supported by Qlik. Over time, the APIs and metrics used by the apps may change, so it is advised to monitor each repository for updates and to update the apps promptly when new versions are available.

If you have issues while using these apps, support is provided on a best-efforts basis by contributors to the repositories on GitHub.

Monitoring Apps for Qlik Sense Enterprise on Windows

Operations Monitor, License Monitor, and Content Monitor

The Operations Monitor loads service logs to populate charts covering the performance history of hardware utilization, active users, app sessions, results of reload tasks, and errors and warnings. It also tracks changes made in the QMC that affect the Operations Monitor. 

• Basic information can be found in Operations Monitor | help.qlik.com
• Detailed descriptions of sheets and visualizations are accessible in the About the Operations Monitor story available from the app overview page under Stories

The License Monitor loads service logs to populate charts and tables covering token allocation, usage of login and user passes, and errors and warnings.

• Basic information can be found in License Monitor | help.qlik.com  
• Detailed descriptions of sheets and visualizations are accessible in the About the License Monitor story available from the app overview page under Stories

The Content Monitor loads from the APIs and logs to present key metrics on the content, configuration, and usage of the platform, allowing administrators to understand the evolution and origin of specific behaviors of the platform.

• Basic information can be found in Content Monitor | help.qlik.com  
• Each sheet in the Content Monitor includes an About text box to describe its content. 
  

All three apps come pre-installed with Qlik Sense. 

Qlik Support can only be provided for Apps pre-installed with your latest version of Qlik Sense Enterprise on Windows. 

App Metadata Analyzer

The App Metadata Analyzer app provides a dashboard to analyze Qlik Sense application metadata across your Qlik Sense Enterprise deployment. It gives you a holistic view of all your Qlik Sense apps, including granular level detail of an app's data model and its resource utilization.

Basic information can be found here: 

App Metadata Analyzer (help.qlik.com)

For more details and best practices, see: 

App Metadata Analyzer (Admin Playbook)

The app comes pre-installed with Qlik Sense.

The Monitoring & Administration Topic Group

Looking to discuss the Monitoring Applications? Here we share key versions of the Sense Monitor Apps and the latest QV Governance Dashboard as well as discuss best practices, post video tutorials, and ask questions.

Monitoring & Administration 

Other Apps

LogAnalysis App: The Qlik Sense app for troubleshooting Qlik Sense Enterprise on Windows logs 
Sessions Monitor, Reloads-Monitor, Log-Monitor 
Connectors Log Analyzer 

All Other Apps are provided as-is and no ongoing support will be provided by Qlik Support.

This article explains how the initial extract and load process differs between legacy connectors and Qlik Talend Cloud native connectors, so you know what to expect from each.

Legacy connectors

For legacy connectors, the initial connection, extract, and load involved two major steps:

1. Metadata discovery through data sampling. Legacy connectors used data sampling to define the target schema. The larger the sample, the more accurate the generated schema. However, a large sample could require extracting most or all of the data, which could take up to several days before the target destination was created. Legacy connectors loaded the data extracted during sampling into a staging area, for use in the initial full load.
2. Initial full data load. If full data extraction was used during metadata discovery, this load was fast, because the data was loaded directly from the staging area.

Qlik Talend Cloud native connectors

Qlik Talend Cloud native connectors work differently. There is no separation between preparation and data load. When a connection to a SaaS application is made, Qlik Talend Cloud begins replicating both recent and historical data.

During connection setup, you choose the start date for historical data — either the default or a custom date. By default, the connector requests 12 months of history, controlled by the Start Date setting. This date can be changed to capture anywhere from a few months to several years of historical data.

It's expected for the first run of any new dataset to take longer than later runs. Qlik Talend Cloud must extract the full backlog of historical data, so that it can track changes over time in future runs, and then load that data into the target. Each phase — extraction and loading — has its own expected limitations.

The time a historical replication takes can be affected by the connector's API quota. API rate limits also play a part: source applications restrict how many requests can be made in a given period, so the connector can't continuously request everything at once, or send thousands of API calls per second. Some integrations, such as Salesforce and Marketo, use API quotas that limit API usage. Qlik's integrations are designed not to consume all of the available quota, but using the same API elsewhere can use up that quota.

Completing the initial extract and load can take hours, and sometimes days, depending on the amount of historical data, the API quota, and API rate limits.

After the initial extract and load is complete, subsequent loads are expected to be fast for connectors that support change data capture (CDC), using Qlik Talend Cloud's bookmark technology.

Key differences

Environment

• Qlik Talend Cloud

Starting with the release of Talend Studio R2026-10, Talend Studio adopts a new structured patching release model. For the original announcement, see Upcoming changes to the Talend Studio Lifecycle and Release Schedule.

Beginning with the Talend Studio R2026-10 release, two Patch Release options are available for Talend Studio:

• Monthly Releases: continue the traditional Talend Studio patching model.
• Support Releases: a Support Release (SR) is a lighter version of the monthly release that focuses on CVE and security fixes and excludes new features, allowing an upgrade without taking on new functionality.

The Patch Releases can be identified as follows:

See Update paths | Talend Installation Guide for an overview and supported update paths. When viewing, verify that you are looking at the correct version.

Monthly Releases

Monthly Releases continue the traditional Talend Studio patching model.

• Immediate access to new features, improvements, and previews.
• Continue using the same patch naming and versioning convention, RYYYY-MM. Examples: R2026-10, R2027-01, R2027-06.
• Patch updates, such as Java or Camel framework changes, require revalidation and republishing for multiple jobs.
• Monthly Releases are the only way to access preview features — for example, the Studio AI Assistant and new components (tAPIContract, tAPIOperations).
• Latest Monthly Release update site: https://update.talend.com/Studio/8/Updates/latest
• Specific Monthly Release update site pattern: https://update.talend.com/Studio/8/Updates/RYYYY-MM

Support Releases

A Support Release (SR) is a lighter version of the monthly release that focuses on CVE and security fixes and excludes new features, allowing an upgrade without taking on new functionality.

• Every October Monthly Release serves as the baseline for a new Support Release cycle (format: RYYYY-10-SRnn). The October patches are still Monthly Releases, and are applied as a standard patch.
• R2026-10 is the first baseline of the new patching lifecycle. The next 11 Support Releases (R2026-10-SR01 to SR11) are delivered monthly from November 2026 to September 2027.
• R2027-10 is the baseline for the next cycle, and so on every October. Talend Studio retains 8.0.1 versioning under the new lifecycle — for example, 8.0.1 R2026-10, 8.0.1 R2027-10.
• Patch installation to Talend Studio follows the same process as standard Monthly Releases.
• Patches address security and CVE maintenance. Security and critical fixes can be applied quickly, without touching features in production.
• With fewer changes included, validating and republishing jobs after a patch is generally faster for Support Releases.
• Unlike Monthly Releases, SR patches do not include new features.
• Support Releases use the naming convention RYYYY-10-SRnn:
  • RYYYY-10 identifies the baseline release (for example, R2026-10, R2027-10).
  • SRnn identifies the sequential Support Release number.
  • Examples: R2026-10-SR01 (November 2026), R2026-10-SR02 (December 2026).
• Latest Support Release update site: https://update.talend.com/Studio/8/Updates/latest-SR
• Specific Support Release update site pattern: https://update.talend.com/Studio/8/Updates/RYYYY-10-SRnn
  
  

Extended Support

• After 12 months, moving to the next baseline release (R2027-10) is recommended. Customers on the Support Release track who are unable to upgrade immediately have the option to stay on the Extended Support track for up to six additional months.
• Extended Support Releases follow the same naming and versioning convention as Support Releases (RYYYY-10-SRnn) — for example, R2026-10-SR12 and R2026-10-SR13.
• Extended Support Releases are provided only upon request. Although up to six releases are possible during the six-month window, typically only a couple of patches are issued.
• Extended Support Releases are limited to critical CVE remediation and severe production-blocking issues. Medium- and low-severity CVEs are not addressed.

Timeline

This timeline is projected; changes are possible.

Upgrade Paths

With the introduction of Monthly Releases and Support Releases, only specific upgrade paths are supported. The general rule with patching is to move forward. It is not possible to downgrade.

See Update paths | Talend Installation Guide for more information and a detailed table. When viewing, verify that you are looking at the correct version.

Supported Upgrade Paths

• Monthly Release → Monthly Release: customers on the Monthly Release track can upgrade to a newer Monthly Release.
• Support Release → Support Release: customers on the Support Release track can upgrade to newer Support Releases.
• Support Release → Monthly Release: customers on the Support Release track may move to a newer Monthly Release at any time. Once on the Monthly Release track, there is no way to revert to the Support Release track until the next annual baseline release.
• Monthly Release → Next Annual Cycle Support Release: moving from a Monthly Release to a Support Release is supported if the Support Release belongs to the next annual cycle (for example, a 2026 Monthly Release to a 2027 Support Release).
• R2024-05 or later is required to adopt the new lifecycle. Customers on R2024-04 or earlier must first upgrade to R2024-05 or later, then move to R2026-10 or higher.
• Extended Support Release → Next Annual Cycle Support Release: migrating from Extended Support to the next annual Support Release is supported. All cumulative fixes from the next Monthly Release baseline patch are applied after upgrading.

Unsupported Upgrade Paths

• Monthly Release → Support Release: once on the Monthly Release track, there is no reverting to a Support Release associated with the same baseline release. This path is only possible if the Support Release belongs to the next annual cycle.
• Support Release → Monthly Release (same month): upgrading from a Support Release to a Monthly Release released the same month is not possible.
• Monthly Release → Previous Monthly Release: Talend Studio does not allow rollback or downgrade of patching.
• Support Release → Previous Support Release: Talend Studio does not allow rollback or downgrade of patching.
• Old Monthly Release → New Monthly Track: Talend Studio versions R2024-04 and earlier can't be upgraded directly to R2026-10 or later. Use an intermediate patch jump for an existing installation, or install Talend Studio fresh.

Talend Runtime

Talend Runtime follows the same lifecycle model as Talend Studio:

• Monthly Releases: include new features, improvements, and updates to bundled components (for example Java or Apache Camel versions), as well as CVE fixes.
• Support Releases: focus on CVE and security fixes only, with no new features and no change to bundled framework versions. Baseline and cadence are the same as Studio (October baseline, SR01 to SR11, then Extended Support on request).
• Naming convention: same RYYYY-10-SRnn format.
• Upgrade rules are identical (forward only, no downgrade, no return to the Support track within the same cycle once on Monthly).

To limit revalidation of jobs, routes and services at each patch, use the same track for Talend Studio and Talend Runtime in a given environment.

Which Path to Choose?

• For customers with no constraints on adopting existing Talend Studio patches, the recommendation is to continue with the existing Monthly Release track, since it includes all CVE fixes and the latest features.
• Customers with longer QA and deployment cycles may prefer the Support Release track, since it allows staying current on CVE fixes with minimal changes to Talend Studio.

Delayed Sync allows client-managed products to operate without internet access before connectivity to Qlik's License Backend Server (LBE) is required. By default, new licenses provide 90 days of temporary offline access.

Delayed Sync has been available since April 2020. It is supported in the following products:

• Qlik Sense Enterprise on Windows April 2020 or later
• Qlik NPrinting April 2020 or later
• QlikView April 2019 or later 

For Delayed Sync to be possible, a portable Signed License Definition (SLD) needs to be retrieved. The product can then be activated using the portable SLD.

Delayed Sync is not a permanent offline solution. A connection to the license backend must be made within 90 days of new license creation (not license activation). If an extension or a more permanent solution is required, contact Qlik Support via Chat or by raising a case via Support portal before the 90 days are reached. The 90 period will not reset. See Request license off-line approval - April 2020 and onwards for details on how to move to a permanent solution.

 

For old license which needs an extension on the temporary offline feature (Delayed Sync) do reach out to Qlik Support via Chat or by raising a case via Support portal.

When the connection to the LBE is made, the SLD will be automatically updated to SLK.

Prerequisites

• Qlik Sense Enterprise April 2020, Qlik NPrinting April 2020, and QlikView (April 2019 or later installed and ready to license
• The license must include the attribute: DELAYED_SYNC;YES;;[enddate] or OFFLINE;YES;;

Steps:

Step 1: Retrieve the portable Signed License Definition 

The SLD needs to be retrieved from the license backend server. Internet connectivity is required. To obtain the definition, use: Retrieve using Get Signed License Definition link

If you receive the error Unauthorized or Invalid SLK, verify that you have copied the Signed License Key correctly. Missing letters, extra letters, or unexpected linebreaks are the most common root cause.

Step 2: Activate the product using the SLD

The example provided uses the April 2020 Release of Qlik Sense Enterprise on Windows. Qlik NPrinting and QlikView function identically, though the license SLD will need to be applied in the individual product's license field.

1. Open up the Qlik Sense Management Console and when prompted, insert the Signed License Key (SLK).
   
   If port 443 is not open or no internet connectivity is available, the following error will appear:
   
   
   
    
2. Delete the SLK from the text box in the Qlik Sense Enterprise Management Console site license page
   
   
3. Paste the full SLD (previously retrieved using either Postman or PowerShell) in the same text box and click Apply.
   
   
   
   
4. The license will be applied once the message Successfully Updated appears in a green banner (as below):
   
   
   

Related Content:

Qlik License Service: the advantages of QLS activation
Viewing Qlik Sense license definition allotments using PowerShell

The following release notes cover the Qlik PostgreSQL installer (QPI) version 1.2.0 to 2.1.0.

Content

• What's New
• 2.1.0 September 2025 Release Notes
• Known Limitations (2.1.0)
• 2.0.0 May 2025 Release Notes
• Known Limitations (2.0.0)
• 1.4.0 December 2023 Release Notes
• Known Limitations (1.4.0)
• 1.3.0 May 2023Release Notes
• Known Limitations (1.3.0)
• 1.2.0 Release Notes

What's New

• The PostgreSQL version used by QPI has been updated to 14.17
• An upgrade of an already upgraded external instance is now possible
• Support for an upgrade of the embedded 14.8 database was added
• Silent installs and upgrades are supported beginning with Qlik PostgreSQL Installer 1.4.0 and later. QPI can now be used with silent commands to install or upgrade the PostgreSQL database. (SHEND-973)

2.1.0 September 2025 Release Notes

Known Limitations (2.1.0)

• Rollback is not supported.
• The database size is not checked against free disk space before a backup is taken.
• Windows Server 2012 R2 does not support PostgreSQL 14.17. QPI cannot be used on Windows Server 2012 R2.
• QPI will only upgrade a PostgreSQL instance that only contains Qlik Sense Databases (QSR, SenseServices, QSMQ, Licenses, QLogs, etc.)

2.0.0 May 2025 Release Notes

Known Limitations (2.0.0)

• Rollback is not supported.
• The database size is not checked against free disk space before a backup is taken.
• Windows Server 2012 R2 does not support PostgreSQL 14.17. QPI cannot be used on Windows Server 2012 R2.
• QPI will only upgrade a PostgreSQL instance that only contains Qlik Sense Databases (QSR, SenseServices, QSMQ, Licenses, QLogs, etc.)

1.4.0 December 2023 Release Notes

Known Limitations (1.4.0)

• QB-24990: Cannot upgrade PostgreSQL if Qlik Sense was installed in a custom directory such as D:\Sense. See Qlik PostgreSQL Installer (QPI): No supported existing Qlik Sense PostgreSQL database found.
• Rollback is not supported.
• Database size is not checked against free disk space before a backup is taken.
• QPI can only upgrade bundled PostgreSQL database listening on the default port 4432. Using QPI to upgrade a standalone database or a database previously unbundled with QPI is not supported.
• Cannot migrate a 14.8 embedded DB to standalone
• Windows Server 2012R2 does not support PostgreSQL 14.8. QPI cannot be used on Windows Server 2012R2.

1.3.0 May 2023 Release Notes

After a Stop and Resume operation on a Qlik Replicate Log Stream task with an IBM Db2 for i source, a subset of tables begins receiving NULL values in the RRN column.

When RRN is configured as the primary key for those tables, downstream merge processes fail with errors similar to:

DML operation to table DB2I_TABLE failed on column RRN with error:
NULL result in a non-nullable column

Environment

• Qlik Replicate

Resolution

1. Confirm that the Log Stream parent task's source endpoint is configured with Add RRN column to tables without a Primary Key or Unique Index rather than Add RRN column to all tables. This mismatch is the source of the NULL RRN values.
2. Because the parent task is current, and changing the endpoint setting would affect every table in the task, remove the affected tables from the existing parent/child task set.
3. Create a new source endpoint with Add RRN column to all tables enabled.
4. Create a new parent task using the new endpoint.
5. Create corresponding child tasks targeting the same Snowflake target tables.
6. Reload the affected tables within the new task to re-establish correct RRN population.
7. Confirm that data flows correctly, and that RRN values are no longer NULL.

Cause

The Log Stream parent task's source endpoint has the RRN setting configured as Add RRN column to tables without a Primary Key or Unique Index, instead of Add RRN column to all tables.

This misconfiguration causes RRN values to be NULL for the tables processed by the affected parent task, while other parent tasks with the correct setting continue to populate RRN correctly.

Internal Investigation ID(s)

SUPPORT-11485

When an OSGi, ESB, or microservice job bundle is exported, Talend Studio removes the dependencies of TCK (component-runtime) components from the bundle’s lib/. 

This leads to talendcsv-1.1.0.jar being missing.  

Testing works fine within Talend Studio, but when it's built, the KAR/CAR is missing the talendcsv-1.1.0.jar dependency, and the route fails with:

java.lang.NoClassDefFoundError: com/talend/csv/CSVReader

Affected Versions

• Talend Studio R2026-07
• Salesforce components
• Snowflake components

Resolution

This is caused by QAPPINT-3212 and QAPPINT-2379.

Fix Version

A fix is expected in the November 2026 release for Talend Studio. Review the relevant release notes for QAPPINT-3212 and QAPPINT-2379 once available and upgrade as needed.

Workaround

No workaround is available. 

Internal Investigation ID(s)

QAPPINT-3212 and QAPPINT-2379

Information provided on this defect is given as is at the time of documenting. For up-to-date information, please review the most recent Release Notes or contact support with the IDs QAPPINT-3212 and QAPPINT-2379 for reference.

When using Qlik Replicate with a Salesforce Incremental source, a record that's created and deleted within a short period may be replicated as an INSERT event containing IsDeleted=TRUE, followed by a separate DELETE event in a later capture round.

This behavior occurs when the record's CreatedDate falls within the current capture window, but its deletion timestamp (SystemModstamp) falls outside that window.

The SOURCE_CAPTURE component logs the following message at VERBOSE logging level:

delete time (modification time) is after end of this round, sending insert, delete will be sent in the next round with modification time

The INSERT is applied to the target before the corresponding DELETE is captured. In the reported case, the DELETE arrived during the next capture round, and the target eventually reflected the deletion.

Environment

• Qlik Replicate

Resolution

Verify that the DELETE event is captured and applied in a subsequent capture round.

Check the source capture log

1. Enable VERBOSE logging temporarily for SOURCE_CAPTURE, if additional evidence is required.
2. Search the log for messages indicating that a deletion timestamp falls outside the current capture window, and that the DELETE will be sent in a later round.
3. Return logging to its normal level after troubleshooting.

Verify the CDC events

For the affected Salesforce record, confirm that:

1. An INSERT event was captured with IsDeleted=TRUE.
2. A corresponding DELETE event was captured in a subsequent round.
3. Both events refer to the same Salesforce record identifier.

If Store Changes is enabled, review the corresponding change table and its operation header.

Verify the target state

For tasks using Apply Changes, confirm that the DELETE was eventually applied, and that the record no longer exists in the final target table.

For tasks using Store Changes, the INSERT and DELETE may remain as separate events in the change table. Downstream applications must process the operation header in the correct event order.

Check replication latency

If there's a delay between the INSERT and DELETE:

1. Review the Salesforce source polling interval and relevant capture settings.
2. Check for source API delays or errors.
3. Verify that the task remains active, and continues capturing changes.
4. Check target apply latency and any pending changes.

Adjust timing-related settings only after reviewing their expected impact and the applicable Qlik documentation.

Important considerations

• An INSERT containing IsDeleted=TRUE should not automatically be interpreted as a DELETE operation.
• For change tables, use the CDC operation header, such as header__change_oper, to identify the operation type.
• The INSERT followed by DELETE sequence may be expected when the events fall into different capture windows.
• Do not enable Apply Changes using SQL MERGE as the resolution for this scenario, as Salesforce is an unsupported source for this option (see Change Processing Tuning | help.qlik.com).

Cause

Qlik Replicate's Salesforce Incremental source captures changes using time-based polling windows.

In the reported scenario, the record was created within one capture window, and deleted shortly afterward. The record's creation timestamp was eligible for the current capture round, but its deletion timestamp was beyond that round's end boundary. As indicated by the SOURCE_CAPTURE verbose log, Qlik Replicate emits the INSERT during the current round, and defers the DELETE until the next eligible capture round. This can temporarily result in a target record containing IsDeleted=TRUE before the DELETE event is applied.

The IsDeleted field represents Salesforce record data, and shouldn't be confused with the CDC (change data capture) operation type.

This sequence is consistent with the Salesforce Incremental source's time-window processing. The available case evidence doesn't establish a missing change event or a product defect.

Internal Investigation ID(s)

SUPPORT-9606

While using the AVRO message format and a partition-by-primary-key, Qlik Replicate tasks that replicate from IBM Db2 for i to a Confluent Kafka target route rows from different tables sharing the same primary key value to different Kafka partitions. 

The expected behavior is that a custom primary key column, defined identically across all tables, produces the same AVRO key message, causing Kafka to route all matching rows to the same partition. The observed behavior is that the same key value in two different tables lands in different partitions.

Environment

• Qlik Replicate

Resolution

Option 1: Use the enableNamespaces internal parameter

1. In the Qlik Replicate task, go to the target endpoint Advanced settings.
2. Add the internal parameter enableNamespaces, and set its value to false.
3. Save the endpoint setting, and resume the task.

Note: Setting enableNamespaces to false removes the namespace from both the key message schema and the value (data record) message schema.

Option 2: Edit the message format namespace directly

1. In the task settings, open the Message Format configuration for the AVRO key.
2. Remove TARGET_TABLE_NAME from the namespace definition. If the tables belong to different owners, also remove TARGET_TABLE_OWNER. If the tables are split across multiple tasks, also remove TASK_NAME.
3. Make sure the resulting namespace is identical for all tables that must share the same partition.
4. Save the task settings, and resume the task.

Cause

When producing AVRO messages, Qlik Replicate includes the table namespace in the AVRO key message schema. Because the namespace contains the table name (and, optionally, the table owner and task name), two tables with the same primary key value produce two different AVRO key schemas. Kafka's partitioning logic treats these as distinct keys, and routes them to different partitions, even though the key values are identical.

Internal Investigation ID(s)

SUPPORT-10509

This article provides details about the new permissions available for Private automations, which will replace the previous Automation Creator role.

You can assign these permissions to a custom role or the User Default. More information about creating & managing custom roles is available here.

The existing Automation Creator role will be deprecated later in 2026.

Private automations

These permissions allow users to run and create automations in their personal space.

Shared automations

Earlier in 2025, we introduced the shared automation permission that allows users to run, create, and manage automations in shared spaces in which they have the correct permissions. More information about which space roles are required for the various automation actions is available here:

• Full & Professional users
• Analyzer users

In Qlik Talend Data Integration, a pipeline task using an Oracle source may suspend a table during initialization when the Oracle connection user does not have sufficient privileges to enable supplemental logging.

The task log reads:

Table 'WIP'.'WIP_SAMPLE' (subtask 1 thread 0) is suspended.
ORA-01031: insufficient privileges;
Failed to execute statement
<ALTER TABLE "WIP"."WIP_SAMPLE"
ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS>;
Failed adding supplemental logging for table "WIP"."WIP_SAMPLE";
Failed to init unloading table 'WIP'.'WIP_SAMPLE'

The issue occurs when Qlik attempts to enable supplemental logging on the Oracle source table, but the connection user does not have the required ALTER privilege.

Setting the internal property addSupplementalLogging to false was also reported not to resolve the issue when the required supplemental logging was missing.

Environment

• Qlik Talend Data Integration

Resolution

Option 1: Manually enable supplemental logging on the affected Oracle tables

This is the recommended option when the Qlik connection user cannot modify tables.

Step 1: Verify database-level supplemental logging

Ask the Oracle database administrator to run:

SELECT SUPPLEMENTAL_LOG_DATA_MIN
FROM V$DATABASE;

The expected value is YES or IMPLICIT.

If database-level supplemental logging is not enabled, have the DBA enable it using the appropriate Oracle procedure.

Step 2: Check table-level supplemental logging

Run:

SELECT OWNER, TABLE_NAME, LOG_GROUP_TYPE
FROM ALL_LOG_GROUPS
WHERE OWNER = 'WIP'
  AND TABLE_NAME = 'WIP_SAMPLE';

Check whether an ALL COLUMN LOGGING entry exists.

Step 3: Enable supplemental logging if missing

Using an authorized Oracle account, execute:

ALTER TABLE WIP.WIP_SAMPLE
ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Repeat for other affected tables as needed.

Step 4: Verify the configuration

SELECT COUNT(*)
FROM ALL_LOG_GROUPS
WHERE OWNER = 'WIP'
  AND TABLE_NAME = 'WIP_SAMPLE'
  AND LOG_GROUP_TYPE = 'ALL COLUMN LOGGING';

A result greater than zero confirms that the ALL COLUMNS supplemental log group exists.

Option 2: Grant the Oracle connection user the required permission

If Qlik Cloud Data Integration is expected to manage supplemental logging automatically, the DBA can grant ALTER on the required source tables:

GRANT ALTER ON WIP.WIP_SAMPLE
TO <qlik_oracle_user>;

When automatic supplemental logging is used with table-list patterns, review Qlik's documented requirement for ALTER ANY TABLE.

Grant broader privileges only when necessary and approved by the customer's security team.

Step 5: Resume the affected task

After correcting the privileges or enabling the required supplemental logging:

1. Resume or restart the affected data task as appropriate.

2. Confirm that the table is no longer suspended.

3. Verify that table initialization completes.

4. Confirm that CDC processing continues without ORA-01031 or supplemental logging errors.

The internal property addSupplementalLogging should only be modified under Qlik Support guidance. It should not be used as a substitute for configuring the required Oracle supplemental logging.

Cause

Qlik Talend Data Integration requires appropriate supplemental logging on the Oracle source to capture changes through CDC.

By default, the Oracle source connector can enable the required table-level supplemental logging automatically.

If the Oracle connection user does not have the necessary ALTER privilege on the source table, Oracle rejects the statement with error ORA-01031, and the table may be suspended during task initialization.

Supplemental logging must still be configured when it is managed manually. Disabling automatic supplemental logging does not remove the underlying CDC logging requirements.

In the reported case, setting the internal property addSupplementalLogging to false did not allow initialization to proceed without the required table-level logging.

Related Content

• Oracle Prerequisites | Qlik Cloud 
• Oracle Required permissions | Qlik Cloud 

Internal Investigation ID(s)

SUPPORT-10803

In Qlik Talend Data Integration, users who have access to a data space through group membership do not receive email notifications for pipeline task events.

The following behavior was observed:

• Users added directly to the space receive task notifications as expected.

• Users who access the same space through a group do not receive notifications.

• Email notifications are enabled at the tenant level, and tenant administrators can successfully send test emails.

• The issue affects notification delivery rather than task execution.

This is a documented Qlik Cloud notification limitation, rather than an issue with the configured email provider.

Environment

• Qlik Talend Data Integration

Resolution

Add affected users directly to the Qlik Cloud data space.

1. Sign in to Qlik Cloud with an account authorized to manage space members.

2. Navigate to the data space containing the affected pipeline tasks.

3. Open Space settings > Members.

4. Add the affected users individually with the appropriate space roles.

5. Ask each user to open their profile settings and confirm that email notifications for data task events are enabled.

6. If necessary, check the space-level and individual task notification settings, as these can override the default notification preferences.

7. Trigger an appropriate task event and verify that the directly assigned users receive the expected email notifications.

• Users can retain their existing group membership. Direct space membership is needed for notification eligibility.
• Confirm that an email provider is configured for the Qlik Cloud tenant.
• Adding a distribution list or group instead of individual users does not resolve this limitation.
• This solution applies until Qlik introduces support for notifications to group-based space members.

Cause

Qlik Cloud does not support sending space-related notifications to users who access a space only through group membership.

Although group membership provides access to the space and its resources, it does not make individual group members eligible to receive notifications from that space.

Users must be added directly to the space to receive supported space and task notifications, subject to their notification preferences and permissions.

This behavior is documented in Qlik Cloud Managing space notifications.

Related Content

• Setting notifications for changes in operation 
• Qlik Cloud Managing space notifications

Internal Investigation ID(s)

SUPPORT-10855

Environment

• Qlik Talend Cloud Data Integration

A Qlik Talend Data Integration storage task targeting Snowflake fails during the Compare and Apply operation with the following error:

Failed to execute sql: Compare and apply to table 'CT',
for dataset 'ACCOUNT'.

SQL compilation error: Failure during expansion
of view 'SF_ACCOUNT':

SQL compilation error: Object
'QLIK_CONFORM.SALESFORCE_ICRM_PROD_TALEND.ACCOUNT'
does not exist or not authorized.

Other datasets within the same storage task and other tasks using the same source endpoint complete successfully. Only the affected dataset fails.

Environment

• Qlik Talend Data Integration

Resolution

Step 1: Verify that the underlying table exists

Using an appropriately privileged Snowflake role, execute:

SHOW TABLES LIKE 'ACCOUNT'
IN SCHEMA QLIK_CONFORM.SALESFORCE_ICRM_PROD_TALEND;

Confirm that the table exists and has not been renamed, dropped, or moved.

Step 2: Verify the Snowflake view definition

SELECT GET_DDL('VIEW', '<database>.<schema>.SF_ACCOUNT');

Confirm that the view references the correct database, schema, and table.

Step 3: Check existing permissions

SHOW GRANTS ON TABLE
QLIK_CONFORM.SALESFORCE_ICRM_PROD_TALEND.ACCOUNT;

SHOW GRANTS ON VIEW
<database>.<schema>.SF_ACCOUNT;

SHOW GRANTS TO ROLE <qlik_service_role>;

Verify the privileges of the role used by Qlik Cloud Data Integration and the relevant ownership and access permissions associated with the view.

Step 4: Correct any missing permissions

If the investigation confirms that permissions are missing, have the Snowflake administrator grant the required privileges to the appropriate role.

For example, if direct table SELECT access is required for the affected role:

GRANT SELECT ON TABLE
QLIK_CONFORM.SALESFORCE_ICRM_PROD_TALEND.ACCOUNT
TO ROLE <role_name>;

If existing tables require access according to the customer's permission policy:

GRANT SELECT ON ALL TABLES IN SCHEMA
QLIK_CONFORM.SALESFORCE_ICRM_PROD_TALEND
TO ROLE <role_name>;

Use the broader grant only when required and approved.

For newly created tables, review the FUTURE GRANTS configuration separately:

GRANT SELECT ON FUTURE TABLES IN SCHEMA
QLIK_CONFORM.SALESFORCE_ICRM_PROD_TALEND
TO ROLE <role_name>;

FUTURE GRANTS do not retroactively apply to existing tables.

Step 5: Validate the view

Using the same Snowflake role and context as the Qlik connection, execute:

SELECT *
FROM <database>.<schema>.SF_ACCOUNT
LIMIT 1;

Confirm that the query completes successfully.

Step 6: Retry the storage task

Restart or retry the affected storage task and confirm that the ACCOUNT dataset completes successfully without the SQL compilation error.

Cause

The Snowflake view SF_ACCOUNT references an object that Snowflake cannot resolve or access during query execution.

The issue was associated with Snowflake object privileges and the FUTURE GRANTS configuration.

Snowflake FUTURE GRANTS apply to objects created after the grants are configured. They do not automatically grant permissions on existing objects.

If required permissions are missing on an existing object, Snowflake may return an "Object does not exist or not authorized" error.

For standard Snowflake views, the role querying the view does not normally require direct SELECT access to the underlying tables. Therefore, the privileges on the view, its referenced objects, and the relevant Snowflake roles should be checked before applying changes.

Internal Investigation ID(s)

SUPPORT-10934

After upgrading Qlik Replicate from May 2025 (2025.5) to May 2026 (2026.5.0.169), a Log Replicate task targeting Snowflake fails during startup with the following errors in the TARGET_LOAD log component:

E: Failed (retcode -1) to execute statement:
CREATE SCHEMA IF NOT EXISTS "LZ_GUESTSERVICES"

E: RetCode: SQL_ERROR
SqlState: 42501
NativeError: 3001
Message: SQL access control error:
Insufficient privileges to operate on database 'EDW_DEV'.
Your primary role DATAREPLICATION must have CREATE SCHEMA
granted on DATABASE EDW_DEV.

E: Failed create client resources
E: Failed while preparing stream component
E: Cannot initialize subtask

The issue occurs even when the target schema has already been created by a Snowflake administrator.

The companion Log Stream task starts successfully, while the Log Replicate task fails.

The same configuration worked in Qlik Replicate 2025.5 before the upgrade.

The reported issue was resolved by upgrading to a corrected Qlik Replicate 2026.5 build (SP01 or higher).

Environment

• Qlik Replicate, version 2026.5.0.169

Resolution

Fix Version

Upgrade to Qlik Replicate 2026.5 SP01 or a later release containing the fix. See the Release Notes for details. 

After the upgrade:

1. Confirm the installed build and review the applicable release notes.

2. Resume the affected Log Replicate task using its existing recovery position.

3. Verify that the task initializes successfully without the CREATE SCHEMA permission error.

4. Confirm that replication continues and that changes are applied successfully to Snowflake.

Workaround (temporary)

Grant CREATE SCHEMA permission.

If an immediate upgrade is not possible, a Snowflake administrator can temporarily grant CREATE SCHEMA on the target database to the primary role used by the Qlik Replicate connection.

Example:

GRANT CREATE SCHEMA ON DATABASE EDW_DEV
TO ROLE DATAREPLICATION;

After granting the privilege:

1. Resume the affected Log Replicate task.

2. Confirm that initialization succeeds.

3. Verify that replication continues normally.

• The workaround grants additional privileges that may not otherwise be needed when the schema already exists.

• Review the permission change with the customer's Snowflake administrator.

• After upgrading to a corrected Replicate build, review whether the temporary privilege can be revoked without affecting other tasks that legitimately create schemas.

• Do not drop or recreate existing schemas as a workaround.

• Avoid reloading or recreating replicated tables unless separately required by the recovery procedure.

Cause

A regression in the affected Qlik Replicate 2026.5 build causes the Log Replicate task to execute a CREATE SCHEMA IF NOT EXISTS statement against the Snowflake target database during initialization, even when the target schema already exists.

If the Snowflake role used by Qlik Replicate does not have the CREATE SCHEMA privilege on the target database, Snowflake rejects the statement with a permissions error.

As a result, Qlik Replicate cannot initialize the target resources, and the Log Replicate task fails to start.

According to Qlik Replicate's documented Snowflake permissions, CREATE SCHEMA is required when Qlik Replicate needs to create a new schema. When the target schema already exists, the role requires the appropriate privileges on the existing database and schema instead.

This issue is associated with the reported Qlik Replicate regression rather than necessarily indicating an incorrect Snowflake permissions configuration.

Internal Investigation ID(s)

RECOB-10774, SUPPORT-11127

When configuring an Oracle source endpoint in Qlik Replicate to capture changes from a pluggable database (PDB) on an Oracle Active Data Guard standby, the Test Connection operation may report the following error:

CDC requires SELECT privilege on SYS.OBJ$ system table

The error may occur even when the Oracle administrator confirms that SELECT on SYS.OBJ$ has already been granted to the replication user.

In the reported environment:

• The Oracle source is an Active Data Guard standby.
• The target PDB is open in READ ONLY mode.
• Qlik Replicate uses Replicate Log Reader to access redo logs.
• Granting broader privileges such as SELECT_CATALOG_ROLE or SELECT ANY DICTIONARY allows the connection test to pass.
• Individual privileges in use rather than broad dictionary access.

Because the standby is read-only, privilege changes must be made through the appropriate writable primary database environment and applied to the standby through Data Guard.

Environment

• Qlik Replicate

Resolution

Verify and correct Oracle source privileges for Active Data Guard, granting SELECT on SYS.V_$STANDBY_LOG from the primary.

Step 1: Confirm the Oracle connection context

Ask the Oracle DBA to confirm the database and container used by the Qlik Replicate source endpoint.

Connect using the same Oracle account and service name configured in Replicate, and execute:

SELECT
    SYS_CONTEXT('USERENV', 'CON_NAME') AS CONTAINER_NAME,
    SYS_CONTEXT('USERENV', 'SESSION_USER') AS USER_NAME
FROM DUAL;

Confirm that the connection points to the intended PDB or CDB.

Step 2: Check access to the required standby view

Using the replication account, execute:

SELECT COUNT(*)
FROM V$STANDBY_LOG;

If the query fails with ORA-00942 or ORA-01031, ask the Oracle DBA to investigate the required privilege.

Also verify access to SYS.OBJ$:

SELECT COUNT(*)
FROM SYS.OBJ$;

Step 3: Verify existing object grants

Using an appropriately privileged DBA account, check the direct grants:

SELECT
    GRANTEE,
    OWNER,
    TABLE_NAME,
    PRIVILEGE
FROM DBA_TAB_PRIVS
WHERE GRANTEE = UPPER('<replication_user>')
  AND OWNER = 'SYS'
  AND TABLE_NAME IN ('OBJ$', 'V_$STANDBY_LOG');

Review the results in the relevant Oracle container and confirm the privilege is effective for the replication session.

Step 4: Grant the missing standby privilege if confirmed

If SELECT on SYS.V_$STANDBY_LOG is missing, have the Oracle DBA grant it from the appropriate writable primary database container:

GRANT SELECT ON SYS.V_$STANDBY_LOG
TO <replication_user>;

If the SYS.OBJ$ privilege is also missing, the DBA can grant it where required:

GRANT SELECT ON SYS.OBJ$
TO <replication_user>;

For multitenant environments, the Oracle DBA must determine the appropriate container and grant scope based on whether the replication account is a local or common user.

Do not execute these GRANT statements directly against a read-only standby PDB.

Step 5: Confirm Data Guard has applied the changes

Verify that the changes made on the primary have been applied to the standby and that the replication account can query the required objects.

Reconnect using the replication account to establish a new database session.

If the grants are confirmed but the permissions still appear ineffective, ask the Oracle DBA to investigate dictionary metadata or privilege visibility on the standby.

A shared pool flush may be considered by the DBA if there is evidence of stale cached metadata. It should not be performed routinely because it clears shared SQL and metadata caches and may affect database performance.

Step 6: Validate the full Oracle CDC prerequisites

Review the Required permissions section of the Qlik Replicate documentation for the installed version.

Confirm the general Oracle source privileges, the standby-specific privileges, and any additional permissions required by Replicate Log Reader, ASM, or the configured redo log access method.

Step 7: Retry the Qlik Replicate connection

1. Open the Oracle source endpoint in Qlik Replicate.

2. Run Test Connection.

3. Confirm that the privilege validation completes successfully.

4. Start or resume the replication task as appropriate.

5. Verify that CDC processing starts without Oracle dictionary privilege errors.

Avoid granting SELECT ANY DICTIONARY or SELECT_CATALOG_ROLE solely to bypass the connection test when the customer requires least-privilege access.

Use individual object privileges supported by the Qlik Replicate Oracle source prerequisites.

Cause

The error indicates that Qlik Replicate could not validate the dictionary privileges required for Oracle CDC using the source connection.

In an Oracle Active Data Guard environment, the Qlik Replicate user requires the general Oracle source permissions and the additional privileges applicable to a standby database.

One of these requirements is SELECT access to V$STANDBY_LOG, normally granted through the underlying SYS.V_$STANDBY_LOG object.

If a required grant is missing or is not effective in the database container used by the Qlik Replicate connection, the connection test may fail.

A grant on SYS.OBJ$ alone does not establish that all Oracle CDC prerequisites have been satisfied.

In the reported case, granting broader dictionary privileges allowed the connection test to succeed, suggesting that one or more required privileges were unavailable through the existing individual grants.

The exact missing privilege and whether standby metadata refresh contributed to the issue require confirmation from the customer investigation.

Related Content

• Required permissions | Using Oracle as a source 
• Data Dictionary and Dynamic Performance Views | docs.oracle.com 

Internal Investigation ID(s)

SUPPORT-11666

A Qlik Replicate CDC task replicating data from PostgreSQL to Snowflake may appear to stop processing changes while remaining in a running state.

The SOURCE_CAPTURE log repeatedly reports the same retrieved LSN and flush LSN values over an extended period, without apparent progress.

The following behavior was observed:

• The task appeared to wait for source transactions to be committed.
• WAL-tracker messages repeatedly showed unchanged LSN values for approximately two hours or longer.
• The PostgreSQL heartbeat table was reported to contain no rows.
• CDC processing did not progress as expected.

Qlik Replicate supports a WAL heartbeat mechanism that periodically generates transactions in a PostgreSQL heartbeat table to help advance the replication slot position when monitored source tables are inactive.

An empty heartbeat table, together with unchanged LSN values, requires further investigation to determine whether heartbeat activity is functioning correctly.

Environment

• Qlik Replicate

Resolution

Step 1: Check the Qlik Replicate task

1. Confirm that the CDC task is running and has not reported an error.

2. Review SOURCE_CAPTURE and PERFORMANCE log messages for repeated LSN values or replication slot errors.

3. Confirm whether source changes are being generated but not captured.

4. Check source capture and target apply latency to identify where processing is delayed.

Step 2: Verify WAL heartbeat configuration

Open the PostgreSQL source endpoint in Qlik Replicate.

Under the Advanced tab:

1. Check whether WAL heartbeat is enabled.

2. Confirm the configured heartbeat schema.

3. Check the heartbeat frequency.

4. Verify that the PostgreSQL connection user has the required permissions to access and maintain the heartbeat table.

The default heartbeat table name is attrep_wal_heartbeat.

Step 3: Check the heartbeat table

Ask the PostgreSQL DBA to verify that the heartbeat table exists.

For the default schema:

SELECT schemaname, tablename
FROM pg_tables
WHERE tablename = 'attrep_wal_heartbeat';

If the table exists, check its records:

SELECT COUNT(*)
FROM public.attrep_wal_heartbeat;

Replace public with the configured heartbeat schema if different.

An empty table should be investigated together with the heartbeat configuration and task logs. It does not independently establish the root cause.

Step 4: Check PostgreSQL replication slots

Using an account with the appropriate PostgreSQL monitoring privileges:

SELECT
    slot_name,
    plugin,
    slot_type,
    database,
    active,
    restart_lsn,
    confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_type = 'logical';

Verify that:

• The expected logical replication slot exists.

• The slot is active when the corresponding Replicate task is running.

• The slot belongs to the correct source database.

• Its LSN position is progressing when relevant changes are captured and acknowledged.

If multiple Replicate tasks use the same PostgreSQL database, review the individual slots and their status.

Step 5: Perform controlled recovery

If the task is stalled and the investigation points to a heartbeat configuration or artifact issue:

1. Preserve the task logs and diagnostics.

2. Record the current replication slot and saved task position.

3. Confirm that the PostgreSQL WAL required for recovery remains available.

4. Review any proposed heartbeat table repair with the PostgreSQL DBA and Qlik Support.

5. If explicitly approved, perform the required heartbeat artifact recovery while the affected tasks are stopped.

6. Resume the task using its existing recovery position, when supported.

Do not drop the heartbeat table or replication slot without confirming the impact on other tasks and the recovery procedure.

Step 6: Verify CDC processing

After recovery:

1. Confirm that the task remains running.

2. Verify that changes committed to monitored PostgreSQL tables are captured.

3. Confirm that the replication slot's confirmed flush position advances when changes are acknowledged.

4. Verify that changes reach the Snowflake target.

5. Confirm that the task does not return to the stalled state.

The WAL heartbeat feature is primarily intended to help advance replication slot positions during periods of source inactivity.

It does not guarantee that all unchanged LSN values indicate an error, nor does it replace troubleshooting for inactive slots, capture failures, or other CDC delays.

Cause

The reported issue is associated with a lack of visible WAL progress and possible problems with PostgreSQL heartbeat activity.

Qlik Replicate uses PostgreSQL logical replication to capture changes. Each replication task normally uses its own logical replication slot, which tracks the WAL position required by that task.

When WAL heartbeat is enabled, Replicate periodically commits transactions to its heartbeat table (attrep_wal_heartbeat) to help advance the replication slot position during periods when monitored source tables are inactive.

If heartbeat transactions are not generated or captured as expected, the replication slot may remain at an earlier LSN position.

However, unchanged LSN values or an empty heartbeat table alone do not confirm a heartbeat failure. Similar symptoms can occur when there are no relevant source changes, when a replication slot is inactive, or when capture processing is delayed.

The exact reason for the missing heartbeat activity in the reported case requires confirmation from the customer investigation.

Related Content

• Setting advanced connection properties | Using PostgreSQL as a source 
• Removing Replicate artifacts from the database | Using PostgreSQL as a source 

Internal Investigation ID(s)

SUPPORT-11918

It is not possible to set up a multicloud deployment in Qlik Sense Enterprise on Windows May 2026 to distribute to Qlik Cloud. The following error is displayed:

An error occurred. Cannot destructure property 'headers' of 'undefined' as it is undefined'

or:

An error occurred. Cannot destructure property 'headers' of 'options.req' as it is undefined'

An additional Missing licene error will be displayed in the Qlik Sense Management Console:

You need to go to the QMC and apply a license

This occurs even if the applied license is active, has full access to the internet, and Qlik Cloud is reachable.

The Qlik Sense License service logs:

{"caller":"handler.go:53","errorMessage":"no available allotment error, No available allotments","errorType":"LICENSES-ForbiddenRequest",…

Resolution

This issue is caused by defect SUPPORT-11220.

Fix Version

Upgrade to Qlik Sense Enterprise on Windows Patch 3 or later. 

Internal Investigation ID(s)

SUPPORT-11220

Environment

• Qlik Sense Enterprise on Windows May 2026 IR, Patch 1, Patch 2

When a Discovery Agent insight trigger is configured with Daily frequency and a valid dataset containing multiple days of data, the trigger evaluation fails with the error:

Failed to count hypercube data points - daily: Found only 1 data point(s) for daily frequency.
Analysis failed at [timestamp].

This error occurs even when the application contains a sufficient number of distinct dates and the data has changed since the trigger was created.

Environment

• Qlik Cloud
• Discovery Agent, insight triggers

Resolution

Ensure that the dataset loaded into the application contains at least 365 days of historical data before creating or activating an insight trigger with Daily frequency.

When testing insight triggers with synthetic or time-limited datasets, extend data generation to cover a full year (365+ days) and reload the application before creating the trigger. For production use cases, confirm that the source data includes a complete 12-month history.

For more information, see Working with Discovery Agent insight triggers | Qlik Cloud Help.

Cause

Automated insights analysis for daily frequency requires a minimum of 365 days of historical data in the dataset. The Discovery Agent's anomaly detection engine (OWL) performs statistical analysis over a 12-month baseline period. If the dataset contains fewer than 365 days of records, the trigger evaluation fails even if the data contains multiple valid daily data points.