Introducing our new packaging model for Jira Cloud Automation

[Peter Fjelsten]

This is an awful decision further trying to push people to the overpriced non-base tiers. You communication is dishonest not mentioning that project executions are currently unlimited. The rules do what people using the system would do (for by far the most part) - so I expect your next step is making us pay extra to transition issues or updating decriptions: "yeah, you're paying a small fortune for Jira - but do you need to move issues? We have made this new super feature that allows you to do this. That till be +50% extra, thank you".

At least let us buy additional rules run for a reasonable price. 

Shame on you!

[Kevin Bui]

Hi everyone!

Thank you all for your questions and comments. While I can't answer all of them right now, I can tell you that the product team is looking at all of the comments on this page, and we'll be sending out a larger response soon.

In the meantime, I wanted to clarify how rules that span across multiple projects/products work. In a nutshell, each rule will only be billed to one product - even if it's a multi-project or global rule:

• Single-project and project type rules: These rules will be billed to the product of that project or project type.

• Multi-project and Global rules: These rules will be billed to the product with the highest monthly limit.

I've updated the FAQ section with this information, and provided a couple of examples to help you understand how this works.

[Yong]

JPD Free plan is till with 100, but not 200 limit as shown in the above new model. I don't know why~

[Yatish Madhav]

Thanks @Kevin Bui - I am a bit nervous about this change ...

But looking forward to seeing my current against the Preview. I see that this is not in the Product updates page. I would like to monitor and know when the Preview tab and the actual changes are applied to our instance.

Also can the preview not be implement sooner at all? I think 1 month is not enough for this and would like to ensure things are fixed or reviewed in ample time. 

Thank you

[l.seplecan]

Hi @Kevin Bui

We'd appreciate that Atlassian is interested continuously in enhancing and helping the customer/client environment. 

Reading the document + observing the other colleagues' reactions I remarked on a comment added by N Gobiananth on the 2nd page of this section but he got no answer. Supposing that this is a very important topic, to deliver accurate and complete information at every important change regarding any Atlassian new functionality.

Please can you detail and clarify this aspect(see the yellow's). Maybe till the 1st of October, this table can be more expressive.

I'm confused too. 

Regards

Liviu

[Peter Fjelsten]

"

We're increasing list prices for the following cloud products:

• Jira Software (5%) • Confluence (5%) • Access (10%) • Jira Service Management (5%‑20%)

These changes reflect Atlassian's commitment to creating more innovative products to connect your teams and boost their productivity. "

"Well, except for Automations - our number 1 productivity booster - here we'll make sure you'll become less productive [but of course still pay more]"

[Nick]

Perhaps I could understand this change if the Atlassian's resources were not enough to support automation, due to lack resources, but we pay a lot of money for all this to work and the functionality to only expand, but not vice versa.

And I would understand the price change, that Atlassian needs to update and purchase new equipment to maintain the speed of automation and the entire system as a whole, and that’s ok.

But when you increase prices and at the same time cut functionality, this is a very strange and disrespectful move, as many commenters above have already said, to be honest.

[Dominik Březina]

Very unpleasant start of the day. First in my news feed I read Atlassian is rising prices of their products in October, proclaiming they made new improvements in the past year, following with the message of this change in terms of calculating usage of automations. Are you seriously pulling my nose? You rise prices and make a huge change in automations that is going to make admins´ life miserable in the upcoming month?

Atlassian, have you ever heard about https://jira.atlassian.com/browse ? This is a place where you keep suggestions from people who vote there and which you somewhat successfully ignore for years? We use automations as workarounds to you flaws and holes in terms of features. I bet you like your flaws since you can use 3rd parties to fix them on Atlassian market and increase your revenue. I would point out one recent case I had to solve in past days.

JSW and JSM don´t support function for making copies of Epics with their stories and sub-tasks. I was very puzzled with that cause why not to define some specific structure of Issues in one Epic and copy them when needed and make processes easier? Well it is not possible. Why should it right?

I´ve found many articles in Community asking about this, with possible workaround using J4A or by bying a plugin solution on market (which is not acceptable, since we already spend big money on plugins). I adopted the J4A solution and now I read this kind of solution is going to drain a lot of resources, making it probably not usable at all.

Atlassian!

* You had 5% layoffs this year and not beacuse of financial issues!

* You are going to increase prices of products (again)!

* You now are now making change in a crucial feature that will mostly force many jira instances to upgrade from standard to premium cause they will go over the automation usage limit!

Yet you can´t make a higly demanded and important security feature like Automatic Backup generation in Backup Manager

I don´t know how can anyone put trust in you. You don´t care for your customers. You care only for stakeholders!

[Yatish Madhav]

@N Gobiananth  @l.seplecan - I also had to think that one through. @Kevin Bui  please clarify?

Correct if I am wrong, but it seems like current rules processing and count arent affected if a rule is on a single project, only for multi and global rules. But after 1 Nov, the rule processing and count is affected on all single project, multi project, project type and global rules ... which is why I mentioned this makes me nervous ..

Please let us know @Kevin Bui 

Thanks 

[Dylan Chadinha]

This is unfortunate, My company will be looking for another alternative SD. 
I have always enjoyed the functionality within Jira and automation has enhanced how our data looks by adding specific information or assigning tickets to teams that deal with them, however with this "new packaging model", it will be a hard sell within my organization and they will be reluctant to use Jira going forward.

[Nick]

Taking into account how Atlassian have updates and improvements that users have been asking for sometimes for several decades, as well as the release of new updates that are not always needed and used, notify customers a month before the changes to the basic Automation functionality that was previously used for years as patches to fix the lack of basic functionality in Jira products, does not meet the level of required customer service.

It is automation that makes Jira usable in the first place. Jira's functionality is very limited.

[Robert Condon]

I feel like this change has been made to target organisations like mine.

We are relatively new to Atlassian products, but have spent the last 18 months migrating increasing numbers of teams and processes onto JSM Standard, leveraging automation to deliver efficiencies.

We run around 9k automations per day, with around 2.5k of those being successful, leaving us no realistic way to remain in the Standard tier, and having sunk so much time into getting up and running without delivering much benefit yet.

Having wavered for the last year on upgrading to Premium, this will most likely be what pushes us over the edge, which I suspect is exactly the point of it

[Peter Fredebold]

I would like to add my Voice to this Thread as well: We have only recently migrated to the cloud and whilst we have previously only relied on automations in a limited fashion, this was due to being on an ancient Server Version. The more attractive Automation Options in the Cloud were a major selling point for us to even consider paying for our License again - we were on no support for years as we had no need to upgrade or receive support at all.

Now we're paying thousands per month again and are relying heavily on automations to greatly improve our workflows, but Premium has been out of the question due to its high pricetag; With the coming price increase even less so.

Multiple of our rules run on issue creation from our Callcenter Software's Reporting Tool. This can be over a thousand reports a day on a particularly bad day. Even with Premium, we would be stuck with less than 100k single-project executions - multiply 1000 reports times 3 rules times 30 days and that limit can be hit by those already, not even accounting for other Rules that run regularly to "clean up" forgotten issues or let our Team know about them via Emails, Teams and Webhooks.

We were happy to get rid of "The Scheduler" since we could just implement "recurring issues" with automations. That's another chunk of monthly automations we will now need to reconsider doing.

We have a custom "IT Team" field from our legacy installation that we want "synced" to Atlas Teams. This is done with an automation whenever that field changes, at least once when the issue is created.

We have Links to our Internal Tools that get auto-filled from other fields combined, based on automations - which is a huge productivity boost - and runs for every field change and at least once when the issue is created.

We're a "small team", but automations allow us to even work on this "small scale" as it does the heavy lifting for us. We are now going to be crippled by arbitrary limits on Automations that were assumed to be free to use and were a big selling point for us.

I am looking forward to the above mentioned upcoming communication in this regard.

[Rune Rasmussen]

I'll join the choir here. It's shit...

1 month is far too short of a heads up time.
Getting 3 months of Premium helps a bit with the timeframe, but it doesn't make the overall situation less shit.

Making single project automation count towards usage will force many of us to take away the project admins option to create their own automation, putting a huge burden on the the product admins.
The prospect of a single project admin using up all our automation executions because they were playing around or trying something new, means we need a tighter control of who can create automations.
Not very agile...

Splitting up automation usage rather than having them bundled across Jira products is a pretty dick move, and not what we initially signed up for.
I'm halfway considering if we can work around this by having a "dump project" on our premium product, and just include that in all automation triggered on our standard product, making it multi-product automation and causing it to count against the product that has the most executions available.
A hacky work around, but from what I understand it should work.

The current limit of 65 items in an automation needs to be either greatly increased, or the "Send web request" action needs to not count against the usage.

Announcing these kinds of changes, without also giving us the option to see usage pr. product shows an alarming lack of foresight from Atlassians end.

Trying to package these changes as a benefit to the customers makes Atlassian look dishonest and deceitful.

I really want to like Jira, and for the most part I do, but crap like this really makes it hard, and makes it even harder than it already is to get management buy-in on further adoption of the systems.

[Kimberly Phillipp]

I'll have to join the overall sentiment here. This is a disgraceful decision and en par with breaches in customer's trust that we have seen from companies like Unity recently. 

I have heavily pushed and encouraged my company to use Atlassian products and have spent weeks of creating single project automations to a point that a lot of our internal processes rely on them. We will now have to reconsider and potentially re-engineer all of it.

It feels like a bait and switch that has real life consequences for a lot of small(er) businesses and I hope that following this very clear customer feedback Atlassian will reconsider these changes.

EDIT: Receiving a marketing e-mail encouraging to 'use automation to keep your instance clean in the future' a day after this announcement also feels a bit like a very distasteful joke.

[Nena Kruljac]

None of us are satisfied with increased costs.

This will force us to do a lot of optimizations in the Jira, and postpone other tasks because of this.

Pricing model changes should be announced perhaps 1 year in advance, so we all have enough time to prepare for optimizations / changes, or re-budgeting costs for the system. This time period is not enough.

Will we be able to see "the most expensive rules" per months (that are successfully executed the most times so we would be able to focus to them first), and get a mail notification before the automation limit is reached (let's say 1000 executions per product before the limit is reached)? This would also be helpful, because perhaps currently some of the rules are not extensively executed, but at some point in the future, they will be, because of the various reasons.

[Peter Fredebold]

I also see a Problem with Jira Product Discovery's Automation: Whilst we do not currently utilize its Automation, I could see us doing so - we regularly get new Ideas added by our Collaborators, but there is no way to scale up the automation usage. So say, we have 300 People contributing Ideas, everyone creates 2 Ideas and an Automation Rule notifies us in Teams about it. Then there are some comments and Insights added, all whilst we have only 5 or so "Editors" Licensed for the Product.

You can very quickly run out of Automation Runs without any upgrade path.

[Fazila Ashraf]

@Kevin Bui  , is my understanding correct that if we are on a valid annual plan, these limitation will reflect only after the next renewal date?

[שגיא גואטה]

I don't like your "Fake Brightness" light in that article.

It's not good news for any standard user. 

You've made the automation unlimited so users will have to make a greater subscription later on?

A lot of our implementation in Jira is based on that particular issue (unlimited automation for single projects), and now you've changed it badly.

1700 successful automation actions per month is nothing.

I hope you'll regret that and change it to be more thoughtful.

[Axel]

Very disappointing to read about these changes. Too bad that we apparently can no longer trust Atlassian to do the right thing.

[Sean Noble]

Time and time again, Atlassian displays their lack of care for their customers because they think they have a grasp on this market. It's time for us to evaluate other solutions, as this change is disgraceful. Shame on you, Atlassian. You should leave unlimited project rule executions alone.

We already have a good BitBucket alternative (GitHub). It's time to find a Jira and Jira Service Management alternative now too.

[Raju Mandapaka]

Hi,

Is there any change in automation processing time, i believe we have 3600 seconds of processing time for every 12 hours after that we are seeing throttling error.

Is there any change in that time??

Thanks in advance

Raju

[Jason Selby]

I find it exceedingly disheartening to peruse this latest update and the ensuing comments, which articulate a palpable erosion of faith and confidence in an organisation I once perceived as exceptionally progressive. This company had a pronounced commitment to enhancing the customer experience and earnestly heeded user feedback to enhance their services. However, my current sentiment is one of suspicion. It appears they tantalised us with the promise of improved functionality and efficiency, only to subsequently introduce charges, akin to what some might term the "heroin effect" in certain circles.

With the imposition of additional costs and a noticeable decline in efficiency, it seems they are increasingly prioritising profits above all else, aligning themselves more closely with the profit-centric ethos prevalent among many other tech companies.

[Tammy West]

Simple Asset transactions with JSM require automation to updates attributes and quantity and such.  The Asset module is basically just a database with no added value without automation.   I would very much like to continue to build out our Asset usage but it would need to be functional and not just a bolt on database that I can't easily update within tickets without paying the automation tax.

[Andrew Gansler]

This echos other comments but nevertheless feel the need to say - This is a dishonest move.

I'd estimate that 80% of our automation rules are intended to compensate for lack of core functionality in the Jira software. It is probably the number 1 recommended solution to community/support issues. It is why we licensed CodeBarrel prior to Jira's acquisition, and why we were able to stay with Jira as our needs grew. 

Our organization, like many others, integrated key workflows alongside Jira Automations. As a result of this change, brought with insufficient notice or recourse, we will be forced to spend valuable, unproductive time, either:

1. Assessing all of our automation rules, rewriting, optimizing or removing, or
2. Evaluating, then implementing a new project management platform instead of Jira

#2 would seemingly take more time and effort, but my trust level for Atlassian has diminished since our adoption more than 7 years ago, and there is no guarantee that dishonest moves like this won't repeat in the future (e.g., "transitioning more than 200 tickets per month? upgrade to the new XYZ tier!")

So I will ask my team to begin looking at alternatives to Jira (and in doing so will likely move away from Confluence as well). We're not a huge account, ~50 licenses, so Atlassian won't acquiesce on threat of our departure. But I happen to be one of those sharing my plans here, others will just quietly leave.