Introducing our new packaging model for Jira Cloud Automation

[#1]

We have heard a lot of feedback and questions about the upcoming changes to Jira Cloud Automation packaging and acknowledge that this is a significant change for affected customers. We want to share some additional information:

• Per our analysis, these changes will impact fewer than 5% of Jira Cloud Free, Standard, and Premium Edition customers.

• We have accelerated the rollout of the new Automation usage tab in the Jira Cloud admin console to all of you to see your usage in new model. It is now live so you can monitor and adjust your usage directly. A screenshot has been added to the post below.

• Customers on annual subscriptions will not have the new limits enforced until their next renewal quote creation date.

• Jira Cloud Standard edition customers who are currently projected to exceed limits in the new model will have access to a 3-month trial of Premium at the price of Standard.

To learn more about how to view your Automation usage and how your usage is calculated, please see the following support articles; View your automation usage and How is my usage calculated?. We have also updated some of the FAQs below to give you more complete information.

Hello Community 👋

On November 1, 2023, we are launching a new Automation packaging model for all Jira Cloud products (Jira Software, Jira Service Management, Jira Work Management, and Jira Product Discovery).

What’s changing?

Today, Automation usage is measured differently across both rule types and Atlassian products. Currently, there is only one pooled limit for all Jira Cloud products. Every time an Automation rule runs, it counts towards that limit regardless of whether it performed a successful action or not. The new packaging model brings a simpler, more consistent way to measure Automation usage. Each product will now have a fixed number of monthly rule runs based on the plan.

Here is a summary of the key changes for Jira Cloud products:

1. Only rules that perform a successful action will count towards the limit

In today’s model, rule runs count toward your usage limit, even if they perform no actions. For example, let’s say you have the following rule set up:

• Trigger: When an issue is created

• Condition: If issue type = Bug

• Action: Set Affects version field to Last released version

This rule would trigger and count toward your execution limit every time an issue was created, even for issues that aren’t bugs. In the new model, the rule will only count if the issue created is a Bug and the Affects version field is successfully updated.

2. Each Jira product will have its own limit

In today’s model, customers get a single, pooled limit across all Jira products. For example, if a customer has JSW Standard and JSM Free, they would get a total of 600 Automation rule runs per month (100 from JSW Free and 500 from JSM Standard) that can be used across both products.

• Each Jira product will have its own usage limit in the new model. Every Automation rule draws on the limit of a specific Jira product when it runs. We have increased the limits for our Free and Standard plans. Automation limits in the new model are shown on our support page here.

3. How will rules be counted in the new model

In today’s model, an Automation rule that is configured to run in a single Jira project does not count toward the usage limit. In the new model, all Automation rule types (i.e. single project, project type, multi-project, and global rules) will count towards the usage limit.

As we expand Automation to Atlassian products beyond Jira, these changes enable a simpler and more consistent usage attribution model for Automation - allowing customers to use Automation more efficiently for cross-product and cross-team collaboration.

We’ve also taken this opportunity to increase usage limits to give customers a larger runway to manage this change and confidently grow Automation usage in the future.

Things you can do to prepare for this change

Here are a few suggestions to help you prepare for the change coming into effect on November 1, 2023.

1. Preview your usage in the new model

From October 1st -31st, 2023, you’ll see a Preview option on the Global Automation screen next to the current usage tab.

This will help you understand how your usage translates into the new model. We will not be enforcing new model limits during this period.

2. Optimize your Automation usage

If the new usage tab (available October 1st) shows that your Automation usage is breaching (going over) the new limits, we recommend looking at your current rules and optimizing them to lower your usage. Here are some things you can do:

• Configure your rules to run where they need to: Make sure your rule runs only in the Jira projects (or Confluence spaces) you want it to run in.

• Add conditions to your Automation rules: Ensure that actions occur exactly when you want them to in order to maximize the value you get out of your rules.

• Disable rules: Monitor your rules and identify the ones that are either running too often or rules that you don’t need, and disable them to prevent wasteful rule runs.

FAQs

What is the difference between the current packaging model and the new one?

In the old packaging model:	In the new packaging model
All Automation rule runs are aggregated as a single limit across all of your Jira Cloud licenses.	Each Jira Cloud product will have its own limit and will be measured per product license.
Any rule that is triggered, regardless of successful action, counts towards your limit.	Only rules that create a successful action will count towards your limit.
Rules that are set up as a project-type, multi-project, globals count towards your limit. Single-project rules are unlimited and don’t count towards your limit. Actions (log action, create lookup table, create variable) count towards your limit.	Rules that are set up as a single-project, project type, multi-project, and global rule will count towards your limit. Actions (log action, create lookup table, create variable, refetch issue, and look up issues) don’t count toward your limit.

How do I know whether or not I am impacted?

All customers will receive a notice by email by October 2, 2023 indicating whether they will exceed limits or not in the new model.

Global administrators will have access to the Automation usage tab in Jira settings that shows the new per-product limits. This will help admins see the new packaging model in the context of their current and projected Automation usage, and be more proactive about their usage if they need to. Visit our support documentation to learn more.

What impact does this have on those with annual subscriptions?

If you’re on an annual Atlassian Cloud subscription and approve a valid annual quote dated prior to October 18th, 2023, limits in the new model will apply on the next renewal date.

Are there any rules that won't count towards usage?

The following actions won't count towards your usage:

• System rules that support core product functionality are unmetered. We will roll out the new packaging with two system rules implemented for JSM:

  • Attaching a risk assessment form for change requests

  • Transition issue in the project on deployments

• Actions that run and only perform: log action, create variable, create lookup table, refetch issue, and look up issues won’t count toward your usage.

How do I optimize my rule runs?

1. Configure your rules to run where they need to: Make sure your rule runs only in the Jira projects (or Confluence spaces) you want it to run in.

2. Add conditions to your automation rules: Ensure that actions occur exactly when you want them to in order to maximize the value you get out of your rules. (e.g. filter by Jira Issue status)

3. Disable rules: Monitor your rules and identify the ones that are either running too often or rules that you don’t need, and disable them to prevent wasteful rule runs.

4. Speak with support and partner teams

   1. If you have an annual subscription, get in touch with support, partners, or customer advocates to understand how the packaging change applies to you.

   2. If you are on a Jira Cloud JSW, JSM, or JWM Standard edition and receive a notification that you are breaching limits in one or more products, speak with our Support, Partners, or Customer Advocates about your 3-month Premium trial.

Who qualifies for the 90-day trial of Jira Cloud Premium?

Only customers on the Jira Cloud Standard edition who are projected to breach the limits in the new model on November 1, 2023. These customers will receive a notification with a link to their 3-month trial of Premium at the cost of Standard, providing 4 months total to monitor and adjust to the new limits as needed.

How will runs be counted, if a rule spans multiple projects or products?

Starting November 1, 2023, all Automation rules that successfully execute (both new rules and rules that you’ve already created) will automatically be assigned to a product. Here’s how this will work:

• Single project rules are billed to the product to which the project belongs.

• Project type rules are billed to the product to which the project type belongs.

• Multi-project rules are billed to the product with the highest limit* among products in the rule scope.

• Global rules are billed to the product with the highest limit* among the licensed products.

*The product with the highest limit is the one with the highest limit of rule runs.

Do these changes affect Confluence Automation?

Confluence Cloud is already on this model. We are making these changes to Jira Cloud Automation to make the experience consistent across our products.

Do these changes affect Jira Server and Jira Data Center?

These changes are only for Jira Cloud. The Automation for Jira app will remain unchanged for Jira Server and Jira Data Center. 

Have any other questions?

If you have any other questions not covered here, please Contact us. 

[Sami Ahmed Shaik]

@Kevin Bui 

Thanks for the detailed explanation of New A4J-Cloud model.

How come “Jira Work Management” premium has 100 per user limit whereas Standard has 1000 per user limit?

Does it mean Atlassian doesn’t want users to subscribe to premium?

[Srini Chakravarthy]

@Sami Ahmed Shaik 

Thank you for the question. Jira Work Management Standard edition has a flat limit of 1,000 runs per month. This does not change with the number of users on the edition. The Premium edition has a limit of 100 runs per user per month. This is a per-user limit, cumulative across all users on the edition. 

Please let us know if we can help with any further clarifications. 

[Rudy Holtkamp]

Could you explain the rational of reducing the numbers for standard licensed users?

Now there is an unlimited amount of project automation runs. Which will be 1700 for all projects combined. A 10 tier user site can run a similar amount as a 100, 250, or 1000 user tier site. Can extra automation runs be bought? Or is a move to the (twice as expensive) premium tier the only option?

Will a 'log action' also be counted as a run? If a condition is placed first we don't see why a rule has not run for a particular trigger. And sometimes it is because of a bug at Atlassian side (e.g. two automation rules that trigger on the same asset object change, one will be ok, the other will fail).

[Sami Ahmed Shaik]

@Srini Chakravarthy 

Thanks for the clarification. However, for JWM premium we feel 100 per user is still a very small limit, it should have at least 500 per user same line JSM.

[Mauricio Heberle]

These changes seem bad at first. What about Automation For Jira user/bot? Does it count towards per user limit like any other user? Cause them i'd have to change rule actors for a bunch of automations that we use 

[Łukasz Przybyłowicz]

@Rudy Holtkamp am I seeing it wrong or the current limits for Standard plan is 500 runs, and it will be raised to 1700?

[Rudy Holtkamp]

The limit for global automation runs is now 500, but project automation runs ate unlimited. This change suggests to have 1700 runs in total. A BIG difference. 

[Łukasz Przybyłowicz]

Okay, I understand now, it`s not clear when looking at the table. I agree, it`s a lot less and I wonder if will it be possible to "buy" more automation runs (which already sounds ridiculous) but I guess not.

[Bill Sheboy]

Hi @Kevin Bui 

Thanks for this valuable information!  I have a suggestion and some questions about this change....

Would you please consider updating the table shown in your post as many will find it misleading?  Currently, the limits you are showing for "Previous monthly limits" for Free and Standard licenses only applied to Global / Multi-project Scope rules.  They did not apply to project-scope rules.  The change described is all rules, regardless of scope, contribute toward limits.  The table seems to imply limits are increasing when they are actually significantly reduced for users below Premium licensing.

Also, has the automation team considered how this will dis-incentivize usage of automation rules for Free and Standard license users?  Why wouldn't a user-based account limit also make sense for Standard licenses?

What changes are planned for the Performance Insights?  Will they be modified to show both "billable" and "non-billable" rule executions on the report tracking, as selectable options?  Will this reporting be extended to longer time periods, allowing customers to analyze usage over time, and thus help make decisions about tool licensing?

Kind regards,
Bill

[František Špaček _MoroSystems_]

Hi @Kevin Bui,

thanks for the heads up. Some changes are welcomed and some seems slightly worse from our point of view.

I am not sure whether using a single limit for single and multiproject automations is a good idea simply because every project administrator can create own automations in his project. Currently there is not much he can damage with wrong automation because there is no limit on single project automations and project admin can't create multiproject ones (so worst that will happen is that he will mess up data in his project somehow). But from 1st of November we will have to carefully watch what new automations each project admin adds and check basically everyday if they did not add some stupid automation that will eat up limit for whole instance for the rest of the month.

Are there any plans to add more control mechanisms for system admins in this area? E.g.:

1. Enable/disable automations as a whole for each project and be able to set default state (for example set all new projects to have automations disabled by default and only enable them on demand for trained project admins).
2. Notification when project admin set up a new project automation.
3. Apply custom limits to single project automations - something like allow only 10 runs per day per automation and if person needs more he need to contact system admins to raise the limit. This one is probably not the best but you get my idea.

I am not afraid that much for JSM Standard (mainly because there are usually just few JSM projects with strict rules), but both JSW and JWM seems quite low to me if we are not given any way to control what people do in their projects. Not to mention complete freedom Team Managed projects have. This can be quite a big deal for medium sized instances (let's say 100 or 200 users+) and that can mean we will have to go back in time to only use company managed projects with NO project administrators and go back to do all the configurations and accesses via system administrators only.

Thank you.

[KC Wong]

What count as a success besides modifying issue?

Would create variable count? What about sending a web request?

What if my automation rule sends web request, then creates a variable in an if block, then only modifies issue if the variable is a certain value?

[Rowell]

Will Legacy Automation count?

[Kevin Bui]

@Rudy Holtkamp - Hi Rudy! We won’t be providing any options for purchasing extra automation runs. I can, however, confirm that the following actions won’t count towards your usage: 

• Log action
• Create lookup table
• Create variable

I’ve updated the FAQ section with this information.

@Mauricio Heberle - Hi Mauricio! Your usage will be the same, regardless of who the rule actor is. What matters is whether or not the rule performs a successful action. The "per user" limits are an indication of how many rule runs are available to you in total. For example, if you have 15 users on Jira Software Premium, this means your entire instance of Jira Software would have 15,000 rule runs available (15 x 1000).

@Bill Sheboy - Hi Bill! Thank you for the feedback - I’ve updated the table as you suggested, to indicate that the previous limits were for multi-project/global rules only.

As for your other questions - yes, the Usage tab in Automation will be updated, to show a breakdown of usage per-product (you can see a screenshot of this in the article). This is the first iteration of the new Usage tab experience, and in future iterations, our goal is to provide ways to track your usage over time.

@František Špaček _MoroSystems_ - Thank you for the feedback - I’ll forward your ideas to our dev teams for consideration. In the meantime, you can either:

• prevent all project admins from creating automation rules, or
• give the ability to create project rules to only specific people

Check out our documentation for steps on how to do this: Permissions required for Jira Cloud automation rules.

Hi @KC Wong! Send web request will count towards your usage. However, the Log action, Create lookup table, and Create variable actions won’t count. I’ve updated the FAQ section with this information.

Hi @Rowell Legacy automation in Jira Service Management is a completely separate feature, which isn't included in these packaging changes.

[Rudy Holtkamp]

Hi @Kevin Bui ,

Thanks for your reply. Could I suggest to either put these into a separate category (or give them another color) and make the out put of a run which only does a log/lookup table/var action a 'NO ACTIONS PERFORMED' status indicator instead of SUCCESS?

[Alex Koxaras _Relational_]

@Kevin Bui I think that you should expand on Confluence the same model currently valid on Jira. This change you propose shouldn't take place. Users and admins know that they currently have this awesome feature of "infinite" single project runs, and they are accustomed to it. Now, since you are taking this away from them, it's like taking away their "fix". This is totally wrong in so many ways.

[Cael Metcalfe]

"In today’s model, an automation rule that is configured to run in a single Jira project does not count toward the usage limit. In the new model, all automation rule types (i.e. single project, project type, multi-project, and global rules) will count towards the usage limit.

As we expand automation to Atlassian products beyond Jira, these changes enable a simpler and more consistent usage attribution model for automation - allowing customers to use automation more efficiently for cross-product and cross-team collaboration."

I fail to see how enforcing limits where limits did not exist, thus forcing customers to revisit their automations and potentially re-engineer or perhaps even abandone certain rules, enables any customer to use automation more efficiently, rather passes the buck of execution processing optimisation from the vendor to the customer.

This is technical debt added to Jira admins, with ongoing maintenance required for project automation or rather behavioural changes or ultimately revoking the ability for project admins to manage their own automations.

[KC Wong]

@Alex Koxaras _Relational_

Especially when you haven't bought ScriptRunner. The capability of the default workflow post-functions are so severely lacking, you have no chance to implement the logic required without using automation. 

And now you have a cap on how many automation rules you can run even for a single project. 

[Petr A]

This is very sad news if the description of the updates is true.

Previously, with a standard license for all products, we were able to create 1500 global rules, for example, copying a comment from project to project, moving an issue from JSM to Software, changing statuses between projects. This was more than enough.

In each project we have webhooks, notifications, field checks, integrations, which has been working successfully for several years, allowing all participants not to waste time on manual actions.

And now, if you say that you are removing the possibility of unlimited automation launches for single projects, it seems crazy.

7700 (5000+1000+1700) runs of rules with all standard licenses, having a small company of 200 employees with 5000 requests per month is no longer enough for even one run of automation for each request, not to mention real automations, notifications, adding users, etc.

Did I understand your changes correctly, you are removing unlimited runs for single projects - are you sure?

What is the reason for this change?

I am sure that the majority of Automation users will not appreciate these changes, since this literally reduces all automation to zero.

[Jarosław Kaczmarek]

Hi
I'll be blunt. The 100-odd automation, set on the project level, that we have is set to offset any shortcomings or lack of features of JSM. 

By including single project automation into the limit you are genuinely taking off our hands tools that made the whole thing going. 

Your move is also forcing us to invest in additional resources and custom scripting just to retain the current automation.

And no, we don't have the resources to go with the "Enterprise" level sub.

[Matthias Gaiser _K15t_]

@Kevin Bui - it would be great if you can also update your documentation with the planned pricing changes so that users are aware of it.

[Guido Menardi]

"Only rules that perform a successful action will count towards the limit"

Will this change affect in any way to the "Daily processing time" (3600s/12h) ?

[Fran]

@Kevin Bui  and the rest of the Atlassian team

To add my voice to the many extremely disgruntled voices above.

This is a disgraceful move from Atlassian to start counting single project automations towards the usage. It feels to me like a cheap bait and switch and is a serious breach of trust.

We use single project automations extensively and invested a lot of time into creating and maintaining them. Often to plug holes and provide facilities that should have been available in the base product.

I mean, what next? Maybe soon I can only view tickets X number of times before being charged (on top of our existing subscription)

This is an incredibly disappointing move, Atlassian. 

[Robert Condon]

Can you let me know if these changes affect the daily processing time limits as outlined here - Automation service limits | Cloud automation Cloud | Atlassian Support

It seems to me the solution here is going to be batching as many rules as possible to run on a schedule instead of immediately, therefore covering multiple issues in a single running

[KC Wong]

We will need way more than a Preview button. Automation rules breaking will wreck havoc with issue data. We must be informed by the system via email and alert well before the limit is reached. 

Also, where can I find the prices for extra executions? 

[Artur Balyan _ Immedis]

These explanations are written very well. However, I fear that it will force us to upgrade as working with a lot of automation rules makes sense when working with Jira for us, as it is missing so much in order to make it usable. We had to pay additionally for Big Picture just to keep track of people's days off and bank holidays reflected on deliveries, and to see gantt estimations of when work is complete and now this.