Packaging shift to third-party runs for Qlik Automate

[Emile_Koslowski]

Beginning on the 30th of January, Qlik introduced the concept of 3rd party runs in Qlik Automate. This is the first step towards a shift in our packaging that will focus on third-party runs only, while standard runs become free of charge.

This shift will happen over the course of a couple of months, giving you sufficient time to analyze your usage and make adjustments if necessary. Please reach out to your account manager if you have any questions.

Contents

• Timeline
• Standard run vs third-party run
• Standard runs
• Third-party runs
• Possible third-party runs
• Transition of existing entitlements
• Introduction of third-party runs (Jan 30th)
• Switch to new packaging (April 2nd)
• Enforcement of overages (May 6th)
• Packaging details
• FAQ

Timeline

The timeline below illustrates how the various stages of this packaging update will happen. In between each stage should be sufficient time to analyze your usage and prepare for the enforcement.

• January 30th: Introduction of third-party runs
• April 2nd: New third-party packaging is available for purchase 
• May 6th: Enforcement
  • Third-party limits for seat-based licenses
  • Third-party overages for capacity licenses

Standard run vs third-party run

Standard runs

An automation run is considered a standard run if it only executes blocks from the following categories:

• All Qlik connectors (Qlik Cloud Services, Qlik Reporting, Qlik AutoML, Qlik …)
• Base blocks (excluding Call URL & Cloud Storage)
• Mail & Microsoft Outlook

Example:

Third-party runs

An automation run is considered a third-party run if it executes any blocks that are not in the standard connector categories.

As a rule of thumb, a standard run will execute one or more blocks from third-party connectors. Among others, third-party connectors are connectors like Slack, Amazon S3, Microsoft Excel, Call URL. A full overview of all automation connectors if available here.

Example:

Every run of this automation will execute the Send Message (Slack) block.
This will make every run a third-party run as the Slack connector is a third-party connector.
The “Contains third-party blocks” label indicates that the automation contains an active third-party block.

Possible third-party runs

For a run to be considered a third-party run, we only evaluate executed blocks. If the third-party blocks in the automation were not executed, the run will not count as a third-party run. A block not being executed could be caused by many factors like Condition blocks, Filter List blocks, deactivated third-party blocks, ...

This illustrates that an automation with a “Contains third-party blocks” label will not necessarily generate third-party runs on every run.

Example:

This automation will only execute the Send Message (Slack) block if the reload fails (from the Do Reload block). This means it will only generate third-party runs depending on the state of the Condition block.

Transition of existing entitlements

Introduction of third-party runs (Jan 30th)

1. Customers who are entitled to included runs will get these as third-party runs
2. Purchased runs will be converted to third-party runs
3. Renewals before the end of March will maintain the same included third-party runs until next renewal.

Switch to new packaging (April 2nd)

1. Every new purchase will be using the new packaging
2. Renewals will revert third-party runs to the edition included quantity of the new packaging + any purchase of third-party runs using the new packaging

Enforcement of overages (May 6th)

1. When your monthly third-party runs are exhausted, overages will be enforced.
   1. For Capacity licenses with included third-party runs only, automations with active third-party blocks will no longer start and an overage status will be displayed. 
   2. For Capacity licenses with purchased third-party runs, overages will be charged according to your contract and configuration.
   3. For User based licenses with included or purchased third-party runs, automations with active third-party blocks will no longer start and an overage status will be displayed. 
2. Automations without active third-party blocks will continue to run (since they cannot generate third-party runs).

Packaging details 

The below table provides an overview of the new packaging for automations that will come in effect on April 2, 2025. Please reach out to your account manager for quotes and pricing related questions. 

FAQ

1. Will max concurrency be shared across run types?
Yes, both run types will count towards the same max concurrency.

2. Will usage of Qlik APIs through the Call URL block or other generic connectors count towards third-party runs?
Yes, when these blocks and connectors are used to make API requests to Qlik APIs, they will still count towards third-party runs. If you are missing blocks or functionality in a Qlik connector, please create an improvement request on our Ideation portal or support an existing request.

3. Will the new packaging have an included amount of third-party runs?
Yes, the new packaging will continue to provide some third-party runs for most editions of Qlik Cloud. Details are available in the above section "Packaging details".

4. Why are some automations with third-party blocks missing the label "Contains third-party blocks"?
An automation will only receive the label when someone performs a manual run or saves it in the editor. We are planning a new update that will apply this label to all automations with active third-party blocks regardless of someone saving them or not.
Please note that regardless of this label being on an automation or not, automation runs will still be evaluated and receive a correct billable yes/no label.

[AlexOmetis]

I think this is a great move - although need to see the pricing & packaging for the third-party runs. It means customers don't need to purchase more automations (or come up with strange architectures to avoid that) just to run more reloads in Qlik Cloud. 

@Emile_Koslowski - One question: Will standard runs still count against concurrent automation runs? We've seen some customers hitting the maxConcurrentAutomationRuns limit of 5 (or 10, depending on which document you look at) with reload automations so this is an important question. 

[chriscammers]

I think this is a great change but a couple of thoughts come to mind.

I was working on some OEM use cases where we were hydrating a new tenant by grabbing content from a parent tenant. In this case I was using the generic api connector to perform actions on the child tenant. It would be helpful to either enable the native blocks to connect to other tenants or duplicate some of the native blocks with a configuration option to connect to another tenant.

I'm looking forward to how this will work out.

Thanks

Chris

[Emile_Koslowski]

Hi @AlexOmetis & @chriscammers , thanks for the questions, I've added an FAQ section to the document.

[AnandKu]

Possible to have the details in the connector part so customer can know which is 3rd party and not quickly by looking at it ,? @Emile_Koslowski 

[DanielZandersQlik]

@AlexOmetis The high concurrent runs we see with many customers caused by using Automations for Reload. Beside a native solution coming my recommendation is always to not use do reload and wait. Most Reload automations just run and wait for Reloads and this way block slots. You can build better solutions by just use the Webhooks to trigger when reload finished and then check if this should start a new Reload. This way Automation runs a few seconds and not hours. 

[AlexOmetis]

@DanielZandersQlik Yes, now that first-party automations aren't counted against your allowance customers can architect much more nimble setups like that. Just getting rid of licensing workarounds is a big benefit - e.g. before it was better to have an automation running pretty much permanently (until it times out, when you trigger it again) to execute an every-5-minutes reload than it was to have it just run every 5 minutes.

[achampire]

Is there any information available somewhere about the price for this third-party run?

April 2nd is coming soon, and some practices—such as writing a message on tools like Teams or Slack when a reload finishes or a new user connects to the tenant—should be reconsidered

[adam_groenbeck]

Hello,
we have a customer that had purchased 20.000 automation runs, but now the customer suddenly has 2.000 3rd party automation runs in the overview?
It was by understanding from the post, that any purchased automation runs would be converted into 3rd party automation runs?

[rodolfoboscolo]

This is great, and it was really helpful to see the next steps for the product.

However, one key piece of information is missing—something many people are eager to know: What are the available quantities for each type of automation moving forward?

Will every environment now have 400,000 Standard Automations and 5,000 Third-Party Automations? What’s the new rule?

[rodolfoboscolo]

@adam_groenbeck 
I had a similar case—I had to request the renewals team to adjust it by allocating the 20K to the third party, and they quickly resolved it.