Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Content
Qlik Cloud is designed to support a single interactive Identity Provider (IdP) per tenant.
This approach enhances security, governance, and operational control while simplifying authentication management. Organizations that require multiple identity sources can achieve this by using a federated IdP (such as Azure Entra, Auth0, Keycloak, or Okta) to consolidate authentication and seamlessly connect it to Qlik Cloud
Qlik Cloud allows organizations to configure an interactive IdP to manage user authentication. Options include:
Any unauthenticated user attempting to access the tenant is redirected to the configured interactive IdP for authentication, ensuring a streamlined and secure login experience.
Using a single interactive IdP is a best practice for identity management and ensures consistency, security, and simplified administration.
Key reasons include:
User Identity Consistency: Qlik Cloud relies on a user's subject and email as unique identifiers. Managing a single interactive IdP helps prevent duplicate identities and ensures seamless user access, reducing risk of users gaining unauthorized access to sensitive data or permissions.
Streamlined Identity & Access Management: Since Qlik Cloud does not transform incoming claims beyond remapping keys, keeping authentication centralized prevents unintended variances in usernames, email formats, or group names. This improves security and reduces maintenance of licenses and entitlements.
Optimized Group Management: A single interactive IdP provides a consistent structure for groups, ensuring they align with an organization’s access policies. By managing group filtering in one place, organizations can maintain clear and structured permissions. Managing groups across multiple IdPs can quickly become unmanageable, leading to inconsistencies in user access.
Simplified Access Control: Groups in Qlik Cloud are referenced by name, making it more efficient to manage access through a single federated IdP rather than multiple sources.
Efficient Token Management: A unified IdP helps maintain consistency in authentication tokens, reducing administrative overhead and ensuring a smooth user experience.
Enhanced Security & Auditability: By centralizing authentication through a single IdP, organizations can apply security controls, enforce device policies, and monitor user access through audit logs.
A federated IdP ensures that organizations retain full control over authentication policies, while providing a seamless experience for users accessing Qlik Cloud.
Many organizations choose to use a federated identity provider to streamline identity management, enhance security, and improve user experience across multiple applications. Benefits include:
Centralized User Lifecycle Management: Users from different sources can be managed in a single system, reducing duplication and inconsistencies.
Improved Security Policies: Organizations can enforce multi-factor authentication (MFA), conditional access policies, and device trust settings at the IdP level.
Single Sign-On (SSO) Across Applications: Users authenticate once and gain seamless access to multiple platforms, including Qlik Cloud.
Comprehensive Logging & Compliance: A federated IdP provides consolidated audit trails and governance controls for user authentication.
By implementing a federated identity provider, organizations can maintain flexibility in their authentication strategy while ensuring compatibility with Qlik Cloud.
The recommended approach for organizations that need to authenticate users across multiple identity sources is to configure a federated IdP that consolidates authentication. Solutions like Azure Entra ID or Okta can be used to unify identity management and connect to Qlik Cloud via OIDC or SAML.
Set Up a Federated IdP (Azure Entra ID, Okta, or another identity management solution).
Sync Identity Sources within the federated IdP to ensure unique identities across different user groups.
Configure OIDC/SAML Authentication in Qlik Cloud with the federated IdP.
This approach ensures a secure, efficient, and scalable authentication strategy that aligns with best practices for enterprise identity management.
Qlik Cloud is designed to integrate seamlessly with a single interactive IdP, providing a robust and secure authentication framework. Organizations that need to consolidate multiple identity sources can achieve this through a federated IdP, ensuring centralized management, improved security, and a streamlined user experience. By leveraging enterprise-grade IdPs like Azure Entra ID or Okta, organizations can enhance their identity management strategy while maintaining full control over authentication policies and governance.
Environment
What is the default user session timeout for Qlik Sense Business and Qlik Sense Enterprise SaaS? Can the session timeout for Qlik Cloud be changed?
The default (fixed) value is set to 30 minutes. This is controlled by SESSION_TTL.
It is not currently possible to adjust the session timeouts in the Qlik Cloud.
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.
This Techspert Talks session covers:
- What to plan for
- Migration Pathways
- Cloud Best Practices
Chapters:
Resources:
This video will demonstrate how to use Qlik-CLI for SaaS to migrate Apps from your on-premises Qlik Sense environment to your Qlik Sense SaaS edition. Qlik-CLI makes it possible for scripting and automating App migration.
Note: These instructions apply to Qlik Cloud. Qlik Sense Enterprise on Windows functions similarly. See How To Edit Published Qlik Sense Apps on Qlik Sense Enterprise on Windows.
Qlik Cloud offers two different spaces to work in. Shared Spaces and Managed Spaces. Apps previously published to a Managed Space e cannot be edited in place, and they will need to be replaced by an app modified on a personal or shared space.
This article covers publishing to both. For additional information on the available space types, see Working in spaces.
Apps are not published to Shared Spaces. They are moved to or uploaded to them. Apps in shared spaces can therefore be edited freely by anyone that has the correct permissions, like any other unpublished app. Please, check Developing and sharing apps with shared spaces on the help site.
Apps cannot be edited directly in managed spaces. The developer will have to modify the original app which is present in their own personal space, or in a shared space. The app is always left in its original place when the app gets published: the publishing process will make a copy of the app, and keep the original where it was.
If the original app was deleted at some stage, a published app can be unpublished using the REST API. The developer will then be able to edit the unpublished app.
If the system cannot identify a connection (for instance, if the modified app was actually redeveloped from scratch) you will need to manually the space and the exact name of the published app and prompt to replace the app.
You can upload QlikView applications (.qvw files) to your Qlik Sense SaaS hub.
Uploaded apps cannot exceed 1 GB in size. If you are licensed for expanded apps, you can upload apps up to 2 GB in size. If you are licensed for dedicated capacity, you can upload apps up to 10 GB in size.
Qlik Cloud is a modern analytics and data platform built on the same software engine as QlikView and Qlik Sense Client-Managed and adds significant value to empower everyone in an organization to make better decisions daily. Qlik Cloud allows you to use one common platform for all users – executives, decision-makers, and analysts.
Navigation:
Migrating to Qlik Cloud can help your organization:
Q&A with Qlik: Qlik Sense Migration to Qlik Cloud
Articles relevant to migration and new Qlik Cloud users
This site provides you the tools to monitor, manage, and execute a migration from Client-Managed Qlik Sense to Qlik Cloud.
Index and home
Planning your migration
Setting up the Qlik Cloud migration tools
Create and configure a cloud tenant
This site provides you the tools to begin your journey to move from QlikView to Qlik Sense and Qlik Cloud.
This Techspert Talks session covers:
Chapters:
Resources:
Qlik Cloud Reporting – Improving Table Presentation
How to send an Excel report as an attachment using Qlik Application Automation
Creating an Automation from Templates
Tips For Designing Application Automation Reporting Reports
Click here to see video transcript
Qlik Cloud apps thumbnail's size is not limited and this could lead to undesired behaviours if such is not taken into account when adding the thumbnails to your apps.
Such undesired behaviour could be end users facing slowness when navigating trough the Catalog or the Home section.
The bigger is the size of your thumbnail on the app the longer it will take to be loaded, this could be easily seen in the Developer tools of the browser as below:
It is strongly recommended to use such images as optimized as possible ensure end users performance when navigations trough such sections.
The main contributor on the loading time of an app thumbnail will be its size (e.g 5B vs 5MB) resulting in different range of times.
A multi-cloud deployment allows you to distribute Qlik Sense apps to the cloud for consumption. You can set up your deployment to connect Qlik Sense Enterprise on Windows to Qlik Cloud. For more information on multi-cloud deployments, see: Multi-cloud deployments to Qlik Cloud
In these multi-cloud environments, Qlik Cloud can be considered an expansion of the Qlik Sense Enterprise on Windows platform, whereas all app development is carried out on the client-managed platform, and the apps can be made available for further consumption in Qlik Cloud.
Any additional editing (modifications of the Data Model) or duplication of the distributed apps is not possible directly on Qlik Cloud and needs to be carried out in Qlik Sense Enterprise on Windows.
Limited options are available on the Qlik Cloud hub for apps distributed from a client-managed platform:
In this article, we outline the ideal workflow used when distributing apps.
If you want to instead fully migrate an app to Qlik Cloud and make them available for modifications, then the app needs to be manually uploaded to the hub. Alternatively, we offer an automated option using the Qlik-cli (see the app import command).
Example Multi-Cloud App distribution setup in Qlik Sense
How To Publish Qlik Sense App to Qlik Cloud and Edit a Published Apps
This Techspert Talks session covers:
00:00 – Intro
00:51 - Migrating Strategy
02:17 - QlikView Governance Sense Profile Score
04:11 - SaaS Readiness Tool
05:37 - Hybrid Readiness Application
06:54 - Manual App Migration
10:05 - Qlik Data Access Gateway for local data
11:33 - Semi-Automated App Conversion
12:47 - QlikView Converter tool
13:37 - Master Items
17:59 - Migration Tools
18:41 - Refactoring stage
21:36 - Performance Evaluation
22:09 – Lineage
22:29 - Reload Schedule
22:45 - Completed 20 min Refactoring
24:33 - Cyclic Groups and Sense solutions
26:07 - Q&A: What if you can’t find a solution?
27:09 - Q&A: How can we do Cyclic Groups?
28:14 - Q&A: How to connect to On-Prem data?
29:01 - Q&A: How to get parameterised variables?
29:41 - Q&A: Where is the QlikView Converter tool?
30:08 - Q&A: Is there a license conversion tool?
30:46 - Q&A: Is there an NPrinting migration tool?
31:40 - Q&A: Can large QVWs perform in Cloud?
33:12 - Q&A: Is Qlik Sense Desktop still available?
33:36 - Q&A: Is there a Governance Dashboard for Cloud?
34:18 - Q&A: What Performance Evaluation tools?
Resources
Qlik Sense Visualization Best Practices
Qlik Sense Best Practices for Choosing Individual Visualizations
What if no standard chart suits my purpose?
Moving from QlikView to Qlik Sense SaaS
Qlik Sense Visualization Showcase
Optimizing Qlik Sense SaaS Apps with App Analyzer
Click here for video transcript
If your tenant is using the new navigation experience, Activity centers replace the Hub. For more information, see New platform navigation.
Welcome to Getting started with the Qlik Sense Cloud Analytics Hub and how to interact with an app. In this article, we'll cover the basics of how to navigate the Qlik Sense Cloud Hub and how to interact with the data provided in an app.
The example App used in the video and article (Beginner's Tutorial) can be downloaded from the Qlik Help site.
Click here for video transcript
Here is a link to the referenced Qlik Help site page in the video:
Tutorial - Beginning with the Basics
By default, the hub will show you all content available to you. This includes apps, charts, data, notes, and links. To begin filtering;
When you make selections, the colors of the values change accordingly. The characteristic Qlik Sense colors are green, white, and gray, and they represent the basic states: selected, possible, and excluded. To learn more about selections and their different states, see Selection states.
Depending on the visualisation used, different selection methods can be used, such as Click selection, Draw selection, Range selection, Lasso selection, Legend selection, and Label selection. For more information on each selection method available, see Make Selections.
Let's test some selections:
This concludes the basics of navigating the Qlik Sense hub and how to interact with visualisations.
Advanced material is available on Help.qlik.com, as well as in our Qlik Continuous Classroom offering:
Navigating in the user interface
Getting Started with Qlik Sense (Free Training)
Searching & Selecting Data (Free Training)
Create and Apply Bookmarks (Free Training)
Build and Play Stories (Free Training)
Creating analytics and visualizing data
Can QlikView Object Migration for Cloud connect through a proxy?
There is currently no support in the bookmark migration tool for a proxy. Make sure to set an exclusion allowing direct connection on port 443 to Qlik Cloud.
A Talend Administration Center execution plan allows you to execute multiple Job Conductor tasks in a predefined workflow. The workflow is presented in a hierarchical view, where each task can execute a set of child tasks in parallel or sequentially.
The parallel approach executes all tasks simultaneously. Whereas in the sequential approach, the end status of the previous task determines when each task launches. You can add tasks in sequential order based on the following conditions
OnOk: Launches a child task if the parent task finalizes without error.
OnError: Launches a child task if the parent task finalizes with error.
After: Launches a child task after the parent task finalizes, regardless of its error status.
In this example, the execution plan consists of five tasks, including parallel and sequential tasks:
The root of the plan has two parallel tasks: “test_users” and “test_address”.
If the execution of parallel tasks is successful, “test_names” task executes.
If the execution fails, the “test_error” task launches.
Finally, the “test_emails” task launches after the “test_names” task, irrespective of the error status.
The plan also has a CRON-based trigger defined, trigger_plan, which executes every quarter on the 5th at 12:37.
Talend Cloud Migration Platform collects and aggregates on-premises assets from Talend Administration Center and migrates them to Talend in the cloud. As a result, you can get a holistic view of all of the on-premises data from different Talend Administration Center environments in a centralized location.
To do so, you must register Talend Administration Center servers in Talend Cloud Migration Platform by providing their Talend Administration Center web URL endpoint and database connection details. Once the servers are registered, Talend Cloud Migration Platform collects all the assets, including execution plans and their respective tasks. The aggregated list, across all of the registered Talend Administration Center servers, is then displayed in Talend Cloud Migration Platform.
You can view the execution plans and tasks in their respective Talend Cloud Migration Platform UI pages.
Migrate Talend Administration Center tasks and execution plans from on-premises to Talend in the cloud by performing the following five steps:
Select the source Talend Administration Center environment, in this case, TacDev, and then click the Cloud button.
Select the destination Talend Management Console Environment and its respective Workspace from the drop-down menu. The destination environment is where you will migrate and execute the assets.
The lists of Remote Engines and Remote Engine Clusters are refreshed based on the selected Talend Management Console environment and workspace.
Cloud Engine
Remote Engine
Cluster of Remote Engines
Toggle the Artifact option to Off. However, this setting applies to all the tasks and will not migrate artifacts with the same name even if multiple tasks did not share them.
Migrate the affected tasks before the plan, and then migrate the plan with the Artifact option toggled Off.
You can view the newly migrated execution plan and tasks in the Talend Management Console UI, and easily confirm that they migrated successfully.
The tasks in the plan are arranged sequentially and represented in the form of steps:
Step 2 launches the test_name task only if parallel tasks in Step 1 are executed.
Step 3 executes test_emails after Step 2, irrespective of the error status.
Talend Administration Center plan CRON trigger, which executes Every quarter on 5th at 12:37 is mapped to TMC MONTHLY trigger which executes Every 3 month, on 5th at 12:37.
Talend white paper Self-Service Talend Migration shows you how to migrate your Talend on-premise to Talend Cloud. Highlights include; ensuring success by planning and assessment, Talend project audit, and potential pitfalls.
Content:
The best practice depends on if you’re already using Talend Cloud extensively.
If you have developed a lot of Jobs, the best practice is not to do anything - at least in the short term. Talend Cloud is backward compatible with most Studio versions (currently to 6.5). So even if Studio is on an older version, Jobs will work.
The same applies to Remote Engines. For example, you can still use the old 2.5 Remote Engine though the latest one is version 2.8. However, Talend recommends that you upgrade. Look for the times when the project is stable or when you're starting a new project.
If you haven’t developed a lot of Jobs and are at release 6.5 or newer, or if you really want to use a new feature, you're welcome to upgrade Studio and Remote Engines.
For more information, see Talend Support Statements.
After you upgrade the Git/GitHub repository, it cannot revert back to the old version, so you need to duplicate (copy or clone) your Git/GitHub repository to a new repository. Then, if there are any issues, you can always fall back to the old project and on-premises Talend.
Use the repository copy to create a new project in Talend Cloud TMC. The Git/GitHub URL will be downloaded to Studio at the first connection. The repository will be automatically upgraded at this time. Individual Jobs may need a tweak or two. For example, any deprecated components should be replaced.
To upgrade a Remote Engine, simply install and pair it. The new Remote Engine can be installed on the same compute resource as the existing resource. However, if any changes to the default configurations (memory, parallel executions) have been made, they need to be applied to the new Remote Engine.
When using UNC paths in Talend Cloud, observe the following:
When hard-coding the UNC path within a file component, the format is "\\\\networkdrive\\folderA\\folderB\\file.txt" (quoted-string)
When using Context Variable and setting the type to Directory, then the path format is \\networkdrive\folderA\folderB\file.txt (backslashes do not need escaping)
When using Context "connection _" Variable, the corresponding connection in the cloud environment is \\\\networkdrive\\folderA\\folderB\\file.txt (no quotes) for the value
To facilitate a smooth migration from on-premises to Talend Cloud, Studio context variables should conform to Talend Cloud connection parameter naming standards. This is for context variables used for connections to external data systems. These can then be stored in context metadata and shared with multiple Talend Jobs.
Context variables to be used for connections should use the following pattern:
connection_<conntype>_<param1..n>
Where connection_ is a fixed string, <conntype> is the type of connection, and <param> is the parameter that matches one of the connection component parameters (for example, userid, password, and server). <conntype> can be anything.
For more information, see the list of Talend Cloud out-of-the-box supported connections.
Jobs that run in TAC require double quotes for string values in context variables. However, Talend Cloud strings must not use double quotes. The following example shows the two sets of values for the context variable fileName. One conforms to Jobs run in TAC, the other to Jobs run in Talend Cloud.
Double-quote errors in the Talend Cloud execution log are similar to:
Failed
tFileInputDelimiter_1 - "C:\IntroTalendStudio\prod\"refProducts.csv (The filename, directory name, or volume label syntax is incorrect)
If your on-premises project is several releases behind the latest Talend Cloud version, you may want to compile all your Jobs to uncover any migration issues. If you have many Jobs in your project, Talend recommends that you consider installing and deploying Continuous Integration for Talend Cloud to automate the compile. Note any compile failures and take corrective action.
Common causes of compile failures in an on-premises migration include:
Deprecated components
Incompatible Java versions
Old database drivers
External sourced components
Talend recommends that you perform analysis on your on-premises Talend projects and Jobs to anticipate any migration challenges, and to reduce risk.
Remote Engine and Runtime servers can be sized very similarly to Remote JobServers. However, you have to take the following into consideration:
Memory and CPU requirements of the Jobs you're going to run
All are Java, so there there can be great variety in run unit size
Simultaneous Job execution requirements, such as how many Jobs are required to be running at the same time
Based on this: (highest Job RAM requirement X max count of simultaneous Jobs) + 25% (or 33% or 50% -- pick a fudge factor) = initial sizing.
Be sure to account for the overhead of the Operating System, plus the memory requirements of the Talend Cloud Remote Engine and optionally the Talend Runtime.
An easier alternative, and recommended best practice is to resize your compute resource on the fly. As compute resources are practically a commodity, changing size after the initial go-live is easy.
Start with a 4 CPU and 16 GB RAM configuration.
Monitor your Jobs.
Scale the compute node up or down from there as your load requires.