I am starting the assessment of migrating our on-premise Qlik Sense environment to the cloud. We are using Vizlib (Library, Finance) and NPrinting. I would like to know whether Qlik Reporting Service fully supports Vizlib components like NPrinting does, especially for the Vizlib Finance part.
Thanks for the questions. Third party extensions are currently not supported, as you can see here. This article explains why we have this limitation. On the other side, Qlik Cloud provides many new native objects. I would recommend to use then in combination with the reporting functionality.
Help users find answers! Do not forget to mark a solution that worked for you! If already marked, give it a thumbs up ! 🙂
The article is more of a marketing statement than a technical one. There is no reason why Qlik could not establish partnerships with professional extension vendors. These vendors are valuable partners who make it possible to use Qlik in specialized business scenarios. Security could be handled in a different way, for example by introducing a Qlik certification process for third-party components.We rely heavily on Vizlib Finance, as there is currently no equivalent solution available in Qlik Cloud. This makes support for Vizlib components a key consideration in our migration assessment.
If memory serves, some Vizlib Library objects work in NPrinting (Table works, iirc, and I think Pivot Table does too). I would strongly suggest taking this up with Vizlib Support directly, though - they would know the latest state.
I fully understand the architectural rationale behind this decision. Running arbitrary third-party JavaScript inside a cloud reporting microservice would indeed introduce significant security and operational risks.
However, there are several technical approaches that could mitigate these risks without completely excluding trusted third-party extensions.
1. Vendor certification program
Qlik could establish a certification process for extension vendors.
Certified extensions would undergo:
Source code review
Dependency analysis
Vulnerability scanning
Penetration testing
Performance and memory validation
Compatibility testing with the Qlik Reporting Service
Only certified versions would be allowed to execute within the reporting infrastructure.
This model is already common in many enterprise software ecosystems.
2. Trusted extension whitelist
Instead of blocking all third-party extensions, Qlik could maintain a whitelist of approved extensions.
During report generation, the Reporting Service could verify:
Extension identifier
Version
Digital signature
Certification status
If all checks succeed, the extension would be executed. Otherwise, the request would be rejected.
This approach significantly reduces the attack surface while supporting trusted partners.
3. Digital code signing
Each certified extension package could be digitally signed by its publisher.
Before execution, the Reporting Service would verify:
Publisher authenticity
Package integrity
Signature validity
Unsigned or modified extensions would never be executed.
This mechanism is widely used for browser extensions, operating systems and enterprise software deployment.
4. Sandboxed execution
Instead of running extensions directly inside the reporting engine, they could execute in an isolated sandbox.
Possible technologies include:
Dedicated containers
Restricted JavaScript runtimes
Browser sandboxing
Read-only execution environments
WebAssembly where applicable
The execution environment would have:
No file system access
No network access
No operating system access
Strict CPU and memory limits
Execution time limits
Even if an extension contained malicious code, its impact would remain isolated.
5. Restricted Reporting SDK
Extensions used only for report rendering do not require full access to the Qlik platform.
Qlik could expose a dedicated Reporting SDK limited to:
Data retrieval
Layout information
Rendering APIs
Sensitive platform capabilities would remain unavailable.
This follows the principle of least privilege.
6. Runtime policy enforcement
The Reporting Service could enforce runtime policies such as:
Maximum execution time
Maximum memory consumption
Allowed API calls
Maximum output size
Blocked browser APIs
No external network requests
Extensions violating these rules would be automatically terminated.
7. Shared responsibility with certified partners
Partners such as Vizlib could assume responsibility for maintaining compatibility with each Qlik Cloud release.
Qlik would certify the platform integration, while partners would certify functional compatibility of their extensions.
This shared responsibility model is already common in enterprise cloud platforms.
8. Customer-controlled trust model
Enterprise customers could explicitly decide whether to allow certified extensions within their tenant.
For example:
Native Qlik visualizations only (default)
Qlik-certified partner extensions
Organization-approved certified extensions
This gives each customer the flexibility to choose the level of security and governance that best matches their internal policies.
Why this matters
Companies like Vizlib are not unknown third-party developers. They are long-standing Qlik technology partners whose products have become an integral part of many enterprise deployments.
In our case, we rely heavily on Vizlib Finance because there is currently no native Qlik Cloud equivalent offering the same financial reporting capabilities. Rebuilding these reports using native visualizations would require a significant investment while still resulting in reduced functionality.
The current limitation therefore represents a significant obstacle for organizations evaluating a migration from Qlik Sense Enterprise on Windows to Qlik Cloud.
A trusted extension framework based on certification, digital signatures, sandboxing and runtime controls could provide a balanced solution that protects the platform while preserving the advanced functionality that many enterprise customers depend on.
