Do not input private or sensitive data. View Qlik Privacy & Cookie Policy.
Skip to main content

Announcements
Join us at Qlik Connect 2026 in Orlando, April 13–15: Register Here!

Qlik Cloud Monitoring Apps Workflow Guide

100% helpful (13/13)
cancel
Showing results for 
Search instead for 
Did you mean: 
Sonja_Bauernfeind
Digital Support
Digital Support

Qlik Cloud Monitoring Apps Workflow Guide

Last Update:

Mar 19, 2026 2:11:55 AM

Updated By:

Sonja_Bauernfeind

Created date:

Nov 10, 2023 5:18:18 AM

This template was updated on December 4th, 2025 to replace the original installer and API key rotator with a new, unified deployer automation. Please disable or delete any existing installers, and create a new automation, picking the Qlik Cloud monitoring app deployer template from the App installers category.

Installing, upgrading, and managing the Qlik Cloud Monitoring Apps has just gotten a whole lot easier! With a single Qlik Automate template, you can now install and update the apps on a schedule with a set-and-forget installer using an out-of-the-box Qlik Automate template. It can also handle API key rotation required for the data connection, ensuring the data connection is always operational.

Some monitoring apps are designed for specific Qlik Cloud subscription types. Refer to the compatibility matrix within the Qlik Cloud Monitoring Apps repository.

 

'Qlik Cloud Monitoring Apps deployer' template overview


Screenshot 2026-01-19 at 13.28.22.png

This automation template is a set-and-forget template for managing the Qlik Cloud Monitoring Applications, including but not limited to the App Analyzer, Entitlement Analyzer, Reload Analyzer, and Access Evaluator applications. Leverage this automation template to quickly and easily install and update these or a subset of these applications with all their dependencies. The applications themselves are community-supported; and, they are provided through Qlik's Open-Source Software (OSS) GitHub and thus are subject to Qlik's open-source guidelines and policies.

For more information, refer to the GitHub repository.

 

Features

  • Can install/upgrade all or select apps.
  • Can create or leverage existing spaces.
  • Programmatically verified prerequisite settings, roles, and entitlements, notifying the user during the process if changes in configuration are required, and why.
  • Installs latest versions of specified applications from Qlik’s OSS GitHub.
  • Creates required API key.
  • Creates required analytics data connection.
  • Creates a daily reload schedule.
  • Reload applications post-install.
  • Tags apps appropriately to track which are installed and their respective versions.
  • Supports both user and capacity-based subscriptions.

 

Configuration:

Update just the configuration area to define how the automation runs, then test run, and set it on a weekly or monthly schedule as desired.

Configure the run mode of the template using 7 variable blocksConfigure the run mode of the template using 7 variable blocks

Users should review the following variables:

  1. configuredMonitoringApps: contains the list of the monitoring applications which will be installed and maintained. Delete any applications not required before running (default: all apps listed).
  2. refreshConnectorCredentials: determines whether the monitoring application REST connection and associated API key will be regenerated every run (default: true).
  3. reloadNow: determines whether apps are reloaded immediately following updates (default: true).
  4. reloadScheduleHour: determines at which hour of the day the apps reload at for the daily schedule in UTC timezone (default: 06)
  5. sharedSpaceName: defines the name of the shared space used to import the apps into prior to publishing. If the space doesn't exist, it'll be created. If the space exists, the user will be added to it with the required permissions (default: Monitoring - staging).
  6. managedSpaceName: defines the name of the managed space the apps are published into for consumption/ alerts/ subscription use.If the space doesn't exist, it'll be created. If the space exists, the user will be added to it with the required permissions (default: Monitoring).
  7. versionsToKeep: determines how many versions of each staged app is kept in the shared space. If set to 0, apps are deleted after publishing. If a positive integer value other than 0, that many apps will be kept for each monitoring app deployed (default: 0).

 

App management:

If the monitoring applications have been installed manually (i.e., not through this automation), then they will not be detected as existing. The automation will install new copies side-by-side. Any subsequent executions of the automation will detect the newly installed monitoring applications and check their versions, etc. This is due to the fact that the applications are tagged with "QCMA - {appName}" and "QCMA - {version}" during the installation process through the automation. Manually installed applications will not have these tags and therefore will not be detected.

 

FAQ

Q: Can I re-run the installer to check if any of the monitoring applications are able to be upgraded to a later version?

A: Yes. The automation will update any managed apps that don't match the repository's manifest version.

Q: What if multiple people install monitoring applications in different spaces?

A: The template scopes the application's installation process to a managed space. It will scope the API key name to `QCMA – {spaceId}` of that managed space. This allows the template to install/update the monitoring applications across spaces and across users. If one user installs an application to “Space A” and then another user installs a different monitoring application to “Space A”, the template will see that a data connection and associated API key (in this case from another user) exists for that space already. It will install the application leveraging those pre-existing assets.

Q: What if a new monitoring application is released? Will the template provide the ability to install that application as well?

A: Yes, but an update of the template from the template picker will be required, since the applications are hard coded into the template. The automation will begin to fail with a notification an update is needed once a new version is available.

Q:I have updated my application, but I noticed that it did not preserve the history. Why is that?

A: Each upgrade may generate a new set of QVDs if the data models for the applications have changed due to bug fixes, updates, new features, etc. The history is preserved in the prior versions of the application’s QVDs, so the data is never deleted and can be loaded into the older version. 

Labels (1)
Comments
PurpleHRM
Partner - Contributor
Partner - Contributor

@Dave_Channon After running the Qlik automation deployer, it appears that the Shared apps are not installing anymore. We would prefer to have an customizable App Analyzer, is there still a way to achieve this? 

Dave_Channon
Employee
Employee

@PurpleHRM If you set the versionsToKeep variable to 1, it'll keep the latest shared space version. Does that help?

The other option is using these apps as a managed set, then binary loading from them with a UI app which you then customize (i.e. use them as a data source).

PurpleHRM
Partner - Contributor
Partner - Contributor

@Dave_Channon So it appears that there is no option for the automation itself to 'automatically' install the shared apps aswell? I think our best option would be to manually install it in a shared space then, correct?

Dave_Channon
Employee
Employee

@PurpleHRM what the deployer does is:

  • If an update is needed, imports the newest version of an app to the shared space
  • Publishes or republishes this app to the managed space
  • Checks the value of versionsToKeep and if set to 0, removes all apps in shared space, otherwise keeps the number set in the variable (newer apps kept first).

Probably the binary load pattern would be the better pattern for you since then you're completely isolated from the somewhat managed process that the deployer does. You could just put Binary... exit script; at the top of the load script in your own copy of the relevant app in your own shared space, then reload them when needed from the managed apps. That would be very fast since it's binary loaded and means you'd still get bug fixes and updates. We rarely change the actual model structure in those apps.

Version history
Last update:
3 weeks ago
Updated by: