Introducing our new packaging model for Jira Cloud Automation

[Lara Jones]

@Andrew Morse  Can admins start switching project rules to global in October or will the breach of Jira Standard's 500 global limit still count? 

I'd like to start consolidating some rules and making changes to other rules but if the trial isn't available until Nov 1 and if I cannot move items to Global now, I'm still stuck regarding modifying automation rules until after November 1 and I can't do much to evaluate usage in October. 

[Majken Longlade]

@Andrew Morse your answer to @Enric Monteagudo is wrong, "lookup issues" is an action that does count in the new scheme.

[Brock Jolet]

I just got the email from Atlassian about the changes and it states that our team should be under the new limits and not require any changes, but this is contrary to the actual numbers. According to my math, we will be using twice the allotted executions in all of our Standard tier products.

How is Atlassian coming up with their numbers and why does the usage tool not corroborate their claims? If they are wrong about our team, how many other teams are they wrong about? Is it truly only 5% of customers that are affected?

[Lara Jones]

@Andrew Morse  I just got the admin email from Atlassian about the new automation limits and our email says we are "just under the limit" which I assume means we are not going to be offered the 3 month trial.

However the usage report for September indicated we were over our limits. 

*Added one more image.  I knew I had this (see the usage in red)

Your current Automation usage data indicates your team is staying under the new limits, and no changes to your Jira plan or usage are needed. If you are on an annual subscription, the new packaging model will only be enforced post your renewal quote creation date.

This isn't remotely true.  

If Atlassian doesn't know what's going on, how can you expect us to figure it out? 

[The_Contractor]

In response to @Brock Jolet recent post, I agree, something is not right. This is not passing the sniff test for me. Something is wrong either in the charges as written, Atlassian's research or alike. 

I happened to be in the Automation section of Jira when I got a notification about Brock's post. Brock's post inspired me to click the "templates" tab in my Automation instance. 

...Thinking about the "5% affected customers", the tiers of usage now affecting project-only automation, looking at the automation tab, something doesn't add up! 

Just look at the first 3 rows of "suggested" templates from Atlassian. Maybe I'm wrong, but all of these are super useful. Most cannot be done with non-Automatoin Jira tools alone (e.g., workflow post actions). But yet any customer instance with more than a couple projects, and a handful of tickets each, is going to be in breach of their respective tier (of course, unless you're a huge organization that has unlimited runs).

If these new pricing policies are enacted, I can't see a single one of these templates being of use. I'd need to start using external, 3rd party tools. 

I hope Atlassian surfaces soon to respond to some of these posts/questions. Their 3 or 4 from earlier today did nothing to address the real issues being expressed over these last 11 pages of comments.

[Andrew Morse]

@Majken Longlade @Enric Monteagudo My apologies! I got confirmation from my product team that you are correct. Lookup Issues will count in the new model. There are only three actions that don't count (log action, create lookup table, create variable). 

[Andrew Morse]

@Lara Jones You don't have to worry about breaching the current JSW standard 500 limit as it will not be enforced. Starting 11/1/2023, we will actually enforce the automation limits.

[Lara Jones]

@Andrew Morse  Thank you for the quick response!  Any idea why the evaluation of our usage is off? 

[Srini Chakravarthy]

@Lara Jones Our support team will be happy to help with the Premium trial, if you haven't received the email. 

[Andrew Morse]

@Brock Jolet The less than 5% claim was based on a calculation of customer automation usage counting their unlimited single project runs that were previously not counted. We can't guarantee if a customer will exceed the new limits or not but we did want to make recommendations based on current usage. If the data in the usage tab is showing a discrepancy, please reach out to our support team for help.

[Srini Chakravarthy]

@Lara Jones It is likely that your usage has changed since our assessment date. Apologies for the confusion. Please get in touch with the support team; we'd be happy to help with the Premium trial. 

[Paul Stallworth]

Wow.  Greedy, bullshit move from Atlassian.  But, this is exactly where most enterprise cloud services lead, especially in a company that isn't controlling its costs.  Headcount has been exploding uncontrollably the last few years so it's no wonder the squeeze is on.

Date	Employees	Change	Growth
Jun 30, 2023	10,726	1,913	21.71%
Jun 30, 2022	8,813	2,380	37.00%
Jun 30, 2021	6,433	1,526	31.10%
Jun 30, 2020	4,907	1,291	35.70%

[Sean Noble]

Just a PSA to any of you Atlassian customers on this thread that are also Okta customers (like we are):

We have begun investigating in Okta workflows as a replacement for Jira automations and so far, have been very pleased with the results. It’s not as elegant of a solution, but if I have to choose between feeding Atlassian’s already greedy monstrosity and leveraging a tool that, which also expensive, can be used to do a lot more things across many other tools, I choose the latter. 

[Johnson Ip]

I just had a look at the usage report and disappointingly, it only had 1 full month of automation data. Shouldn't Atlassian provide data for at least 3-5 data points so that some sort of trend can be established? If the Jira Admins operates in a data driven organisation, how can they justify to an organisation using 1 data point that they need to redirect resources to refactor the automation rules. Sure they can wait until they are pushed into a higher tier trail and use the grace period to gather more data points, but by that time, it will be too late to start the refactoring as the testing of the new automation rules will count towards the total so they will only have this month to complete the job while they are still on "unlimited" usage. The post says only 5% of customers are impacted, but how many customers are at the 80-90% mark where a sudden surge or a small growth will tip them over? If they are at 90% on September, is this due to a surge in tickets (automation rules being executed) or their long-term average execution is really sitting at this danger zone and they need to act now?

[Patrick Chen]

I got an email saying "Your current Automation usage data indicates your team is staying under the new limits, and no changes to your Jira plan or usage are needed."

Meanwhile, the usage tool shows that our September Jira Software (Standard) automation usage was 26,743. 

2 Days into October and we've already used 863 (49%) of our 1,700 Jira Software runs. 

Can someone explain this math?

[Srini Chakravarthy]

@Patrick Chen The emails were based on a calculation of usage, counting single project rules, and adjusting for successful runs in the new model. We did want to make recommendations based on this analysis, but we can't guarantee that a customer will exceed the new limits. If the data you see on the usage tab has discrepancies, please reach out to our support team. We'd be happy to help.

[Charlie Gavey]

@Nena Kruljac That's right, the new Automation Usage Tab will show you the rules which have successfully executed the most, and there will be in-product and email notificiations as usage approaches the monthly limits.

@Fazila Ashraf @Yaron AzarThat's correct, customers on annual subscriptions will not have the new limits enforced until their next renewal quote creation date.

@Raju Mandapaka We're not introducing any changes to Automation Service Limits (e.g. processing times) as part of this change. If you do have any feedback on our current service limits, please let us know.

@Alex Steinlauf  @dmitry_gil Thanks for flagging this. Global Admins can manage the rules directly via the Usage Tab dashboard (e.g. by editing or disabling rules that are running too frequently), and they can also manage permissions around who can create/manage automation rules (e.g. by only allowing Global Admins, rather than Project Admins, to access Automation). While we haven't made any changes to Automation permissions as part of this packaging work, we'd love to hear any suggestions for how we could improve permissions, to give admins more confidence managing Automation usage.

@Bridgitte Molyneux @Darren Nicas The new Automation Usage Tab has now been released, so you can preview your usage under the new packaging.

@Helen C That's right - if you reach your monthly limit, Automation rules will stop running, as they do today.

@Zsolt Juhasz @Laura Savičienė The scheduled trigger will count as a single rule execution each time the rule triggers.

@Haddon Fisher That's right, the Usage Tab reflects usage for the entire month to date.

[Yatish Madhav]

Quick one to confirm @Kevin Bui  - rule run counts are by rule in it's entirety and NOT by the number of actions successfully run in a rule, correct?

Thank you

[Nena Kruljac]

As @Patrick Chen , we also got an mail:

Your current Automation usage data indicates your team is staying under the new limits, and no changes to your Jira plan or usage are needed.

But we will soon exceed 5000 JSM executions for this month.

[Srini Chakravarthy]

@Yatish Madhav That's right. A rule can have multiple actions but is only counted once for every run with at least one successful action. 

[Marc Turner]

One observation and one question

Observation: I execute 20k+ automations each month, yet I got the email saying my usage is below limits. based on Atlassian saying it "only" impacts 5% of their customers, I wonder if this bizarre assumption was based on poor or incorrect data, and the number is infact much higher.

Question:  I've had a look at a few of my highest usage rules. one is counting against my usage, yet the issue doesn't match the condition so no action is taken. the rule in question has "re fetch issue data" in it. does this mean any rule with re fetch issue data, regardless of if it does anything or not is going to count as an execution? because re fetch is an action that succeeds?

[Dominik Březina]

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

What does Customer exactly mean? Is it single Jira instance? Or do you account even number of used licences per instance?

It is different if customer of 50 licences gets over the threshold than Customer with 500.

You can have 19 customers with 50 licences who are OK and one with 500 who goes over. Then suddenly you migh have one impacted customer (your 5%) BUT in fact it is 34,5% impacted licences and this is very different from your mentioned 5%.

What does your statement exactly means? Does it mean that neither one of those got over 5% threshold in their specific licence category or does it mean that sum of all Jira Cloud Free, Standard and Premium Edition customers doesn´t get over that limit. So which one of these cases is right:

Case 1

100 Free - max 5% instances breaches the threshold 

100 Standard - max 5% instances breaches the threshold

100 Premium - max 5% instances breaches the threshold

Case 2

100 Free - 0 instance breach the threshold

100 Standard - 15 instances breaches the threshold

100 Premium - 0 instance breach the threshold

300 in total and 5% breached the threshold all being standard which is 15% in this licence category.

[Hector Ojeda]

This change means that Atlassian is going against its own beliefs about productivity, collaboration, and high-quality work. Remember this blog post? https://www.atlassian.com/blog/announcements/atlassian-automation

Limiting the use of this tool only downgrades the experience and all the benefits Atlassian was promoting with fireworks. The fact that not even the enterprise suite limits of automation fulfill the actual use of the tool, means you didn't analyze this quite trough.

This kind of behavior and political changes make Atlassian unreliable, unpredictable, and frustrating since now instead of solving day-by-day problems, we have to deal with Atlassian as a problem, not the solution.

In other words, Atlassian with this change became the problem and not the solution.

We really expect that Atlassian will listen to the customers and change these policies.

[Szabó Dávid]

After 1 day, it is clear that 5,000 runs are very few. Automations in a standard package make no sense.

[Thomas H_]

the narrative should not be around the "only 5% impacted" but rather how automations are now severely limited for everyone's (*) future uses.

whereas until a few weeks most solutions around shortcomings of jira were "create an automation", this is just not the case anymore. any future automation use will from now on always involve a non-zero amount of fear of reaching a limit and with that jeopardize the project & business.

(*) every peasantstandard licensee