Introducing our new packaging model for Jira Cloud Automation

[Lara Jones]

@Kevin Bui you need to finally update the granularity of administrator/developer etc permissions for Jira if you put this in place.  This has been an ask that Atlassian has ignored for a long time. 

Site/org administrators need the ability to prevent some admins from creating and running their own automation without site/org admin permissions or the entire site is going to wind up throttled and crucial automation will not run when needed.  I don't need an admin in project ABC writing a bunch of automation and running it on their own. 

[Cody Hoyt]

This is dishonest and your motto of DFTC clearly is in the rearview mirror as you speed down the highway to greedy corporate profits while running over your userbase. Good job... 

[dmitry_gil]

Are team managed projects will be counted towards limits? We have dozens of team-managed projects where each team configures own automations for their projects. Now you are forcing to prohibit diversity and move to company-managed projects? How otherwise I can say to all my teams that they are not allowed to configure automations in THEIR projects.Jira admins don't have event tools to limit automations created by owners of team managed projects. One not very educated project manager can utilize all limits in few hours. Please give instructions how can Jira admin limit automations in team managed projects.

[Dan Crough]

I've been an Atlassian champion at multiple companies. We were just considering onboading a new Atlassian product. This change and perhaps as much the way in which it is being handled makes it hard to contemplate a long-term relationship with Atlassian. Anyone at Atlassian following what is happening with Unity? Never even bothered to consider it before, but I am starting to look at alternatives today. Disappointed!

[Brandon Fish]

I don't think there is anything that I can type here that isn't already covered, but I'm not going to stay silent.  This is an extremely underhanded tactic to pull the carpet out from under standard users.  You spent years encouraging us to use automations that we invested in and now rely on and are now going to set a hard limit.  I will have more users than allowed executions in my instance.  I did a quick spot check, I've had 23 successful executions in the last 30 minutes; we'll probably to hit our limit within the first 3 days of the month.

Quick thoughts:

• Clear cash-grab to push larger orgs like mine to premium
• Will put more pressure on Admins to manage/limit user-created automations (even if you spring for premium)
• Little to no warning

When I visited the Atlassian offices, I don't remember how many years ago, I remember seeing a "100-year plan" display.  This has to be one of the most short-sighted decisions I've ever come across.  This is going to make us rethink out entire task management portfolio strategy.

[Jawann Swislow]

@Kevin Bui The FAQs mention three actions that will not count towards usage. Does this mean "Re-fetch issue data" will count if it is the only action that runs? We use this somewhat liberally to prevent problems with stale issue data that we have observed in the past, so I certainly hope not.

[Srini Chakravarthy]

Hello All,

Thank you for the feedback and questions. We’re sharing our responses to some common questions and concerns we’ve seen in your comments. We hope these provide more context and clarification on the change.

1. Why are single-project rules counted in the new model?

Our vision is to expand automation beyond Jira across the Atlassian ecosystem to enable you to collaborate across teams and products. To do this, we need a simpler usage model where rules aren’t counted based on Jira-specific contexts such as project types.

To make this easier, we’ve simplified the process by counting ALL automation rule runs that perform successful actions. This will help you understand your automation usage more easily, as you no longer need to differentiate between rule types.

2. What is the difference between Standard and Premium limits?

The automation limit on a Standard edition is a constant number, independent of how many users you have. For example, Jira Software Standard will have 1,700 rule runs.

The number of rule runs for Premium plans scales with the number of users you have. For example, if you have 15 users in Jira Software Premium, you will have 15,000 rule runs (15 x 1000).

3. What actions don't count towards a rule run?

There are three actions that don't count towards a successful rule run: Log actions, Create variable, and Create lookup table. If your automation rule only performs these actions, it won’t count toward your usage limit.

4. How can admins manage the change?

Today, Global admins can restrict project admins from creating and editing automation rules. We’re also introducing easier ways to monitor Automation usage, including reporting on rules driving the most Automation usage across your instance. Global Admins will be able to monitor and enable/disable rules driving significant usage across their instance.

On October 1, 2023, we will roll out the new usage tab in Global Automation so you can manage your usage under the new packaging model. With the new Usage tab, you’ll be able to preview and optimize usage to be more proactive with your automation limits.

Here are some things you can do to optimize your rule usage:

• 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 maximize the value you get from 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.

5. Are we changing service limits in the new model?

The new packaging model is applicable only to usage limits, i.e., the number of automation rule runs per month. The model doesn't introduce any changes to Automation Service Limits, such as the daily processing limit.

[Lara Jones]

@Srini Chakravarthy  my Global Admin doesn't handle automation.  We don't give everyone "Global" administration rights for a reason.  Based on this answer, I'd need Global rights to cut off project admins from running automation? 

Why?  This is the complaint I have about better granularity with Jira admins.  Why are you rushing out pricing changes when your permissions for admins are still such a mess? Who makes it so only the Global admin can make changes for such low level admins? 

And frankly this explanation is not an explanation.  This provides me with no real reason why you're changing the pricing at all just corporate nonsense that tries to justify raising prices. 

[Thomas H_]

This will help you understand your automation usage more easily, as you no longer need to differentiate between rule types.

you @Srini Chakravarthy are absolutely right, this will indeed make it easier for us to understand our automation usage, as we will not be able to use it at all anymore for anything useful. thanks for making it sooo easy, it was my number one (and of course only one!) problem I had using Jira, and now that's solved too!

seriously, this was your takeaway reading through the comments here? 'I need to tell people again how great that change is for us them, they clearly did not get the message the first time!'. it is very clear Atlassian does not care for the non-premium/enterprise customers (anymore?) and the trouble this change causes for them at this point.

[Nick]

"This will help you understand your automation usage more easily, as you no longer need to differentiate between rule types."

Has any Automation user ever complained about finding it difficult to use their current automation? No one.

However, such a “useful” option has already created 5 pages of comments and negative reviews, think about it.

As a simplification, you could just add the ability to view the number of successful automation runs, close the question there, everyone would thank you, although we could do without this new functionality, since there are more important things in your backlog that are “gathering interest”.

But what simplifications are we talking about, what differences in the type of rules, if you simply cut the basic functionality of automation, and increasing tariffs? We pay for the cloud version so that the service runs on your resources, and we don’t have to worry about system performance. The server version is no longer available for purchase, which might be an alternative.

The alternative options are purchasing plugins, since there is no automation package provided, only switching to premium, which costs 2-3 times more, is a very strong move.

[Chris Rogers]

I'll add my voice to the disappointed chorus; I've been a huge proponent of Automation for different clients as I help configure and optimize their processes.  For the most part, Automation is very flexible, powerful, relatively easy to learn, and can help my clients reduce additional spend due to Automation being available out-of-the-box, but the limit changes don't make sense.

[Bridgitte Molyneux]

This is absolutely absurd and the timeline in which this change is being made is unacceptable. Francois Bousquet's comment many other commenters here have already spoken my thoughts. We have too many rules to reanalyze after trying to evaluate trends in the short window given. Many companies are cutting back heavily right now as we are heading into uncharted territory as far as the market goes. This is a total bait and switch!

[Darren Nicas]

This is not a welcomed change. We've spent countless hours on the setup of our automation based on the existing framework of no limit to single project automations. Now we will have to spend more resources to update our automation or just stop using it.

The new limits are not reasonable and force customers into premium plans for no reason other than more automation calls available. So even if I don't want anything of the premium plans I need to buy one to get more automation calls. Then if I want even more beyond the number of users I have, I can't buy more calls and instead need to add dead users to my account to increase my automation calls limit? Absurd.

If we are supposed to evaluate our usage in such a short period of time where even is my preview tab? How can I start the analysis to decide if I want to spend more money on automation when you don't even give the preview as in this article?

[Helen C]

I think I understand this but can I clarify if we reach our limit what will happen currently it says our rules will not fire if we exceed our limit is this staying the same or are you going to bill us?

[Johnson Ip]

Many of our automation rules were developed as a workaround to Jira Service Management's limitation. This change feels like Atlassian is charging us to fix their product limitation. If you want to get a sense of the product limitations, just go investigate those tickets that are "gathering interest" for years.

Furthermore, the hard execution based limits for standards licence looks unfair to large implementation. The limit indicates that Atlassian expect a 10 users site to generate the same number of tickets (automation execution) per month as a 1000 users site.

[sekhar reddy]

We are in JSM premium version with 50 users, as per the new change we will get only 50000 rules per month. We are running some scheduled 5 automation rules for every 5 min, that is to transition the issues based on the current date and time, These rules are cover 43200 rules in a month. 

We are using so many other automations rules also for our ITSM projects and these can be covered like 30k rules.

If we exceeds the limit it stop processing and we have to update the details manually except going for enterprise version which is 200 users.

There is no way to optimise the scheduled events, even with scripts also not possible because script runner will only support create issue actions not in the edit issues action because of there is no API for this from Jira end.

Atlassian is simply forcing users to move to Enterprise version to make profits.

[KC Wong]

@sekhar reddy 

I think our only way out now is to look at Forge plugins. 

Whatever the OOTB workflow post functions couldn't do, we did in automation.

Now whatever automation does, we put it back into workflow post functions using Forge plugin (beta workflow functions). 

That is, until that gets an execution limit too. 

[Vince Clark]

@Srini Chakravarthy Why is I feel like your response is straight out of a text book. You are in no way simplifying any process to make it easier to understand. We are not fools, but we are, I may remind you, your customers and your response quite frankly does not give me any confidence whatsoever and quite frankly it seems you have not read or maybe listened to the comments in detail as posted by your customers

[Vivien Sahr]

So, when a user creates a faulty rule that runs in a loop and completely drains the pool of all available executions, all automation will completely stop for all projects? Sounds like a really really bad idea... Do I really need to disable automation for my users and carefully craft the rules myself to make sure that no one accidentally prevents the whole automation from working?

[Zsolt Juhasz]

Hi,
How the Scheduled trigger type will be counted, if the JQL will result more Issues to change?
Will it be one or it will be the number of changed Issues?

[Fran]

@Srini Chakravarthy and CC @Kevin Bui 

Srini, you said:

Our vision is to expand automation beyond Jira across the Atlassian ecosystem to enable you to collaborate across teams and products. To do this, we need a simpler usage model where rules aren’t counted based on Jira-specific contexts such as project types.

To make this easier, we’ve simplified the process by counting ALL automation rule runs that perform successful actions. This will help you understand your automation usage more easily, as you no longer need to differentiate between rule types.

Your explanation why you are starting to charge for single project automations is not even understood, never mind not accepted. Literally nobody has asked for this. I'm sure it wouldn't take a huge amount of ingenuity to figure out a technical and pricing model that doesn't cripple your user base, yet moves towards this "vision", whatever it means in reality. But we all see through this corporate-speak to what it really is: a clumsy attempt to raise revenue.

You have not moved the "trust" needle back to where it should be even by the smallest iota. Stop doubling down on this. Trust takes years to build and just a moment to destroy. In NPS terms, you've turned me from a strong promoter to a strong detractor. I couldn't right now in conscience recommend any Atlassian product to anyone because of this complete breach of trust. Once bitten, twice shy.

To stand any chance of rectifying this, you need to immediately announce you're rolling back on this plan.

To put this in a bit more context: we, a several-hundred standard-user Jira and Confluence instance (so, not tiny) are coming up to annual renewal point in the next few months. Every year, we have to justify why we are paying tens of thousands when we could just all move to Azure Devops at basically zero additional cost to us. I benefit you by arguing for license renewal annually, and I suspect most of the people who have taken the time out of their day to protest about this change on this thread are in a similar stakeholder position to me. You've just crippled my (and our) ability to argue for renewal AND made me, an advocate for your products, lose trust in you.

Do the right thing.

[Lars Swart]

I would like to add my voice to most of the people in this comment section. We use a lot of automation in individual projects. This is necessary because most of them are highly streamlined business processes. We have just completed a migration from server to cloud. This was a tough argument against our manager. We sold him and moved everything to the cloud. And now this. Under the circumstances, I can no longer argue for our beloved Jira instance. I know that many other companies are also unable to pay for the upgrade to a business licence.

Please consider upgrading your idea to more realistic automation numbers.

[Ijaz Ahamed]

Explanation is written well but this ain't the right model when Jira Service Management does not seem to support basic required operations like other products. There are too much limitations, and the requirements are just under either Gathering or Closed stages. 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 am sure that the majority of Automation users will not appreciate these changes, since this literally reduces all automation to zero.

[Ijaz Ahamed]

Should have added this to the community to Gather Interest before thinking about implementing!

[Jason Plumhoff]

After receiving the notification about the changes to the automation rules, I'm in the process of backing out all our automations.  Some we'll just have to live without, others will have to be replaced with homegrown scripts to poll and modify Jira issues through the REST API.  I wish I could wait and analyze our actual usage to see if any of this extra work is necessary... but with only one month between announcement and implementation, there's no time.  I can't afford a service interruption if we exceed the limit, and I'm definitely not going to double our Jira spend for a collection of features we neither need nor want. 

This rushed, customer-hostile decision is a clear example of a company that is failing to live up to its purported values.  Please do better.