Introducing our new packaging model for Jira Cloud Automation

[Andrew B]

Well, that's it - Atlassian has made the decision easy for us - Staying with JIRA is not workable. 
We have already invested in JIRA Automations but these new limits will force us to look at another product - can't go forward. 

It's nothing but a money grab move by Atlassian.   Poor form.

Supports solution -"Upgrade to get more Automations".. yeah right.

[Dave]

Come On Atlassian I now think you should reverse this change and put effort into fixing all those fishhooks that your System has. and is letting you down.

As mentioned before thanks to Atlassian Support, they are and have been very helpful.

Just now I found another defect that rings alarm bells to me not knowing what it does or if it will expose one customers data to another customer.

Just like the ticket raised with TEAMS (not MS Teams) where people could type random TEAMS in  comments within JSM  that were not part of their company - didn't know them but people could tag them - Atlassian assured us that they could not see peoples  data - that was fixed. 

Now to todays findings Not happy at all

The Automation I have set up to email approvers  so they could approve the ticket to be resolved or rejected (only customers in the Project) I added their email code to the automation within that customer Group (not sure if that's the correct Atlassian Term). The Automation wasn't working like it was in our test (sorted now)

but I had to manually add the approver where the status was DONE so they would get an automation email for approval and either approve or reject our solution. - closing the ticket

The problem I just noticed is: remembering that I have all our customers to this project are in a group so they are isolated and others Projects customers in another groups so they are isolated from each other. 

So they can not see or access others tickets. I thought that was working from a to z until today.

When I manually type in a persons name  who I want to add an approver, typing R I get the options to add people from another Project who I thought we had in Silos and kept apart. I guess not.

I can't afford to test this - live project and I can't afford that if a user accidently adds a person from another Project. - they get the email and are now seeing an other customers data. 

IMHO - There is no way that other projects names should be coming up if they are not part of that Project / Group.  

Adding an approver manually so they get an email. typing R I get people from another group and Customer 

Only Customers in the Blue Highlighted Groups below should be an option to add as an Approver. not others from another project as shown above.

This is why you need to back out of this change and test your system and fix issues you have.

[Steven Rhodes]

Although we are under the levels in JSM for now, (we have Jira Software Premium and JSM Standard), this is really going to curtail the amount of JSM projects we can undertake and we will almost certainly just make use of JS projects internally instead, and we won't be buying any more JSM agents as a result.

It is a real shame that Atlassian have gone this route as it really cripples the Standard tier and makes JSM Standard almost unusable at scale. So, JSM will just remain as is in use by ICT, HR and Payroll and no-one else. We just can't afford to scale up with it now.

JSM Premium just isnt worth it, because we don't make use of OpsGenie and the Assets part is simply unfinished compared to the server version and the integrations which just aren't there except for CSV importers. These should be built in, not addons doubling the price of the end product. It's not a premium product right now (I am watching issues for several features so this may change).

The timing of this, after we've just paid for our annual subscription (we pay just before the annual price raise), is also rather bad, then giving customers just 6 weeks, (4 of which with a new calculator) is very rushed and unprofessional. I'm just happy that we are under the limit and I'm sure this is a real headache for many businesses. I fear that a 3 month premium trial will only be used by many to migrate away from the platform.

[Adam England]

@Steven Rhodes 

We're in the same position.  JSM Standard and Jira Premium (for roadmaps)

What is really frustrating is that we can't have a totalized pool of automations ACROSS products.  This would be exactly the same amount of compute time and it would help us scale better.

It's pretty disgusting and a clear shift that Atlassian just want to bleed customers dry.

@Kevin Bui do you have any answers to the above please?

[KC Wong]

Fill up all your automation rules with meaningless but CPU intensive calculations up to the 65 components limit.

An execution is an execution, you may as well get the most use out of it. 

[Sam Dean]

Anyone looking into the legal angle on this? It seems like there are an awful lot of us. My company was promised (as a former Automation for Jira Code Barrel customers) that we would have "Unlimited executions for the lifetime of your premium plan". We've got this all recorded.

If we end up exceeding our Automation limits then our business will cease to function. We'd have to shut up shop until the start of the next month when our automations start running again. This can't be right.

[Paul Krueger]

@Sam Dean Someone earlier in the thread mentioned they were grandfathered in because of their previous subscription to Automation for Jira. We, too, used it before Atlassian purchased them, but I don't remember if there were different subscription tiers. 

@Kevin Bui Can you comment further regarding this exception? 

[Andrew B]

Sam - sounds like you have a case.

For the rest of us it's probably time to take the feedback external.  Atlassian don't seem to care much for inconvenient forum feedback... the only thing Atlassian will really care about is if new sign-ups slow down.  

[Takahiro Furuya]

I asked Atlassian Support to open a ticket for a fix that would aggregate the automation execution entitlement across all products. If you like, please help us by voting here.

https://jira.atlassian.com/browse/AUTO-984

[Txus]

Thank you @Kevin Bui. Now it is clearer to me.

[Paul Krueger]

BSM (Bad Service Management) leads to bloated budgets with features and modules we'd never use.

No kidding! I know Atlassian would never do something like force customers who are perfectly happy with Standard to upgrade to Premium just to continue using automation. 

 

[Paul Krueger]

As stated here and here it looks like we're required to use Automation executions for every Jira issue created by Opsgenie because Opsgenie still can't set the Request Type. Wasn't a "problem" before, just a minor feature request. However, now that every execution counts against our limit, this is a Problem. 

This is but one example of how we use automation to accommodate Atlassian's shortcomings.

[Andrew B]

The Atlassian orchestrated Money Grab continues.

Now - given we are going to hit the Automation limits of course the highly effective SPAM engine Atlassian have invested in to drive revenue growth kicks in... UPRGADE, UPGRADE, UPGRADE.

Of course the reality is - the marketing tag line should be "Pay more to get back what you had" (it's not about advanced features at all.... )

[Rafael Ibanhez]

I guess I'm just another one in the crowd of mad people. We have been using Jira for a very specific purpose and besides the limitations we always worked around. But now Jira really messed up, to a point that our hard work, time and effort to make a tool tailored for us to be useless. Hopefully all big players move to other platforms so Jira's leaders can see what a big mistake the made

[Marc Turner]

So who else now has an extra regular task to "check in" on the amount of automations we have remaining, DAILY. something I never had to worry about before...

I had a response from Atlassian support as to why I got an incorrect email saying i was under the limits.

"The Email that stated that you are not breaching the limit, was sent in error.
We used August 2023 data to collect customer usage and reach out to the customers and there your site was marked as "under the limits". "

So you're telling me although in September & October I had 30,000+ automation runs, somehow in August I had less than 5,000? I call bull****

I've also just re-raised the point that Jira Service Desk is not a viable service desk without unlimited automations. there is no built in way in the system that issues are marked as updated when a customer updates them.  Therefore we have to use automations.  I have no way of controlling how often customers will respond to issues (each time using an automation run) so if that's more than 5,000 times a month Jira Service Desk stops becoming a working service desk at the point the 5,000th issue update comes in (assuming all we used automation for was transitioning on update)

What makes this terrible decision even more terrible, is now I'm deep into the market trailing alternatives to Jira Service Desk, I'm realising quite how limited and poor JSD is, and how much automation was its saving grace. now that's gone, all we are left with is an unfinished attempt at a service desk.

[Artur Balyan @ Immedis]

@Marc Turner Oh brother, that's my new anxiety! I did the math, I used the free tool to check in advance and still check our remaining runs daily! It's really NOT fun.

[Sam Dean]

@Marc Turner I have been using an SLA because they offer a "comment added: by customer" trigger. You can then use e.g. the JQL: "Time to first response" = running() to find any where the customer has added a comment. The only thing is that these SLA counting triggers can sometimes be a little flakey.

Regarding your other point, yes, I am having to keep tabs on the executions on a near daily basis. This is just one example of the additional costs which are being imposed on us by these changes.

[Andrew B]

I agree @Marc Turner Atlassian's price changes have forced us to change horses for an upcoming project - and with what have found in the market over the past two weeks - I think we are looking an entire switch out to another solution.  Can't have two in the house, particularly when one misbehaves.  We are well into PoC on the other solution and it's going great.

oh, and ahh. No thank you... 

[Sam Dean]

@Andrew B what other products have you been looking at, if you wouldn't mind sharing? I had a quick scan online the other day, but couldn't immediately find anything.

[Ian Good]

Adding my voice to the mix. My firm just ran into the automation limit for the month of November, with 2 weeks left in the month -- bringing multiple teams' workstreams to a temporary halt -- with no warning from Atlassian that this limit was going to be hit -- and no way for me to 'buy more' without upgrading to premium. The initial email about the change told me that we weren't going to run into the limit. Paying 2x as much for Premium isn't in the cards -- so we will deal with the emergency Atlassian just thrust upon us and go find a more cost effective tool. 

[Slava Gefen]

Hey @Kevin Bui and all!

Have I understood it correctly that now

15 Users Jira Software Standard plan has the same 1'700 limit as 2000 Users Jira Software Standard plan?

Does it make any sense?

Regards
Slava

[Andrew B]

Hello @Slava Gefen 
It makes perfect sense if Atlassian want to make the Standard plan useless - and drive all (well, nearly all) customers to the Premium Plan.  It's a pretty clear revenue driven strategy from Atlassian. 
So yes you understand correctly.
Andrew

[Andrew B]

Hello @Sam Dean 
Yes - I was thinking it would be interesting to compare notes.  I'm all for sharing.
Rather than share our market intelligence with Atlassian I thought I might create a LinkedIn group where we can chat - away from the overlords.
I'll come back with that link in a day or so, all welcome.
Cheers
Andrew

[alexander_tzonkov]

Hi @Kevin Bui and Atlassian,

I would like to join the previous comments and ask for some review of this process. I can see that you try to find ways for more customers to go to Jira Premium. However, the approach applying restrictions to already present functionalities trying to push for Premium, instead of creating new features to make people go there on their own, is not very user-friendly.

We are 500+ users Standard - going Premium is not an option right now as the price is too high for the value we receive. At the same time the automation limitations is too low - please consider changing this and applying at least some limitations based on a user (i.e. 10-20 automations per user) - this will give us some time to breathe, instead of going back to many users explaining why they cannot use the Jira main capabilities.....

Is there an open Jira ticket to vote for this change?

Best regards,
Alexander

[Andrew B]

Hello @alexander_tzonkov 
Good job asking questions - but Atlassian don't have a history of replying to inconvenient questions!
I'm not even getting any email replies from the product manager after I invested time on a product interview for another issue....  anyway...

I suggest you make contact with your Atlassian Rep directly - and if you don't have one - get one.  500 is a big number!

There is no open JIRA ticket per se, it's a deployed change already - and there was no vote; Atlassian just did it to us all.  So again, if something is not right - raise a support case to get attention and make your case - firmly - but expect to be given a hard sell to upgrade.... escalate as far as you like/have time to do so.  Additional traffic in the support channel might help.

Cheers
Andrew