Introducing our new packaging model for Jira Cloud Automation

[Facundo Castillo]

This is so wrong...

[Syed Fazeem]

So , Single Project Rules are no more Free ?.

[Patrick Chen]

This is a deeply dishonest move. Completely inverting the way Automation is used by your customers in a brazen move to force us to move to Premium. 

[Dörken Administrator]

At this point I would like to join the choir of negative comments.

I think everything is said in the previous comments and we just can hope that @Kevin Bui and @Srini Chakravarthy take this serious and will give us a proper answer soon. The previous answers were just pre made text blocks and not a real answer to all the comments below this announcement.

I would like to point out that this will force a lot of people to premium subscription in a timeframe of 45 DAYS, because they have no other choice. In my case this is a cost increase of 70% in such a short time period. Its just ridiculous.

[Yaron Azar]

@Srini Chakravarthy 

Our site is under premium subscription and the annual renewal date is around Jan 2024, when will the change impact our site?

[Sean Brewington]

... 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.

Imposing a hard limit and removing pooled usage does not make things simpler or more efficient for customers.  This only adds additional usage to monitor and work we must do, as well as being a disincentive for using automation.

If people are abusing unlimited automation's, or the servers can't handle it, why not improve or enforce the automation time/rate-limiting rules you already have? https://support.atlassian.com/cloud-automation/docs/automation-service-limits/ .  Fine tuning those time/rate-limiting rules, or tying those limits to users/tiers would be more understandable and much easier to stomach than a hard limit with ~45 days notice.

We are already on premium tier, so do not get the extra ~3 months increased usage boost for evaluation and optimization.  We are about to roll-out a new workflow, and are now potentially over limits.  Having to pay for additional users, that will be unused, just to get a higher automation limit feels really weird.  Having an option of paying for # rules run > limit, or directly for higher automation limit, would be better than paying an annual cost for additional unused user licenses.

Edit: Rate-limiting is also how the Jira Rest API and Jira app's wok.  This IMO is a better practice for limits in general and would be more consistent.

[Marc Turner]

To keep (JSD especially) a viable product you need automation rules, so premium will be the only route, which is over double the price of standard.

From Atlassian's point of view this is a win for them. If this announcement means they loose half of their customers, the remaining customers are paying 2x what they were before.

So same/more revenue, half the customer base, half of the support queries, half of the infrastructure etc etc.

[Alain Kovacs]

This is a REALLY REALLY BAD MOVE Atlassian. We are a ~50 people company, which will see a few hundred tickets per month, and just having a handful of automations for each ticket, will easily hit the limit and break the whole integration! Basically anybody that needs automation and uses the automations reasonably, will need to move to the enterprise plan, as otherwise you will easily hit the limit which will totally stop your automations from running, throwing all that data into the bin basically. VERY SAD! We have not so long ago moved to JIRA and I was a big advocate for it, I really pushed it a lot, I still trusted you, that you can do something good, and now you come with this crap. We are seriously considering alternatives, and so should other people because you keep taking stupid decisions like these driving your loyal customers away. Shame on you!

[Steffen Helfenberger]

It makes no sense, to have a fixed limit per instance for standard no matter what number of users, since you pay per user!

It is a greedy move to force a lot of companies to premium. Most features in premium are not helpful for smaller companies like us (60 Jira users) and therefore we don't want to pay double just for a few automations.

You are really destroying your brand with such moves....

[Laura Savičienė]

Someone has already asked this question, and I can't find it answered anywhere - how will the scheduled JQL rules be counted if they make changes on several issues, is it counted as one successful execution, or as many executions as issues changed?

[שגיא גואטה]

Dear community,

Please enter the next link and discuss about the situation, and see what may be a good solution to the new headache from Atlassian:

https://community.atlassian.com/t5/Jira-discussions/Automation-for-Jira-OUT-what-s-next/m-p/2483968#M21118?utm_source=dm&utm_medium=unpaid-social&utm_campaign=P:online*O:community*I:social_share*

[Clément Faure]

@שגיא גואטה : Even if I understand your thinking process, I do not think this is yet the way to go. This will just mean work for us admin to stay in the same process as we used to be.

Hours of work, for no productivity at all. I think the community should focus first on making atlassian hear, rather than finding a way to keep work as it used to be.

The funny part is that automation was already the community's way of bypassing the product's kind of native flaws.

[Alena Fricova]

Hi, could you specify: if some automation rule have trigger in JSW project and action in JSM project (or the opposite) does it still mean that in both cases the rule counts toward the product with the highest limit? Or does it matter in which product is trigger and in which the action is?

Thank you

[Michael Eckert]

This is a very bad move with a very short notice period. Many companies are deep down the path of using automation and this will likely force them to unnecessarily upgrade or reconsider other options to support their current and future processes. I hope Atlassian reconsiders this policy change as I firmly believe it will adversely affect many customers.

[KC Wong]

[sheeraz Nawaz]

Hi,
I am writing to express my deep concern and disappointment regarding Atlassian's recent decision to change the working rules of JIRA Service Management (JSM), particularly the decision to set the limitations for JSM automations. As a long-time customer and advocate of Atlassian products, I believe this decision will have a significant and negative impact on the overall customer experience and the value we derive from JSM.

Automation rules have been an integral part of JIRA Service Management, providing users with a powerful and efficient way to streamline their workflows, reduce manual tasks, and enhance productivity. Many organizations, including ours, have completely rely on these automation rules to automate repetitive processes.

The decision to limit JSM automations is, in my opinion, unjustified and detrimental to the community of Atlassian customer. It effectively puts essential features that were once accessible to all users behind a paywall, which goes against the principles of openness and inclusivity that Atlassian has been known for. This sudden change in policy not only disrupts our existing processes but also puts an added financial burden on organizations already invested in Atlassian's products.

Moreover, this decision will disproportionately affect small businesses and non-profit organizations that may not have the financial resources to absorb these new costs. By moving towards expensive tiers that have this functionality, It may force them to reevaluate their choice of tools and consider alternatives that offer similar functionality without the added expense.

I strongly urge Atlassian to reconsider this decision and maintain access to JSM automations as a core feature for all customers, as it has been in the past. This move would demonstrate a commitment to supporting your user base and preserving the principles of fairness and accessibility that have made Atlassian products popular.

I believe that open and constructive dialogue between Atlassian and its customers community is essential to finding a solution that benefits everyone.

Thank you for your attention to this matter, and I hope that Atlassian will take into consideration the concerns of its user community.

[Zsolt Juhasz]

It seems Atlassian team has left the scene. Why am I not surprised?

[Steven Rhodes]

@Kevin Bui The article really needs editing to highlight the fact that single project automations for Jira Standard will no longer be unlimited and that they have until 31st October to make adjustments to all their automations or run out of executions. Its very unclear and seems purposely obfuscated and confusing. Firstly, the table is a screenshot making it impossible to search/copy the text, and refers to "These limits were only for multi-project and global rules -- single project project rules didn't count towards usage" in small lettering, in the past tense, not what is going to be imposed on the users. 

This is all regardless of the changes you are proposing to make.

[Brandon Fish]

So I got this from my Atlassian rep in response to my complaint.  Tell us again how this is just a move to "simplify" and not a money-grab

It's important to note that we've historically under-monetized automation while still investing in making our automation more flexible and powerful for customers. Customers like yourselves have been getting a high value capability for a below market price point for quite some time.

My response was (among other things): You say "under-monetized", but us customers say that Atlassian has "under-delivered" with product features that should be standard and ARE standard with some of your competitors.  We have had to cobble together automations to work-around your shortcomings.  We will not see eye-to-eye on this.

[Jack Brickey]

yuck...just...yuck

WARNING: Soap Box so stop here if desired. ;-)

I feel this is a poor decision that needs to be reconsidered. While there are a few positives here, for the most part those are window dressing covering up the bad news.

The only beneficiaries here are Atlassian and potentially some Atlassian partners. Partners selling competing (?) automation/scripting solutions, e.g the likes of Adaptivist Scriptrunner and Appfire's JSU Automation Suite or Powerscripts should benefit as the changes make their offering more attractive.

@Kevin Bui , some things to add to the "Things you can do..." section...

• For your JSM projects consider using Legacy automation when possible.
• For your CMP projects consider once again leveraging workflow post functions where possible.

[Marc Turner]

Are Atlassian aware of quite how many automations are there to make their product do what it should. i.e i bet we all have the automation there to re-open an issue that a customer comments on.

And how many resolutions to support cases have been to create an automation rule to work around a product limitation?

Mine seem to be either "create this automation rule"  or "vote for this request that's been outstanding in gathering interest since 2005"

You are already monitizing automation Atlassian, without it you couldn't monitize the jira service desk platform itself as it simply doesn't work without automations 

[Lara Jones]

@Brandon Fish 

It's important to note that we've historically under-monetized automation while still investing in making our automation more flexible and powerful for customers

I'm amazed an Atlassian rep was so clueless as to actually use the words "under-monetized" in a communication with you.  

Are all features supposed to be a la carte now?  Are they going to start ripping out core features in Jira and start announcing that they were "under monetized" and that we have to start paying for Jira to simply work because they were under monetized? 

Oh you want to customize workflows?  Sorry that's a premium feature.  Oh you want to actually be able to transition issues? Sorry we under monetized that, you're going to have to pay per transition. 

Yes Jira, let's introduce micro transactions to software management products.

That's a joke by the way.  I'm joking. 

[Patrick Chen]

Today's Jira Recap cheerfully suggests that we attend an open Q&A with the Automation product team to "Supercharge" Automation, the feature they are now effectively gating behind Premium. 

https://community.atlassian.com/t5/DevOps-articles/Live-Q-amp-A-event-Supercharge-Automation-with-DevOps/ba-p/2474324

[Haddon Fisher]

Hey Atlassian, are y'all going to respond to any of this in a meaningful way? There's a lot of very valid feedback here about how big of an impact this change is going to have on a lot of your paying customers and you seem to be trotting out answers out of the "Spin 101" textbook.

Speaking for myself, a once (and, hopefully, future) Atlassian fanboy who has been administering Atlassian products for over 15 years, I feel pretty confident saying that the enshittification of your products is really heating up:

• Jira used to be...well...just Jira. No sales, no BS, just "pay us based on these user buckets". Now you've split that into vertical 'tiers' and horizontal 'products', segmenting functionality in ways that feel kind of arbitrary and designed solely to extract the maximum amount of money from us.
• The move from Server to Cloud has been a constant low-level rolling disappointment. Y'all had 10+ years to make your SaaS offering even mostly on-par with Server, but as of today (2.5 years after you stopped selling Server licences), Cloud is, if anything, more of a mess. It's missing features that were fixed or mitigated on Server years ago and so much of the new functionality that's being delivered is completely untethered to what people actually want or need but have to accept because SaaS.
• On Server, when confronted by one of the nearly limitless issues with the application, we could reliably find an add-on which solved the problem. Hell, in a worst-case scenario, we could even roll our own add-on. I understand that the challenges of a multi-tenant application add a lot of complexity to the problem of add-ons, but.....uh....traditionally people figure out how they're going to mitigate a known problem before they create that problem. Sometimes, they even do some work before also.

And now this change, which breaks the conventional wisdom and best practices around Automation you yourselves established when you added this into your product.

TL;DR:

You've made a bad choice, which you are messaging and executing poorly. Again.

I would ask that you take a gander at the recent "Unity" and "Wizards of the Coast OGL" case-studies and re-evaluate your decision.

[Brandon Fish]

Thanks @Patrick Chen for the link.  I'm definitely joining one of those sessions now.  I have some questions.