Introducing our new packaging model for Jira Cloud Automation

[Jason Freeman]

We had already begun migrating from Jira Service Management and had some doubts about our decision, but this new announcement shows we made the right decision.  Jira is a dying platform.  Everything is either EOL or barely supported, and there are constant cost-cutting moves like the one in this post.  Atlassian as a company is in a bad financial place.  Move to FreshService or another platform and call it a day.  Atlassian's trajectory has been negative for 5 years and it's getting worse.  Most Atlassian employees know this too and are looking to get out.

[Jack Brickey]

@Jason Freeman , FWIW I definitely do not agree with you on your wholistic problems perspective. While I really regret this recent decision and hope it is rescinded I believe Jira and most of Atlassian products represent best in class in most capabilities and where they may not, Atlassian is investing heavily to improve. Moreover, I have received very good support when needed. I certainly appreciate that your experience/perspective might be different but wanted to maintain some balance in this thread. 

[Mark B Wager]

!!!!! WHAT???? !!!!! With all due respect -- THIS IS WRONG! IT'S A BAIT & SWITCH.
PLEASE RECONSIDER, ATLASSIAN. DON'T BETRAY THE TRUST OF YOUR FAITHFUL USER-BASE!!!!!  

We built an entire, elaborate process around automations with the understanding and trust that SINGLE PROJECT AUTOMATIONS WOULD NOT COUNT toward our quota! We are going to be THOUSANDS of automation-runs OVER our quota! We only have 75 users in our business unit. This will force us to purchase Premium or maybe even Enterprise (for a 75 user site!) This will TRIPLE OUR COSTS for your product!

At the very least, this change should have a been a ONE YEAR NOTICE, telling us that in the 4th quarter of 2024 you were changing, giving us time to adjust. If not for planning, then AT LEAST for budgeting purposes. Instead, you're giving us ONE MONTH to adjust! You are pulling the rug out from under us.  

I thought Atlassian wanted to HELP businesses, help them succeed and thrive, but this move is exactly the opposite. This feels like a money grab and it undermines the benefit your product has always brought us and the hard work we've invested into using it. 

I am beyond disappointed.

Please bring back single project automations that do NOT count toward quotas. Fix this.

Respectfully,

A bewildered Atlassian administrator

.

P.S. ATLASSIAN USERS - has anyone else run their numbers? Are we alone in our frustration over this change?

[Peter Fjelsten]

@Mark B Wager - I believe we will hit our quota on day 1. each month.

[Vince Clark]

we slightly longer day 5

[Josh Wexler]

@Mark B Wager Yes, i have run our numbers.  And we're currently, last I checked, doing the most rudimentary way I could since they chose to wait 2 weeks after announcing this to provide the "tool" that would like us see it clearly, and it came to 8900. I'm sure we could refactor them a bit to reduce successful executions and turn some off, however, even if we could reduce our usage by a 80% to get under the 1700 threshold we would basically be done with automations going forward.  

Someone else pointed out the lack of a sand box, so any new automations that you test and experiment with would also start going towards that count.  

it's just a totally brain dead decisions focused solely on pushing people to premium and an insult to our collective intelligence to package it as a "convenience" for use by packaging them together as if it was difficult for us to tell the difference between multi and single project automations.

[Fran]

I think we need Atlassian to come back onto this thread.

@Kevin Bui and @Srini Chakravarthy we would all appreciate this.

Thanks

[Lara Jones]

@Mark B Wager  Yes.  One project will put us over our limit within the first week every single month.   

[Kimberly Phillipp]

Atlassian really needs to come back to this. Their silence is effectively putting any planned implementation of further automations on hold due to the risk of having to be reversed within weeks.  

[Katherine Kirchner]

I can't say that I am too excited or too pleased about these upcoming changes, particularly to automation runs.  Our organization will exceed the automation limit in one day, in one project.  This does not even take into consideration the other 10+ projects that require automation.  Based on this comment section alone, it sounds like a number of organizations would now be expected to either spend a considerable amount of money to upgrade to the premium package, or re-engineer their entire platform to accommodate this change.  Introducing a change in price model with 1 month notice, in Q3 when most organizations have already completed budgeting for the year is incredibly bad business and even worse customer service.  I hope that one look at this forum is enough to show Atlassian how poor of a business decision this is.

[l.seplecan]

Hi @Kevin Bui and @Srini Chakravarthy

It begins with this message:

Therefore, that's the real intention of squeezing money out of upgrading to the next subscription level => PREMIUM. 

Wouldn't be better to ask clients gently, normally with a proper demand if they want to upgrade, not to use such abusive conditions?

To QUOTE a movie series GOT => SHAME! SHAME! SHAME!

[Peter Fjelsten]

Hi @Kevin Bui and @Srini Chakravarthy - please comment

[Sam Hepworth]

Severely limiting a feature that Jira encouraged customers to use and thus become dependent on is quite evil. Here is a quote from the Atlassian site:

"You’ll save countless hours of work in the minutes it takes to set up an automation rule. That means more time for the things that bring greater value to your organization." (https://www.atlassian.com/platform/automation)

It makes me wonder what caused Atlassian to do this? Is it a desperate need for revenue right now, even if it makes customers churn in a slightly longer time horizon?

[David Webb]

@Kevin Bui What about automations that have several actions. For example, an automation that creates 10 tasks when triggered. Is each task creation a successful run? Or creating all 10 is one execution? That is the difference between one execution and 10 that counts towards our limit.

[Constantin Lotz]

@David Webb  Even if one automation like assigning and transition a ticket will be only 1 charge, we will hit the usage in the first two weeks.

I don't know how someone can work without automated transitions based on customer reply and so on. For standard users this limit is a lot to small when having a mid sized environment.

I see the problem that this short announced change will break a lot of processes and use cases which will produce a lot of work/support needed... 

[Serginho]

I'm currently working on optimizing our rules, and it feels like quite a challenge. With the new model (with 1700 runs), using triggers like "on issue created" or "on issue updated" isn't feasible anymore because they consume a significant portion of the 1700 runs available, even if each run is relatively straightforward.

For instance, a rule as simple as sending a message to the manager when the issue priority is set to "Highest" can quickly deplete our run allowance. You should enhance these triggers with additional conditions to start the automation.

In my opinion, automations system is not sophisticated enough to justify doubling our expenses by switching to the Premium plan. Developing the same automation using lambdas and jira APIs is a much cheaper, flexible, and better approach.

On the other hand "This post was created Sep 14, 2023 to apply changes Oct 1, 2023". No further comments are required.

[Dave]

As well as others we are not happy about this change and I'm monitoring it for my management .

I think this is going to hurt for high Automation Customers and Customers who have several instances of JSM (not just Projects but who purchased new instances vs creating another project with in an already instance held) 

Fortunately we only have 10 Users  -  55 Automation Rules on individual Projects,  19 of which are turned on. 17 Projects including the OOB ones and some testing Projects.

Looking forward, see how many rules we are triggered regularly. Only because we have not long started to understand and implement Automations, and thought they were great until this post.

We have paid up until May 2024 so surely any changes should not be until May 2024?

[KC Wong]

Is Atlassian done playing dead yet?

[Mauricio Heberle]

This event is going to happen today and tomorrow. We should attend to make questions to Atlassian https://community.atlassian.com/t5/DevOps-articles/Live-Q-amp-A-event-Supercharge-Automation-with-DevOps/ba-p/2474324

[Leonard Hussey]

Many gaps and very valid concerns have gone unanswered until now. Radio silence from Atlassian. What else is new.

One more gap I've noticed: we already have Enterprise for JSM since some time ago, so we are covered (luckily) on that front...

But, while checking the "Usage" option (still the legacy one), it shows me that we have "Premium" for JSM.

We _certainly_ are paying for Enterprise. 

So... if at this very basic level the info is not showing accurately, I really wonder how this is expected to work at all on a 1-month notice period.

[Serginho]

I want to demonstrate you that I model is a bad model with a very simple automation example.

- On issue created

- If user belongs to financial team

- Edit issue, add tag financial-team

If, among the incidents created by people who are not part of the financial team and the incidents created automatically by the systems, we create a total of 3000 issues, is it fair for a simple rule to have a cost of 3000 runs to do nothing? Something is failing here.

[Jack Brickey]

@Serginho , while I too believe the decision is bad I wanted to comment on a possible solution for your UC.

Build your workflow and create screen such that the user creating the issue to tag the financial-team. 

I only offer this is an example of how we are going to have to rethink the usage of automation. Before automation was part of Jira we had to manage in a "life without automation" world. Now we need to approach in a "conserve automation" world. It will certainly be interesting to see what the Community comes up with as far as conservative and/or alternative approaches as time passes.

[Paul Krueger]

@Jack Brickey, I appreciate your optimistic approach; however, I've managed to make Jira jump through hoops with automation. While there may be some opportunities for optimization, 90+% of my automation rules are there because there's no other way to accomplish the task. Maybe I can schedule a task to run every 10 minutes instead of every time an issue is created, for example, but all that does is make Jira a "slow" process.

If this change goes through, these are the conversations I'll have with my users:
- "I know you didn't have to deal with a pop-up and a field selection for every request. Yes, I know it adds 30 seconds to every issue. Yes, automation could do it, but we can't use automation to do what humans can do because we have to save automation for stuff humans can't do. Yes, we're looking for a replacement."

- "Yes, it used to happen instantly, but now you'll just need to wait for automation to run. Yes, that slows down your process and makes you less efficient. It runs every 10 minutes, but we'll probably have to move it to 20 if we bring on the HR department. Yes, Jira used to be awesome and now it's stupid. Yes, we're looking for a replacement."

[Jack Brickey]

@Paul Krueger , I certainly appreciate all the challenges that we all will be facing…and indeed, this is a step backwards…and I hope that Atlassian changes their mind. In lieu of any reversal, we will be faced with those challenges and the need to continually look at how to manage through it or move on to other alternatives. My hope is that as part of the Community we can all seek to help each other. There is one thread started in that vein albeit very lightly attended ATM likely given the wounds are still quite raw. 

[Anthony Guevarra]

@Jack Brickey , I added a comment to that thread. Hopefully it generates some discussion.