Qlik Cloud tenants are the highest level of logical isolation provided to our customers. The subscriptions and associated entitlements (also known as licenses) that customers purchase from Qlik are not fixed to these tenants. When needed, a customer can update the entitlement used by their tenant. This article covers how to do this, as well as all considerations before moving.

You should not attempt to update your tenant entitlement unless directed to do so by Qlik, or you are an OEM customer who is managing multiple entitlements for their estate.

The steps in this article only apply to User-Based Subscriptions. To convert your tenant from an evaluation tenant to a paid tenant, or to convert from a user-based subscription to a capacity-based subscription, contact Qlik Support.

Content:

• Why you might need to update your entitlement
• Considerations
• How to update the entitlement for your tenant
• 1. Retrieve the signed license key (SLK) for your entitlement
• 2. Export the current user assignments
• 3. Update the tenant entitlement
• 4. Reassign user assignments

Why you might need to update your entitlement

There are three scenarios where you might need to update your entitlement:

1. You have been directed to do so by Qlik support or another Qlik team
2. You are an OEM customer who purchased multiple subscriptions, and who wishes to merge these into your new multitenant entitlement
3. You are an OEM customer who is managing multiple multitenant entitlements

If you are an OEM or Enterprise customer leveraging multiple tenants in Qlik Cloud, please also consider reviewing the Platform Operations series on qlik.dev to learn more about managing these estates prior to changing your entitlements.

Considerations

Before you begin migrating your subscription or entitlement, consider:

• When changing entitlements, all assignments will be lost. This means any user who has previously been assigned a named entitlement (such as a professional-, analyzer-, full- or basic user entitlement) will need to have their entitlement reassigned. 
• Any entitlement changes are immediate. If your new entitlement is missing features or capabilities compared to the original entitlement, or it has less capacity than the original entitlement, then components in the tenant may not function as expected, or users may be impacted. As a good practice, verify the new entitlement on another tenant before applying the changes, or apply the change outside of working hours for the majority of your users.
• Original assignments are not restored if you re-apply the original entitlement. Although you are able to re-apply the original entitlement, it will not restore the original assignments, and some capabilities that may have been disabled through the move might need manually re-enabling.
• The Service Account Owner of the entitlement is the individual who has access to the tenant recovery capabilities. Make sure you know who the Service Account Owner is for the new entitlement before you move the tenant.

How to update the entitlement for your tenant

Updating the entitlement requires four steps:

1. Retrieve your signed license key 
2. Export the current user assignments
3. Update the tenant entitlement
4. Reassign  User assignments

1. Retrieve the signed license key (SLK) for your entitlement

Your SLK is available through:

• The welcome email sent when the entitlement was generated
• Qlik support, if you only have the numeric subscription or entitlement number available
• Any tenant already deployed to that entitlement
  
  To find the entitlement via an existing tenant, log into a tenant linked to the entitlement, and navigate to https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/overview
  
  This will return a license definition, from which you can pull out the SLK. In the example below, you can see "licenseKey". We need the long value, e.g.: "eyJhbGciOiJSUzUxMiIsImtpZCI6ImE...".
  
  

  {"licenseNumber":"1234 5678 1234 5678","licenseKey":"eyJhbGciOiJSUzUxMiIsImtpZCI6ImEzMzdhZDE3LTk1ODctNG....","valid":"./2023-10-08","status":"Ok",...}

2. Export the current user assignments

When you migrate between entitlements, any user assignments will be reset. You will need to export any current assignments if you wish to reassign them. 

There are three ways of doing this:

1. Call the licenses/assignments API endpoint via script:
   
   

   curl -L -X GET 'https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/assignments' \ -H 'Authorization: Bearer ey....' \ -H 'Content-type: application/json' \ -H 'Accept: application/json'

   
   
   
2. Log into the tenant you wish to bring onto the entitlement as a user with the Tenant Admin role. Then open the following address: https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/assignments

   
   If you have many users, both option a and b will require you to paginate to get all results.
   
   Results will look like:

   {     "data": [         {             "subject": "QLIKBOT\\f0e92f326ac77427df155940fec39e6a",             "type": "professional",             "excess": false,             "created": "2022-10-20T13:46:29.474Z"         },         {             "subject": "auth0|a08d000001f0wjria3",             "type": "professional",             "excess": false,             "created": "2022-10-06T09:21:13.265Z"         },         {             "subject": "QLIKBOT\\52b7313d6705e2873eaadb9be23d8c06",             "type": "professional",             "excess": false,             "created": "2022-10-05T12:46:01.716Z"         }     ],     "links": {         "next": {             "href": ""         },         "prev": {             "href": ""         }     } }

   
   
   
3. Log into the tenant you wish to bring onto the new entitlement as a user with the Tenant Admin role, and use an automation to export these assignments. The example below returns the list as a table to the automation output. To import this automation, simply create a new automation, right click, then import the workspace JSON file attached to this post (automation-template-export-license-assignments.json).
   
   Output of attached automation template
   
   Note that for tenants with a large number of users, you will need to output the records to a file as the output window will eventually be capped.

3. Update the tenant entitlement

1. Log into the tenant you wish to bring onto the new entitlement as a user with the Tenant Admin role
2. Click your Profile
3. Click About
   
   
   
   
4. Click the key icon next to Subscription ID
   
   
   
   
5. Enter the SLK for the multitenant entitled subscription
   
   
   
   
6. Click Submit

4. Reassign user assignments

If required, reassign entitlements which were exported in step 2. You can do this in two ways:

1. Manually, by navigating to the management console.  See Assigning user entitlements | Help.qlik.com.
2. Programmatically by using automations or raw API calls.
   
   An example API call to assign an entitlement is shown below.
   
   Example cURL code to assign an entitlement (can also be done in automations):
   

   curl -L -X POST 'https://<hostname>.<region>.qlikcloud.com/api/v1/licenses/assignments/actions/add' \
   -H 'Authorization: Bearer ey...' \
   -H 'Content-type: application/json' \
   -H 'Accept: application/json' \
   --data-raw '{
       "add": [
           {
               "subject": "1ef2caed0dbe0a66a24ccadf61546099",
               "type": "professional"
           }
       ]
   }'

The information in this article is provided as-is and to be used at own discretion. Depending on tool(s) used, customization(s), and/or other factors ongoing support on the solution below may not be provided by Qlik Support.

Qlik Cloud Tenant Admins report that the IP Allowlist option is missing from Administration > Settings. In some cases, the Alerts submenu is also unavailable (existing alerts may still be visible, but create or edit is not possible).

The Feature Preview settings may also appear under an “Other” tab instead of their normal location. The issue affects multiple Tenant Admins in the same tenant and appears suddenly without any configuration changes in Qlik Cloud.

Environment:

• Qlik Cloud

Resolution

The missing menu options are caused by blocked outbound network calls to Qlik Cloud feature-flag and analytics services. When these calls fail, the user interface hides the related features.

1. Ask the network and security team to allowlist (or add to SSL inspection bypass) the following domains:
   • clientsdk.launchdarkly.com
   • app.launchdarkly.com
   • events.launchdarkly.com
   • cdn.pendo.io
   • pendo-static-5763789454311424.storage.googleapis.com
2. Refer to the official domain allowlisting documentation for the complete current list:
   Qlik Cloud – Domain allowlisting
3. After the domains have been allowed, perform a hard refresh of the browser (or clear cache and reopen the session).
4. Confirm that the IP Allowlist tab and Alerts options reappear in Administration.

This issue is almost always network-related (proxy / SSL interception / DLP) and not a change in Qlik Cloud itself. Testing from a different network (e.g. mobile hotspot or unrestricted network) can quickly confirm the diagnosis.

Cause

Qlik Cloud uses LaunchDarkly for feature flags and Pendo for in-product guidance and analytics. Several Administration features (including IP Allowlist and Alerts) depend on successful calls to these services.

When a corporate proxy, SSL inspection appliance, or Data Loss Prevention tool blocks or intercepts traffic to domains such as clientsdk.launchdarkly.com or Pendo endpoints, the browser receives no response (or a CORS/connection error). The Qlik Cloud frontend then falls back to a reduced feature set and hides the corresponding menu options.

This explains why the same tenant can show the full Administration menu from an unrestricted network while the options are missing when accessed from the corporate network.

Related Content

• Qlik Cloud DNS and IP allowlisting
• Managing IP allowlists in Qlik Cloud

A Talend Remote Engine running as a service on Linux repeatedly shows Unavailable in TMC during a consistent daily window (for example, 05:00 to 06:30 CST). The service appears healthy on the host, and no network issues are found. Scheduled tasks on the engine may fail or be skipped during this window.

Typical log indicators:

• wrapper.log: the JVM hung and was killed with SIGKILL, and the wrapper timed out waiting for Karaf to initialize.
• karaf.log / karaf-10.log: log back pressure (dropped log events) and tasks blocked by a parallel execution restriction.
• Permission denied errors when the engine writes to /var/lock/subsys/talend-remote-engine.
• The deployment limit is shown at its maximum (for example, 10/10).

Environment

• Talend Cloud

Resolution

1. Stagger the scheduled jobs that overlap in the affected window so fewer run concurrently. In this case, this stopped the Unavailable condition.
2. Review the deployment limit (max.deployed.flows). Raise it only if the host has capacity for additional JVMs. Otherwise, reduce the number of concurrent tasks per engine.
3. Monitor host resources (CPU, memory, swap, disk I/O) during the failure window. Check the health of any network mounts used as job sources.
4. If memory pressure is confirmed, increase the engine JVM heap via the Xmx setting in the wrapper configuration (the recommended heap for a Remote Engine running as a service is 1 GB), add host memory, or move some jobs to another engine.
5. Verify permissions on /var/lock/subsys/ so the Remote Engine service account has write access. Upgrade to the Remote Engine release that fixes the underlying bug when available.
6. Confirm the Remote Engine version and check whether the TMC false-unavailable edge case applies.
7. If the issue persists after these steps, open a new case with karaf.log, wrapper.log, job execution logs, and resource monitoring data for the failure window.

Cause

The most likely cause is JVM unresponsiveness under peak concurrent load. Many parallel jobs and large file transfers (around 100 MB archives) were scheduled in the same window. This can cause host resource contention (memory or swap pressure, prolonged garbage collection, or disk/network-mount I/O stalls). The wrapper then killed and restarted the engine JVM. While the engine reconnects, TMC marks it as Unavailable, even though the service eventually recovers by itself.

Related Content

• Qlik Talend Cloud: JVM Hanging Errors occur in Wrapper Log for Talend Remote Engine Server 
• Running tasks in parallel on Remote Engine 

Environment

• Talend Studio

In earlier versions of the cFile before Talend Studio version 2026-01, the success field was intentionally left blank to keep the file in its original location. After the migration, even if the success field is left intentionally blank, the component will create a ".camel" folder and move the successfully consumed file there.

Environment

• Talend Studio

Resolution

Caused by QAPPINT-3213.

Fix Version

QAPPINT-3213 is expected to be resolved in the Talend Studio R2026-11 release. Review the relevant release notes for details.

Workaround

No workaround is available. 

Cause

QAPPINT-3213 Cfile 2026-01 changes is forcing a file move when NOOP is disabled when it is successfully consumed

Internal Investigation ID(s)

QAPPINT-3213

Environment

• Talend Studio

The Scheduled Job icon in the Job Conductor section continues to display even after the job has completed. 

This behavior started after patching the Talend Administration Center to 2026-09.

Before patching, the Scheduled Job icon would disappear once the job was completed, and only the corresponding Job Completed or Job Failed icon would be displayed.

Resolution

This is caused by QTAC-3083.

Fix Version

QTAC-3083 is expected to be resolved in the November Talend Administration Center patch. Review the relevant release notes for details.

Workaround

No workaround is available. 

Cause

QTAC-3083 Timeline: scheduled events not removed after the scheduled run (regression from Quartz 2.5.x upgrade)

Internal Investigation ID(s)

QTAC-3083

Environment

• Taledn Administration Center

General Considerations When Selecting Server Hardware 

The purpose of this technical note is to provide starting guidance on what to consider when selecting hardware for the Qlik Associative Engine in Qlik Sense® and QlikView® deployments. 

Server selection for any given customer should be based on recommendations and tests provided by trained Qlik professionals. For information on how to contact Qlik's Professional Services, see How and when to contact Qlik's Professional Services and Consulting Teams.

Processor 

In current generations (2023) of processors, there is not much difference between AMD and Intel. 

Memory 

More RAM allows more result sets to be cached, which typically results in better performance. 

The Qlik Associative Engine allocates memory uniformly over all available RAM, which means that it is important to always have the amount of memory per CPU socket evenly distributed. 

For information on the memory configurations for best performance (including which RAM configurations can be deployed whilst keeping the bus speed as high as possible), contact the server manufacturer.

Architecture 

To compare the performance of different servers, you can use the theoretical calculation capacity: 

Theoretical Calculation Capacity=#sockets ×#CPU cores×base clock speed

This gives the theoretical number of calculations that a server can do every second. Servers with higher theoretical calculation capacity generally perform better than servers with lower theoretical calculation capacity.  

New architectures usually improve on the number of instructions per clock cycle and thus provide improved performance in comparison to older architectures.  

Sockets 

Since the Qlik Associative Engine is good at using memory as well as the processing capacity of all CPUs, the chipset architecture must provide fast communication between the CPU sockets to keep the latency towards the memory as low as possible. Chipset architectures that allow for direct connections between all available CPU sockets via high bandwidth links are therefore preferred. 

• Single-socket configurations: Single-socket configurations perform very well as all memory is directly connected to the CPU.  
• Two-socket configurations: These configurations perform very good providing there is enough bandwidth between the CPUs and towards the memory. For example, Intel CPUs with two or three processor interconnects perform better than those with just one. Using a single Intel CPU in a two-socket configuration also provides good performance.  
• Four or Eight-socket configurations: In most situations, it is not advised to use these types of configurations with Qlik Sense or QlikView as they more frequently introduce latencies to remote RAM. 

Core Count and Clock Speed 

It is important to find a good balance between the core count and the clock speed. Even though the Qlik Associative Engine is very good at multi-threading and uses all cores available to it, some procedures are still single-threaded and run faster with higher clock speed.  

BIOS and Operating System Settings 

Server BIOS and operating system settings can have a significant impact on the performance of Qlik Sense and QlikView deployments. For more information on the recommended settings please visit Quick tips #8 - Server settings for best performance. 

The attached recommendations are stored for archival purposes. No additional .pdf's will be created. Server selection for any given customer should be based on recommendations and tests provided by Qlik professional services.

A Qlik Replicate task using an Amazon RDS for PostgreSQL source, with the supportCdcPartitionedTables internal parameter enabled, terminates with a broken connection. The SOURCE_CAPTURE log component reports:

Failed to get partition details about table <schema>.<tablename>
Failed to get parent table details of child table '<schema>.<tablename>'

The error can reference tables that are not included in the task. The task restarts automatically and resumes processing.

The partition error is a side effect, not a partitioning metadata failure. The SOURCE_CAPTURE log also records the underlying error, showing that the database connection was dropped:

RetCode: SQL_ERROR  SqlState: HY000 NativeError: 1 Message: FATAL:  terminating connection due to idle-session timeout SSL connection has been closed unexpectedly

The error can appear in every environment that shares the same source endpoint configuration.

Resolution

Add TCP/IP keepalive settings to the source endpoint

1. Open the Amazon RDS for PostgreSQL source endpoint in Qlik Replicate, and go to the Advanced tab.
2. Add the internal parameter additionalConnectionProperties, with the value:
   
   KeepaliveTime=60;KeepaliveInterval=1;

3. Save the Endpoint.
4. Resume the task.

For more information about Internal Parameters, see Qlik Replicate: How to set Internal Parameters and what are they for?.

Configure TCP/IP keepalive at the operating system level

On the Qlik Replicate server, set the operating system’s TCP keepalive interval to match, or be shorter than, the idle-session timeout enforced by the Amazon RDS for PostgreSQL instance or any intermediate firewall.

Cause

An idle-session timeout terminates the connection between Qlik Replicate and the Amazon RDS for PostgreSQL instance. The timeout can be enforced at the database level or by a network component, such as a firewall. The query that is running when the connection drops, in this case a partition-tree lookup, fails with an SSL connection error.

Related Content

• Qlik Replicate: How to set Internal Parameters and what are they for?

Internal Investigation ID(s)

SUPPORT-11452

Environment

• Qlik Replicate

With a Microsoft SQL Server source, Qlik Replicate tasks can miss transactions in one of two ways:

• Data loss during a task restart by timestamp: a task is stopped and then resumed using the start from timestamp option, and replication begins at a log sequence number (LSN) later than expected. Transactions committed at or near the restart boundary are skipped.
• Data loss in transit: transactions present in the SQL Server transaction log are not captured by the Qlik Replicate change data capture (CDC) task, even though no restart occurred.

In both cases, rows committed on the source are missing from the target, and the affected tables must be fully reloaded.

Resolution

Reduce data loss during task restart

1. Avoid start from timestamp as the restart method when precision is required, since it can produce an LSN start position that is later than expected.
2. If the replication user has sysadmin privileges on SQL Server, add the internal parameter afterConnectScript to the source endpoint, with the value DBCC TRACEON(2537). This lets Qlik Replicate read the inactive portion of the online transaction log, so the task can start further back in time when it recovers from a stop.
3. Set the internal parameter logScanBatchSize to a value lower than 1000.
4. Stop and then resume the task, so that the endpoint settings take effect.

For more information about Internal Parameters, see Qlik Replicate: How to set Internal Parameters and what are they for?.

Investigate missing transactions without a restart

If transactions in the SQL Server transaction log are not captured while the task runs without a restart, contact Qlik Support.

Cause

Starting a task by timestamp is not exact. The LSN that Qlik Replicate derives from the requested timestamp can be later than expected, so the task resumes after transactions that were committed around the restart point.

Related Content

• Qlik Replicate: How to set Internal Parameters and what are they for?

Internal Investigation ID(s)

SUPPORT-11536

Environment

• Qlik Replicate

When the issue is related to the web browser cache and the user does not want to clear all browser cache, then what is the right approach to delete the cache only for the specific site?

Clear site-specific cookies and cache in Chrome

To delete cookies and cache for a specific site in Google Chrome, follow the instructions given below:

1. At the top right, click on the ellipsis (three dots)
2. Open Settings
3. Click Privacy and security
4. Select Clear browsing data 
   
5. To clear the complete cache: Check all data you wish to clear and click Clear data (this clear data for all sites)
   
   Direct link: chrome://settings/clearBrowserData
   
   
   
   
6. To choose a site: From the Privacy and Security menu, select Site settings 
   
   Direct link: chrome://settings/content/all
   
   
   
   
7. Click View permissions and data stored across sites 
8. From there, locate the site you wish to clear (expand the main domain for subdomains) and click the trash bin. 
   
   
    

Clear site-specific data in Legacy Edge

1. Click on the ellipsis (three dots) button on the top-right corner, then on History > Manage History.
2. Select the web page data you would like to delete, then click on the X button to the right, and confirm.
3. To delete all cache, instead of Manage History, click on Clear browsing Data.
4. Then select what data to delete. 

Clear site-specific data in Firefox

1. Open Firefox and go to Firefox Menu > Settings.
2. Go to the Privacy & Security tab.
3. Scroll to locate Cookies and Site Data
4. Click Manage Data 
5. Select or search for the website from the list and click Remove Selected. 
6. In order to remove all data, in Cookies and Site Data, click on Clear Data and then Clear the specific data.

Clear site-specific data in Safari

1. Open Safari, select the gear icon (settings) and open Preference
2. Select Privacy 
3. Click Details
4. Search for the website you wish to clear the cookies for
5. Select remove

Clear site-specific cache in Internet Explorer 11

1. Launch Internet Explorer and navigate to the website for which you want to delete cookies and cache.
2. Press F12 to launch Developer Tools and go to the Network tab.
3. To clear cache for the current website, click on Clear cache button or press Ctrl + R.
4. To delete all cache, go to Internet Options, then under the General Tab > Browsing history, click Delete.
5. Then select what data to delete.
6. To delete files specific to a web site, click on View Files.

Clear site-specific data in Internet Explorer 8, 9, and 10

1. Launch Internet Explorer and navigate to the website for which you want to delete cookies and cache.
2. Press F12 to launch Developer Tools.
3. Click on Cache on the Developer Tools menu bar.
4. From the drop down menu, select “Clear browser cache for this domain”. This will clear all the cache specific to the currently open website.
5. Similarly, go to Cache > Clear cookies for domain in Developer Tools to clear cookies of the current website.

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

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