Qlik Application Automation

Qlik Application Automation is a no-code visual design tool for automating manual work. Instead of writing code, users combine configurable blocks that they drag and drop onto a canvas, forming a sequence of action steps from a variety of SaaS applications, including Qlik Cloud.

These steps run like a program to automate business processes, using analytics to direct the flow of data through a multitude of applications.

Automations can be executed manually, run on a schedule, listen to webhook events, and be triggered using an API endpoint. Automations are compiled into native code that runs in Kubernetes pods on Qlik Cloud to automatically provide the scalability you need to scale and automate your business processes.

Qlik Application Automation provides blocks to implement conditions, work with loops, use variables, and a wide range of other building blocks to implement automation flows.

Architecture

Qlik Application Automation is an integral part of Qlik Cloud and is available in a Qlik Cloud tenant alongside other capabilities such as analytics applications, connectivity to your data sources, and notes.

The elastic nature of the underlying technology allows Qlik Application Automation, as well as the other Qlik Cloud services, to scale horizontally as needed.

Qlik Application Automation shares access to common services, such as authentication services and file storage, to ensure an integrated experience with the other data analytics and data integration capabilities within Qlik Cloud.

For more information about the Qlik Cloud architecture, see the The Qlik Cloud platform technical paper evaluation guide.

Reliability

As part of the Qlik Cloud platform, Qlik Application Automation is built on a resilient, autoscaling architecture to handle any customer workload. Qlik Application Automation is subject to the same uptime commitment policy reported in the Service Level Agreement (Section 7, point 7.2).

Automations

Blocks

Every automation is made of different building blocks chained together to build a flow. There are three types of building blocks:

• Start block
• Standard blocks
• Connector blocks

Start blocks

The Start block is your starting point and mandatory in each automation. It is already present on the canvas and defines the start of the automation process; any other block in the automation must be connected to the start block chain.

Standard blocks

Standard blocks fall into four categories: Basic, List, Advanced, and Cloud storage. Some example uses are:

• Loop over data and conditional block
• Working with variable and user input block
• Merge, filter, lookup or transform lists block

Connectors

Qlik Application Automation offers a range of connectors. Connectors are the bridge between third-party applications and the automation itself. They can be used to get data from or write data to a third-party application.

There are too many connectors to cover them all here, and we regularly add new connectors to the platform. For information on all connectors available see Application Automation connectors in the help.

Qlik Cloud connectors

As well as connectors to other platforms and services, Qlik provides connectors to perform actions on Qlik Cloud itself. These cover the full life-cycle of Qlik Cloud from tenant provisioning to reporting.

Qlik Cloud Services connector

One connector of note is the Qlik Cloud Service connector, it allows the connection to the user's current tenant. It does not require authentication and comes with the same logged-in user's authorization.

Qlik Cloud Platform Operations connector

The Qlik Cloud Platform Operations connector can orchestrate one or many Qlik Cloud tenants using either tenant or subscription OAuth clients.

Qlik Reporting services connector

Qlik Reporting is a Qlik-native connector that lets you build customized, multi-page reports based on app sheets. Reports can be deliverer via e-mail as PDF or PowerPoint documents.

Run modes of automations

Automations are built by combining blocks that represent API endpoints of connected applications. Each Automation execution is called a job or run. Automations can be run either manually, or automatically. Manually an automation can be run either from he console, or directly within the automations editor.

Automations can be executed in three ways systematically:

• On a scheduled basis - from every 30 seconds, up until monthly.

• Triggered from an external webhook

• Exposed as an API Call

Use cases

Given the flexibility and wide range of connectors supported by Qlik Application Automation, several common types of use cases are possible:

• Operational automations in service of Qlik Cloud: Qlik Application Automation provides a direct visual access to various Qlik Cloud APIs to facilitate operations such as:

• Task chaining (e.g., Qlik Cloud Services app reloads)

• App versioning

• Assign licenses, roles, spaces, rights to users

• Alerting and messaging: send messages using e-mail, Slack, and MS Teams triggered by events

• Active intelligence: Reverse ETL and write-back in business applications (such as CRM, SCM, ERP etc.) based on analytical insights

These use cases can be combined to create complex automations to support business processes, implemented in the same automation or by chaining different automations together.

Security model

Connector authorization and authentication

In general, connectors allow two types of authentication, and this is dependent on the third-party provider service:

• Access token authentication

• OAuth authentication

The access token authentication method requires users to provide an access token (e.g., API key or secret) to the third-party application and provide it in the connector settings.

With OAuth authorization, users are forwarded to the application login page which requires user permission access to grant access to Qlik Application Automation, on behalf of Qlik Cloud. If the user agrees, Qlik Application Automation will store and refresh the access token for accessing data in the automations.

Qlik Application Automation will request both read and write permissions in OAuth flows, due to the nature of the features.

Automation owners can export automation in a JSON file format and subsequently import them in a different tenant or share with other users on the same tenant. Authentication tokens are not part of the export; thus, the import requires a re-authentication of all the connectors involved in the automation.

Governance

The Qlik Cloud platform's management console allows any administrator to manage and govern all the automations. An administrator is entitled to list all the tenant's automations, and sort and filter them based on their name, status, last run, run mode, owner or completed time. Each automation can further show the list of executions and their states.

A Qlik Cloud administrator may enable or disable automations, change owner, or delete them.

Data privacy and compliance

An automation can make API calls to connected SaaS applications (e.g. Salesforce), retrieving data for processing within the automation. For example, a user could build an automation that fetches contacts/leads from their CRM and send it on to another SaaS application. Each automation job will have a history log that shows the API calls made by each block.

Where an automation processes personally identifiable information (PII), or other private data, part of this data will also be present in the history log of the automation. History logs can be viewed in the UI for each automation. History logs have a retention of 30 days and are automatically deleted afterwards. These logs are only visible to the automation owner and can not be viewed by other users or administrators.

In cases where there is a requirement not to log this type of data, it is possible to disable the logging of information on a per-block basis within the automation. This ensures this data in never written to the logs of the automation.