I was asked to look into using Qlik CLI "Qlik App Unbuild" to generate and move the yaml and json files to a Git repo.  This would act as version control for us.  Is this something I could build in Qlik automation or do I need to run this from Python or a similar program externally?  Does anyone have thoughts about how this could be done?

Hi,

I am using button object in layout container over a text object to apply some actions and sheet navigation in Qlik Cloud. This works perfectly in browser but not in SaaS mobile app. I have noticed that actions such as set variable value works perfectly in mobile app however only navigation functionality is not working either I choose sheet navigation or apply bookmark action.

Can anyone confirm that this is a known bug or please suggest some solution or workaround. 

Hello Qlik Community,

We would like discuss about a suspected issue in Qlik Replicate. After a source table is recreated and explicitly reloaded, Full Load completes successfully, but subsequent changes to that table are not captured. CDC resumes only after an additional Stop → Resume.

Environment

• Qlik Replicate: 2026.5.0.423.  Sourse and Target use same  Microsoft SQL Server 2019, Microsoft SQL Server (MS-CDC) 

• Task  Full Load + Apply Changes + Store Changes enabled. DDL action all ignored 
  
  

  The test uses two tables:

  • dbo.VersionTest — the table being recreated.

  • dbo.CdcHeartbeat — an unaffected control table. A stored procedure continuously generates committed updates to this table so that the task’s LSN position continues to advance.
    

  •  

  The heartbeat procedure remains running throughout the experiment, including periods when the Replicate task is stopped.

  VersionTest has a primary key and simple text/numeric columns, without LOB or rowversion columns. We reproduced this behavior in a laboratory while investigating replication recovery after BAS application table restructuring.

  Steps to reproduce

  1. Start the Replicate task and confirm that CDC works for both tables. Start the procedure generating continuous committed updates to CdcHeartbeat.

  2. While the Replicate task is running, drop dbo.VersionTest.

  3. Create a new table named dbo.VersionTestNG.

  4. Rename dbo.VersionTestNG to dbo.VersionTest. The table now has the original name but a different SQL Server object_id.

  5. Manually enable MS-CDC for the new dbo.VersionTest. Verify that changes to this table appear in the source cdc.dbo_VersionTest_CT.

  6. Stop the Replicate task and wait until it is Stopped. Mark VersionTest for Reload while the task is stopped, then select Resume Processing.

  7. Wait for Full Load to complete successfully. Execute and commit an UPDATE setting the test value to PROBE_A. This event appears in the source CDC table but does not appear in the target VersionTest__ct. Meanwhile, heartbeat changes continue reaching the target and advance the saved task position beyond the LSN of PROBE_A.

  8. Perform another Stop → Resume Processing, without an additional Reload.

  9. Execute and commit another UPDATE setting the value to PROBE_B. This change is captured successfully. The target VersionTest__ct contains the transition PROBE_A → PROBE_B, but the previously missed event that changed the value to PROBE_A is not recovered.

  Expected behavior

  After an explicit Reload refreshes the recreated table’s metadata, CDC should resume for that table.

  If this DDL scenario requires additional recovery steps, we need a documented, supported procedure that prevents missed changes and clearly identifies when capture remains inactive.
  

  Observed mechanism

  At the first Resume, the capture component detects the missing old object and removes its registration. Reload subsequently refreshes the metadata for the new object, but the new CT is not added to the running capture component’s polling list.

  The additional task restart establishes the correct registration and restores polling.
  

  The task continues processing other tables and advancing its LSN while capture of VersionTest remains inactive. This creates a gap in the change history, which is critical for downstream historical processing.

  An additional Stop → Resume restores future CDC processing but does not recover the missed interval. The current workaround therefore requires keeping writes to the recreated tables paused until Reload, the additional restart, and CDC verification have completed.

  
  what is best supported recovery procedure after replacing a source table with a new object under the same name?
  
  
  

Hi,

Has anyone replaced "Entitlement Analyzer" v1.0 with the latest which is v2.4, while keeping the history so we don't lose relevant "past information"?

Thank you.

Hi everyone,

We are experiencing an OAuth 2.0 authentication issue when trying to connect Qlik Cloud Analytics to Salesforce using the Salesforce connector from Add Data.

A new Salesforce External Client App was created following Salesforce's recent security changes.

According to Salesforce's updated security requirements, PKCE is mandatory for newly created applications, and the option to disable it is locked.

However, the Qlik documentation instructs us to disable PKCE as part of the connection setup.

We attempted to configure the Salesforce Callback URL using both:

https://connector.qlik.com/auth/oauth/v2.htm

https://connector.qlik.com/auth/oauth/v3.htm

Both attempts failed during authentication, resulting in the following errors:

redirect_uri_mismatch

OAUTH_APPROVAL_ERROR_GENERIC

We would appreciate hearing from anyone who has encountered a similar issue or has successfully established a Salesforce OAuth 2.0 connection in Qlik Cloud Analytics under the new PKCE requirements.

Thanks in advance for sharing your experience!

Dear Support Team,

I am writing to request clarification regarding the behavior of the use_manipulation_pk_for_apply parameter and an apparent discrepancy between our test results and the current documentation.

1. Current Documentation

According to the manual, to enable this feature, the parameter should either be:

• Removed (unset), or

• Explicitly set to OFF.

2. Observed Behavior / Verification Results

Based on our internal testing, the actual behavior appears to contradict what is stated in the documentation:

• When use_manipulation_pk_for_apply is unset or set to ON: If a configuration exists to arrange primary key (PK) values in a specific order, the system appears to attempt to reorder and apply them according to that sequence.

• When set to OFF: This reordering process does not seem to be triggered.

• New Task Comparison: Based on our observation, the reason this unexpected behavior does not occur in newly created tasks seems to be simply that no specific PK ordering has been configured for them.

Therefore, our verification suggests that the feature is actually enabled when the parameter is unset or set to ON, rather than OFF.

3. Questions / Confirmation

Could you please confirm the following points?

1. Is the statement in the manual incorrect, and should it state that the feature is enabled when set to ON (or unset)?

2. If the manual is correct and setting the parameter to OFF is indeed the intended specification to enable the feature, is the observed behavior where ON triggers this process considered a defect/bug?

We would appreciate your clarification on the intended behavior and documentation.

Best regards.

Hi Qlik Fam,

In Qlik Application Automation, I have a list of emails in loop. Is there any way to get their user ID like:

67b41d9cb8f9db2519625a28

 to perform operations like role assignments and updates on multiple user IDs, because the Qlik operation block asks for a user ID to perform any operation.

Any suggestions would be highly appreciated.

Thanks and Regards,

VJ

Hello,

I’ve configured a replication task that reads from a Log Stream and replicates data to a Snowflake target with Apply Changes Processing enabled, meaning that changes are applied directly to the target tables in Snowflake. The source of the Log Stream is an Oracle database.

Moreover, I’ve implemented a soft-delete logic in this task by adding a technical field defined as follows:

CASE ifnull(operation_indicator('DELETE','UPDATE','INSERT'),'null')
WHEN 'null' THEN 'INSERT'
ELSE operation_indicator('DELETE','UPDATE','INSERT') END

Occasionally, operations are performed on the source that modify primary key fields. I’d like to understand if it’s possible to transform the UPDATE into a DELETE of the record with the previous key, followed by an INSERT of the record with the new key.

As I understand it, the “DELETE and INSERT when updating a primary key column” option available in Apply Changes Processing cannot be used to achieve this because for the Snowflake target endpoint this option applies only to Change Tables, not to the actual target tables.

However, I noticed that there is also an “Apply changes using SQL MERGE” option. If I understand correctly, this option works as follows: “for a standard UPDATE, Qlik Replicate generates a MERGE INTO statement. However, if the UPDATE modifies primary key values, Qlik Replicate will not use MERGE INTO; instead, it will apply the change as a DELETE + INSERT pair for that row”.

This behavior is described in the following article:
https://community.qlik.com/t5/Official-Support-Articles/Qlik-Replicate-Implementing-UPSERT-and-MERGE-modes-by-applying-a/ta-p/1780009.

If this is how SQL MERGE operates, would implementing a soft-delete logic mean that, when a primary key changes, the target table would contain the record with the old primary key marked as deleted (soft-deleted) and the record with the new primary key inserted as a new record?

Thank you in advance for your support.

Best regards