Introducing our new packaging model for Jira Cloud Automation

[Erin Trahan]

So just to reiterate...

• Atlassian released a "new packaging plan" for automations that is nearly universally hated. (Without adding any improvements to Jira, mind you.)
• Atlassian goes radio silent to all criticism for almost two weeks (I assume to do damage control and meet with PR).
• Atlassian releases this new "tool" that only shows ONE MONTH of data so Admins can't properly gage their usage (less than 30 days before the changes go live).
• Admins get emails saying "you haven't gone over the limit! the new changes won't effect you." even though this is not true whatsoever, for many users.
• Atlassian posts another article happily announcing the changes (no comments section on this one; you all learned your lesson, I see).
• Atlassian refuses to back peddle on their "less than 5% of users will be blahblahblah" even though they are seeing evidence to the contrary.
• Atlassian sends in their team to shell out pre-approved, cookie-cutter, AI-generated responses that are wholly unhelpful and infuriatingly cheerful while ignoring the very valid criticism.

Conclusion

Atlassian will not be going back on this decision or even acknowledge they miscalculated until this hurts their bottom line. They also seem to think their users are unintelligent and incapable of sniffing out nonsense.

I am not sure which option is worse: that a decades-old company worth billions would do so little research and remain willfully ignorant or that they're so apathetic and greedy that they don't care about the backlash. Maybe a mix of both.

Slow clap for Atlassian. I really thought ActiBlizzard or Unity would take the cake as "Worst Company Decisions that Destroy Your Reputation" of 2023, but Atlassian really came in at the 11th hour. Bravo. 👏👏👏

[Anthony Guevarra]

This rollout failed for so many reasons, and the team behind the decision and the rollout need to be reassigned. At the very least, Atlassian failed its customer base by:

1. Setting artificially low limits for Standard users.
2. Setting a hard limit for Standard users and a scaling limit for Premium users. (1700 total vs 1000 per user)
3. Only providing a month for admins to plan.
4. Increasing licensing rates in the same relative timeframe.

Let's face it. This is a money grab masking as automation improvements. How points 1-3 above improve any company's experience is beyond me. Or maybe I'm missing something here.

[Andrew Morse]

@Marc Turner Thank you for your feedback! The analysis was based on current customer automation usage and included the rule runs that will actually count in the new model. The table below will show what rules count in today's model vs the new one being enforced on November 1, 2023.

In the current 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 whether the action is successful, counts towards your limit.	Only rules that result in a successful action will count towards your limit.
• Project-type, multi-project, or global rules 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.	• Single-project, project type, multi-project, or global rules will count towards your limit. • Actions (log action, create lookup table, create variable) don’t count towards your limit.

 As stated in the above table, only rules that result in a successful action will count towards your limit in the new model starting in November. Today any rule that is triggered counts towards your limit which is maybe why "re fetch issue data" regardless of successful execution, is counting.

[Marc Turner]

@Andrew Morse thanks for your reply. 

"The analysis was based on current customer automation usage and included the rule runs that will actually count in the new model."  Well you emailed me saying I'm within the limits, but your tool says I did 30,000 automations in September.  So how confident are you that this analysis is correct? 

Regarding the re fetch issue data - this is needed to properly evaluate some rules before taking action. so what you are saying, is even though I have rules that take no action, these will still count just because i re fetched the issue data? this seems unfair and not in line with what your announcement said.  You said only rules that have a successful action - my example does not result in a successful action, however its getting counted.

[Bill Sheboy]

Hi @Andrew Morse 

Thanks for helping answer the community questions about these changes.  Based on your response that the Re-fetch Issue Action counts for the limits, I have a couple of suggestions:

#1 Please update the automation documentation to indicate which actions count toward the limits.  This could be similar to the other information noted for each action, such as "Use smart values here: Yes / No".  https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/

#2 As customers change automation rules over time, tracking which rules counted toward the limits may become unclear, even for the same rule.  Please investigate changes to the rule Audit Log to clearly show for each execution when it counted toward the limit.  This could be a new column in the log, or a simple indicator near the status, etc.

Kind regards,
Bill

[Haddon Fisher]

Charlie Gavey you said "we'd love to hear any suggestions for how we could improve permissions, to give admins more confidence managing Automation usage."

As I see it, the problem being created by adding single-project executions to the global limit is:

1. As organizations grow larger, it becomes increasingly impossible for Jira Administrators to own Automation business logic for every project. The recommended solution to this problem has always been (as far as I know) to delegate this to project administrators, since they do have local awareness.
2. In general, these project admins are not Automation professionals, nor do they have any real vested interest in designing rules with a minimalist design consideration. I would further assert that it is infeasible to attempt to convert them into Automation professionals, both because it would require a big time investment and because it's not really their responsibility to be.

This results in a reality where either:

• Jira administrators need to take back ownership of the entirety of Automation within their instance. This dramatically increases the size and scope of their job without any compensating feature gain, and indeed will likely create a lot of ill will from the people losing the ability to create and maintain their own business logic without going through a help desk.
• Jira administrators need to be extremely diligent in monitoring Automation rules written by non-admins as well as their usage to ensure that a poorly written rule or set of rules doesn't inadvertently blow out their allocation for the month. Failure to do so will result in NO ONE's logic running, which will likely have incredibly painful consequences for anyone attempting to use Automation for anything like critical business processes.

The obvious and easiest solution would be to go back to not counting these against the utilization limits. Given Atlassian's current and past history of doubling-down on bad choices, this seems unlikely, but I feel compelled to mention it since it's the safest and best way to solve this problem.

With that assumption made, you could instead:

• Implement configurable per-project usage limits. This idea has all sorts of other not-great implications (mainly that its more about risk mitigation than actually making anything better while also forcing admins to potentially pay favorites), but it at least lets admins sleep at night knowing that a bad rule run on the first of the month isn't going to shut them down.
• Add a rule priority system. This has all of the complications introduced above but with even more of a configuration headache, but by telling Automation which rules are more important than others, we could at least ensure the most critical rules are in the least amount of danger. I think this would have to be very configurable, and allow admins to assign blocks of executions to different tiers.
• Create a class of rules which are executed more slowly but do not count towards the usage limit. There are some use-cases which call for rules which run regularly, but don't need to executed quickly. For example, take a rule which generates email to new hires a week after their hire date; it might fire at 9am, but no one is going to care if the emails don't go out until 9:30. This assumes that the root cause of this change is processing costs though, which doesn't feel like the driving force behind this.
• Customizable Utilization Notifications - I like to the think the best of people no matter how many times they've hurt me, so I didn't originally add this because I made an assumption that you're working on this table-stakes feature and will have it ready in time for when the new limits go into effect. Thinking about it further, it seemed prudent to mention it now and maybe not get my expectations up.

None of these are totally fleshed out, so I am sure there are use-cases and situations where these would be not-great, or even terrible. As I said above, the best solution to this would be not to create the problem for yourselves in the first place.

[Jack Brickey]

@Andrew Morse , thanks for staying engaged here. As @Marc Turner pointed out maybe there is some confusion on the Refetch data action. Your post seemed unclear on this action, however, I have to believe that this action will not count towards the limit. It, in-and-of-itself, does not result in an automation success. Could you please clarify?

[Paul Krueger]

Here's an example of a high-use automation rule specifically built to address a product limitation.

https://confluence.atlassian.com/jirakb/jsm-opsgenie-set-the-request-type-for-jira-service-management-issues-when-issue-is-created-through-an-opsgenie-alert-1252327912.html

We use Opsgenie as our "emergency line" for all things tech support, so this rule is pretty important. 

[Jack Brickey]

@Paul Krueger , thanks for sharing. I think the right answer there is to address the open issue listed in JAC - OPSGENIE-138 Ability to set the request type when issue is created through an Opsgenie alert , but until such time that that's addressed you're stuck with a workaround. :-( 

I used Opsgenie and jsm with a previous employer. I like both products and was glad to see Atlassian invest in Opsgenie thru an acquisition but I think the integration is still a bit loose.

[Lara Jones]

@Andrew Morse  I moved our rules to multiple projects yesterday.  All our automation is stopped as of this afternoon because we breached our limits.  I thought this wasn't supposed to happen? 

I'm still being held to the 500 limit for standard.

Does the right hand know what the left hand is doing?  

[Bill Sheboy]

Hi @Lara Jones 

I believe the limit changes take effect on 1 November 2023, according to the first page of this article.  And so you may be hitting the current 500 executions for global/multi-project limit for a Standard License level (or one of the processing time thresholds).

Kind regards,
Bill

[Andrew Morse]

@Lara Jones What @Bill Sheboy said is correct. Please reach out to Atlassian support to have them look into this.

[Lara Jones]

@Bill Sheboy  @Andrew Morse 

I'm really confused now.  I was under the impression no limits would be enforced until Nov 1st.

[Srini Chakravarthy]

@Lara Jones Apologies for the confusion here. As @Bill Sheboy clarified, limits in the new model will be active from 1st November. We've launched the new usage page in preview mode (without limit enforcement) to help you understand how usage translates in the new model. 

The current model is still in effect, so you will continue to get unlimited single-project rule runs and limited global/multi-project rules as per edition until 1st November. 

Please reach out to support, and we'd be happy to help if you have any further questions. 

[Lara Jones]

@Srini Chakravarthy I actually asked about breaching the 500 limit this month while I was moving rules around and was told it would not be enforced. 

Do you want the screenshot because I have it. 

And it's easy to tell me to reach out to support. Harder to do so when support is locked behind a form and never gets back to me. 

[Srini Chakravarthy]

@Bill Sheboy Thank you for the suggestions. We'll update the documentation and evaluate how we can surface more information on the audit logs. 

[Bill Sheboy]

As an FYI @Srini Chakravarthy and @Andrew Morse 

One good reason not to count the Re-fetch Issue action for the new limits is...a work-around for a defect.

There are known race-track conditions in automation rules.  One such condition is the Issue Created trigger can fire so quickly that the data is not available at the time the rule starts.  This appears as the symptom that later rule conditions, actions, and branches fail to work as expected...because the issue fields are empty (or do not contain the intended values).  I checked again and I did not find this defect / symptom listed in the public-facing, automation backlog.

One work-around for this symptom is to always add the Re-fetch Issue action immediately after the Issue Created trigger.  This slows down the rule to reload the data, resulting in later components usually working as expected.

If this defect did not exist, a rule might otherwise perform no countable actions due to condition tests preventing further processing.  Indeed the root cause warrants fixing the race-track condition, yet it is unclear if the automation engine and event-driven nature of triggers would support that (from an external customer perspective).

Thanks!

[Michael Lawrence]

Extremely disappointing and frustrating move from Atlassian.

Jira misses some key features other tools have available out-of-the-box. It compensates for this by being able to bridge these gaps offering a high level of automation power. Now we need to pick and choose which product gaps are acceptable to run with as this change severely impacts high-level automation runs; such as being able to capture the last comment on tickets.

[John Marsh]

This is a great explanation. It seems to me that Atlassian customers (the 5%) are left with 2 choices: 1) pay up for Premium or 2) migrate. With the stance that it is not possible to buy more automation runs then 2) is starting to look like a good option. I can see parallel running of a new system whilst the Jira licenses run out as a very good way to proceed. I have seen a number of other great tools recently so this will prompt a project to look at the market for a best of breed tool from a company that doesn't try to milk their best customers for more money.

[Constantin Lotz]

Best is the Mail from Atlassian: Subject: "Coming soon: new monthly Automation limits"

saying that: 

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.

---

In reality we are at 10% on the 4th (with 3 countrywide holidays - so @Work day 1) of the month, lets count + 30 days = 300% how that will fit?

[The_Contractor]

I'm going to go out on a limb here @John Marsh (and others) their math of affecting 5% of users is wrong. I suspect that given they buried the warning on the Automation page AND not all admins have received the warning suggests many customers are not even aware. If they were, we'd have more than 12 pages of negative comments. (BTW, in the 11 instances (different customers) where I am an admin, I have not received the change email).

I'm not sure how it's wrong - most likely the way they have calculated the "Single-Project-only" automation rules. Their base templates for notifications and feature gaps that can only be bridged in Automation make me go out on this limb. 

There's no way that ticket-change-triggered rules can stay under their respective limits for a given license/instance. Especially if you are letting external customers use Service Management and alike. You either fork over a Brinks truck of money to get unlimited or you're forced to migrate your entire Customer Support system to a non-Atlassian system. 

@Atlassian, to spell it out, if you don't apply these changes to Single Project Automation, this 12 pages of gripes immediately gets quiet.

At a minimum, make the run limits very different for Single Project Automation.

[John Marsh]

@The_Contractor I suspect you are right. In September Atlassian say we used 4000 of the 1700 we were allowed. With 1000 user licenses that is only 4 automations per user per month. Doesn't seem very many really considering how we have integrated Jira into our working practices across the business.

[Jack Brickey]

@Bill Sheboy , regarding the race condition on the trigger my thoughts for dealing with this are to put in some "delay conditions" to eat up some time. Ugly but maybe it will work?

[Omer Meshar]

@Kevin Bui I would like to suggest that you add another point to "How do I optimize my rule runs?" - I am not sure that this is what you wanted to get from this change, but from the experience I have so far, this is one of the most beneficial changes I found.

So my suggestion to optimize rule runs is to migrate your simple, straight forward and elegant automation rules, like Issue created -> set a field to X, to a single, complex, non intuitive scheduled automation rule, that finds all recently created issues, and with a complex if/else logic, sets multiple fields with whatever is needed.

This of course takes much more time and compute efforts (from my experience, instead of 10 * 2-3 seconds, it takes about 100-200 seconds in total, so about 5-10 more compute time for Atlassian), but it is counted as a single automation run and thus is much more optimized now.

Is that what you wanted us to do? Is this what you were aiming for with this change?

[l.seplecan]

@The_Contractor & @John Marsh - This "Big CHANGE" they announced to be rolled out is full of uncertainties and gaps. I even raised a ticket to their support and a guy from there, as the idiom says, keeps taking me to the sugar bowl - continues to repeat that this new release will not affect us, only this stupid number of 5%. and it is to our benefit... bla bla bla. This is not support, it's a mockery. If I requested to contact a direct representative of Atlassian, I was put on Hold. In other words, after this, I escalated the ticket and no other guy from the support in the highest position contacted me as you should when you call a ticket but still the same guy, with the same approach. 

As John suggested maybe it's time for a change. If the reason (those 5% are the clients who pay the biggest bills to Atlassian + certainly we will be affected by this change) then it's time for a change).

PS: They don't give a s...t about what we discuss here or what is the position of the community members.

So, for Atlassian - please be a good and intelligent farmer - cows can go crazy and they don't want to be milked more than they should.