Introducing our new packaging model for Jira Cloud Automation

[Daniel Vargas Llopis]

Will the new report for automations include historical data over few months?

This would be extremely useful to evaluate the impact of the changes, as only current or previous month would not be enough, the limited 1 month window would not allow to properly review it if these are not available.

[Peter Fredebold]

I can understand the need to bill processing time / automation invocations.

The Issue here is that there is no way to get a higher limit without upgrading to a tier whose features you may not need or do not qualify for.

I would understand it if we were charged for executions above the limits, but blocking execution is, as many have mentioned, a blocking issue.

Please consider allowing us to purchase more executions/a higher limit independent of Product Tiers and many will go from "this is unacceptable" to "this is bad, but we can deal with it and understand the reasoning".

[Sam Hepworth]

Going from unlimited to 1700 or 500 single project executions is a huge reduction. Consider an option to purchase more executions, so that customers who have invested in and depends on automation are not screwed. 

Our decision to go for Jira Product Discovery and not Aha!, ProdPad, ProductBoard, etc. is based on the integration to Jira Software and the customization possibilities of JPD. Our customization of JPD depends on automation is unusable without it. Limiting automation will force us to switch to another product.

[Clément Faure]

After reading the comments, I just put mine here to backup all the unhappy ones. 

The speech that this will enhance clarity for the users is just unnacceptable.

Doing this, you are just removing from users what made us chose atlassian products in the first place, and take from us (additionnally adding debt) hours of work on automation.

I am single admin of a 100+ userbase. Automation is heavily used now. We will move from unlimited use, to ridiculously low rates, and no ways to upgrade them(I don't consider doubling the price a solution), along with costs increase.

Trust is broken, I don't see another solution than to move away from atlassian, we will, starting on 1st November, lose a lot of features anyway, along with a price increase.

[Jänsch_ Michael]

quite a bid sad now ... just checked and controlled last month, which automations we can set into project context ... and now this one ... 

at least we need no stop when the limit is reached, but maybe buy some extra runs .... sounds like EA Fifa style pay to win ... but well, we are forced to do that or change the application

[Nena Kruljac]

What does "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." exactly mean - Is this limit

1. per automation rule (but regarding product)?
2. or per all automation rules in products (JSM / JSW) - summary of executions of all automation rules in 1 product?

I suppose the 1st one, but it would be good to confirm it.

[Fran]

I have to say, I don't agree at all with some previous posts here that ask for a way to purchase extra "automation credits".

Atlassian are going to effectively take away functionality that came with the standard license fee, which we already paid for, and a lot of users invested heavily in using this feature over the years since its introduction in order to plug gaps in the base product.

We shouldn't be content with that behaviour, at all.

[Marc Turner]

I'm on standard and I execute 20k+ successful automations each month. I would say 70% of these are to work around limitations of Jira Service Desk, or to make it do stuff that you would expect it to do that it doesn't.

I have no requirement for any of the premium functionality, so it feels very unfair to force me into more than doubling my licence fee to be able to continue doing what i do today. And all this with 30 days notice.

This change coming in will break our service desk. Atlassian really need to step back and think again with this. I've already got Freshdesk and Zendesk demos booked in.

[Marcin Krasicki]

Really? There's even no such a basic function built in like changing the status of the ticket when a customer replays and needs to be handled with automation... the same when we are answering the ticket, that 2 automation runs per every comment on every ticket ... c'mon ...

Also .. if you start counting runs by project maybe you finally start charging us for app licenses only on products we actually using the app? Now we need to pay for x users from Jira just so considerably fewer users can use an app in JSM.. that's ridiculous...

[Peter Fredebold]

There's even no such a basic function built in like changing the status of the ticket when a customer replays and needs to be handled with automation... the same when we are answering the ticket, that 2 automation runs per every comment on every ticket

We have the exact same, I agree with this.

[Brandon Fish]

Hey look what popped up on our site today, is Atlassian going to start enforcing the storage limit now too?

There are ZERO tools supplied by Atlassian to manage storage in Jira.  You can't even search for issues by attachment, must less sort them by size.

This suggestion was submitted in 2005 and is "gathering interest" and "not on the roadmap"  https://jira.atlassian.com/browse/JRACLOUD-5700

[Clément Faure]

Looks like for any business already in Jira, it's basicly premium or out. Good strategy.

[Odie]

@Brandon Fish exactly this, it's the cherry on top of the bulldook pie! And making us wait an extra 10 days for the estimate calculator is also a bush-league move. All of this reeks of out-of-touch decision making.

Serious question: is Atlassian taking lessons from Unity in how to aggravate their customers? If so, you're doing a bang-up job. 

[Lara Jones]

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

I'm just going to point out how ridiculously condescending these "helpful hints are"

Who do you think your audience is here?  "Add conditions to your automation rules" or "disable rules"

The people providing you with feedback are pointing out that we have mission critical automation that runs as part of our workflow(s) and that automation is usually working in various large projects.  Some of this automation runs hundreds of times of day.  Some of these rules may carry out one operation and only look for a single trigger.  

We're using small and efficient automation rules. 

So making these kinds of comments is just insulting your audience/customers while continuing to twist the knife with the pricing changes.  

And to be honest, this kind of pricing sounds like it is encouraging larger, process intensive rules.

You're counting the #number of rules rather than the efficiency of rules over the load on the server which.. make it make sense Atlassian.  If someone executes several small efficient rules over fewer extremely inefficient rules, how does this pricing make sense?

[Darren Nicas]

Reviewing the latest comments raises many great points about Jira Service Management. The product is not usable out of the box in almost any organization. With automation it is actually useable. The feature request backlog of items to make it useable without having to throw hours of automation at it are "gathering interest". Why are there not improvements being made to the product to make it useable without automation? 

We already have a paid plan for the product and made it work for us. Now with 1 month of warning we have to revaluate the usage of the whole product. Maybe we decide to not pay for it anymore and get something that actually works out of the box. 

[Brandon Fish]

@Odie It's like someone has an OKR to "Increase premium adoption", they spit-balled all the ways they could push users to move and then someone said "Do them all!" without ever considering the affect on their customers.

Personally, I feel like creating Premium from the beginning was a mistake, at least from the customer's point of view.  Spending development time on new features that only a fraction of your users can use instead of adding features to your core product makes your core product less valuable when compared to competitors that do improve the core product.

In 5 years, after they have forced us all to move to premium or leave the platform entirely, they will introduce "Jira Platinum" and start adding new features there instead.

[Jim Bren]

@Kevin Bui , it might just be me, but I've found that when communicating to your user community about upcoming improvements to their service, it's generally best to lead with how you're not screwing them over. 

After reading this announcement on Monday I opened a ticket with Billing in order to get an estimate for upgrading to premium under the new model. It was through conversation with them that I received really important clarification: that executions with a status of no actions performed do not count toward the new monthly limit. 

Since Atlassian has chosen not to give us access to the count tool until next month, I looked at yesterday and did some back of the napkin math:
automation log entires for yesterday: ~1550

- automation log entries for yesterday: ~1550
- executions with status of success or some errors: ~56

If I assume that ~56 is an average number of successful daily executions and multiply that by 22 working days, we're well under the limit for standard and my sense of outrage diminishes considerably. 

Of course, I won't be able to fully validate that until the tool is available, but I'm no longer thinking that I need to use the 90 days of (maybe) free premium to figure out a plan to migrate away from Atlassian. 

[Kristján Geir Mathiesen]

Thank you for sharing, @Kevin Bui 

[Brock Jolet]

This update, in addition to the sudden notice of licensing increases, is very disheartening. Our team has hundreds of automations if not thousands across the full Jira suite and Confluence. The more we use Atlassian products, the more features we find lacking, and the more often I have to automate workarounds. Now it simply might not be financially viable to do this.

We've been able to get by by limiting our rules to single projects and being selective with global rules. Now that's not going to matter? We also benefited from having the premium limits across all project types, but now I have to worry about whether the rule is in a JWM, JSW, JSM, JPD, or other project.

We are heavy users of JPD and have rules that trigger every time a ticket is created or edited in order to provide missing functionality. With these changes, JPD becomes unusable. There isn't even a higher tier to upgrade to. We have had ~100 automations triggered in the last 24 hours in a single project.

All of these changes happening suddenly, with such a short window to assess them, is a criminal cash grab.

[Erin Trahan]

This is unacceptable.

Thesis Statement

What the hell, Atlassian?

JPD Complaints

Y'all are really screwing over JPD users. 💀💀💀

We rely heavily on JPD and automations within it... 500 max with NO WAY to increase it effectively destroys a project used by a majority of our company. We have JPD automations that run DAILY. Do y'all just not want people to use Discovery? Why even create and promote it and then brick the functionality? What is the logic?

General Gripes

Jira admins have to use automations to bypass limited, broken, and missing functionality... so y'all take away the ability to use those automations WITHOUT improving Jira in any substantial way? At the same time as a price increase?? With only A MONTH of notice???

Who was the absolute genius that made these decisions? Seriously, I cannot believe more than one person at Atlassian was foolish enough to think this was a good idea.

The icing on the 💩 cake is the peppy, "look how great this is!" tone in which this was delivered. This is terrible news with no substantial upside for 99% of your users.

Closing Statement

Make better choices. Don't do this.

[Marcos Milanesio]

Automation is a great solution that incredibly expands the possibilities of Jira Software. Making the decision to limit executions in a single project really becomes a very serious problem due to everything already built in these years. Please, make better decisions. Don't do this.

[Alex Steinlauf]

With this change will we be getting an update to Permission Schemes to allow us to decide *who* can create and manage Automations? It's shocking to get a rather major change without also being provided tools to enable us to succeed.

I can easily see Project Admins ballooning Automation runs.

Additionally, will we see expanded functionality like utilizing Smart Values in Workflows/Post Functions? I assumed Automation was to alleviate how much your workflow is doing but ironically it seems to be the solution again to save on executions.

[Gurtek Singh]

Agreed with the larger sentiment on this post. This is a horrible decision. 

We understand the need to evolve and adapt your business model. However, the announced changes to automation usage rules have raised widespread concern.

Here are a few key points of contention with this change:

• Imposed Limits on Automation Usage: Automations are key tools we've been encouraged to use for enhanced productivity and process streamlining. They serve as valuable workarounds where there are limitations within Jira's functionality. The new restrictions on automations therefore reduce not just a functionality bonus, but impact usability and user experience, as it feels we're now being charged to fix product limitations.
• Disproportionate Allocation of Limits Per Product: Expecting sites with vastly different user counts to operate under the same automation limits seems disproportionate and unjust. It's unfair to expect a 10-user site and a 1000-user site to successfully operate under the same automation limits. This one-size-fits-all approach fails to take into account the differences in scale and complexity across Atlassians customer base.
• Impacted Project Administrators: Limiting automations in single projects means that higher-level admins will now bear the burden of managing them. This runs counter to empowering teams and fostering an agile workflow. The decision seems to lack thorough consideration from a user standpoint, and feels like a departure from the core agile principles that we value greatly in Jira.
• Short Notice Period: The limited timeframe provided for adopting these changes has left us with very little time to adapt and reassess our task management portfolio strategy. This lacks the ample consideration usually experienced with Atlassian’s major changes.

We genuinely hope our concerns are considered and lead to an open discussion about feasible adjustments to these new rules before they take effect

[Kristen Hugg]

Atlassian, you are so radically out of touch with how to approach and support your customer base with your cloud updates, especially those working in the admin and/or project admin capacity for their organizations, that I would say it is comical, but nothing about this is funny. Nothing about this is enjoyable. Nothing about this is reducing stress or overhead for anyone, except perhaps you, and even that's debatable.

I think many here would agree that your recent product choices reek of poor planning and greed, plain and simple.

"We're making it better!", you cheerfully exclaim as you change the automation limits with only a month's notice, leaving everyone here to panic and scramble and rethink a collectively inestimable amount of automation configuration on top of our regular day-to-day tasks.

"We're making it better!", you tell yourselves as you put in the cryptic evergreen notification about being over the attachment storage limits in Jira and Confluence, with no current implementation for managing storage issues, and no perceivable plan in sight. Remember everyone, the Storage page under the Billing section says "There's no penalty for exceeding the storage limit at the moment." That's copied verbatim - so just wait for the 1-month notice about this topic next!

"We're making it better!", you chant, in an attempt to brainwash yourselves and us, as you push out billing changes on top of all of this, again with next to no lead time for us to ready ourselves for the changes.

You're not making it better. You're making it hell.

Looking forward to the next "How would you rate Jira" pop-up in my instance so I can give the lowest score I will have ever given, along with some additional artfully-worded feedback and the "contact me" checkbox turned off.

[Archi Apronti]

@Kevin Bui It's completely unacceptable to include single project automations that were previously unlimited in the newly proposed usage limits. The excuse that this is somehow good for customers is frankly insulting. This decision needs to be rescinded, otherwise it's a breach of customer trust.