This is very disappointing. It is certainly not fair that this is promoted as a simpler and more consistent way of measuring automation rules, although the real consequence is cost maximization in certain billing models. Jira and Jira Service Management can be very powerful tools if automation is used to its maximum, but any limitation of it restrains the tool. Atlassian should be aware that there are companies with a larger number of users which are using standard features of Jira/JSM with a big number of projects and issues. For example, a standard model can sometimes be enough for 500 users per product (for example, basic support through JSM). Those costs can be high based on user amount, and now those teams are forced to switch to a higher pricing model plan (even a lot of those features will not be used). In some situations, it is difficult to control how many automations will be executed (especially in JSM -> where the base is customer-driven) etc.
I think that is duplicitous to talk about some fair models, especially when a lot of customers were affected by automation bugs [unavailability and delay in executions in last month's] -> As I know large amount of them did not have any rights for refund/discount even that maybe caused serious service disruption and trouble for admins/agents/users/customers.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Not sure if anyone else is seeing this, but it seems like we got the "usage preview" function a bit earlier than October 1st.
If there's ever been a doubt in my mind about why they've decided to make this change, it's been cleared up:
Two other things about this I noticed:
- It doesn't look back across September, so we won't really know what the actual usage will be until the end of October. Which means we won't really know what we need to change until the nominal due date to make those changes. That's some good change management process right there, Lou.
- I'm waiting on confirmation from Atlassian Support on this, but it sure looks like the usage allowance for Jira Work Management is only applicable if that's the only product you use. So if you have Jira Software Premium for example, you just get the 1,000 per-user-per-month for that and nothing for JWM.
@Haddon Fisher , I don't have an instance that shows anything value as it is simply a free instance with limited automation runs other than my testing. Would you or any other party here be willing to share an image of the trend that is supposed to show over the last six months?
@Brandon Fish I've read that using the API won't count against those totals so we're looking at spending the year grace period at shifting our workload to Scriptrunner. We also consume about 20k automation runs a month so we're in the same boat as you.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Hey Jack Brickey, there's very little data in the tool right now, but this is what I am seeing:
The top section is aggregate info about our overall utilization. To give you a sense of the limitation numbers, we're "Premium" tier customers with ~ 1,500 users. It's hard to tell exactly when it started collecting data, but it doesn't look like it could be more than a day or two.
The bottom section contains metrics for individual rules, as well as the option to disable them directly from the panel.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
As a contractor to small businesses this is likely to nuke a relationship for me.
I moved them from another system to Jira Cloud - completing migration last week. Automation configuration was under way this week when, today, I noticed the banner, that led me to this page.
Project level automation at these low limits with no option to buy more executions is going to ruin the features and functionality I was promising to my customer. IMO, these limits make certain use cases pointless now (feeds to Teams or email, issue field changes based on fields / criteria, etc).
I really hope Atlassian surfaces here to either rescind this change, make higher limits or at least give a reasonable time to make a change (really, just 1 month?). Just in my testing of the partial workflow configuration I have consumed roughly a hundred executions.
I really hope this isn't the mark of me having to find a new tool to lead with in my next opportunities.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
We had in September a usage of 6114 in Jira Software, with a limit of 1700 :-(
There are probably some rules we can turn off or reduce, but there is no way we can fit our needs into this absurd limitation. The only way forward is to stop using automation and find another solution to the gaps we have in Jira's functionality.
This is really sad, since I have been an automation fun for a very long time now, even at the time it was an add-on.
@Kevin Bui - we do not need to renew until August. According to your communication, new limits would not be enforced until next renewal. Looking at our data, the new rules are enforced.
I join the wagon and am also deeply disappointed in this move and the timeline of it, just one month to decide/make the required changes and not even giving us enough data to be able to assess our current situation...
And and also, you may want to update your pricing plan page to announce the change to your future customers...:
Have just had it confirmed by Atlassian that we are unaffected by this as our annual renewal is before the 18th October.
Atlassian really should be contacting admins directly, to explain how this affects them individually. This would have prevented countless meetings in my organisation and 2 full days analysing our Automations.
I don't think the notification on the Automations page is sufficient, as you may not check this often on a mature project with no errors or changes that require attention.
And I don't see any reasonable case for applying this to customers before their renewal date. Obviously this doesn't help monthly customers much, but those on annual plans have been essentially mis-sold the product.
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
I see Atlassian's response has been to add some clarifications to the original post. Personally, not sure that's really the appropriate way to address 10 pages of negative feedback, but I'm not the MC of this particular circus so not my call. However....
I think the second claim that "per our analysis, these changes will impact fewer than 5% of Jira Cloud Free, Standard, and Premium Edition customers" sort of misses the point. Equally important to the tactical "do we have enough executions in the bank for all of our Automations to run", this change introduces a significant behavioral change to how we use the tool which is not limited to the 5% of customers you think will need to entirely rework their Automation ecosystem. The tool has trained us to build rules in a certain way, and with almost no warning, you're upending the entire model. You speak to this directly in your opening statement saying that you "acknowledge that this is a significant change for affected customers", so it seems somewhat contradictory.
The statement that "Jira Cloud Standard edition customers who are currently projected to exceed limits in the new model will have access to a 3-month trial of Premium at the price of Standard, allowing 4 months to adjust to the new limits" seems to reinforce the sentiment raised here that this change is being driven primarily to squeeze more money out of us. It does feel like that has become your primary motivation in recent years, which is not a great feeling to have.
I do very much appreciate rolling out the usage tool early. Can someone at Atlassian confirm that the data it has includes the entire month of September and not just the last couple of days of the month? It looks like it might, but there isn't a way to confirm I can find. I don't suppose it's possible to backfill with months prior to September, but if it is, that would be tremendously useful as well.
Atlassian Team members are employees working across the company in a wide variety of roles.
October 2, 2023 edited
@Robert Condon Thank you for your feedback. We are contacting all Jira Admins directly today to let them know about the change. We will also let them know if based on their current usage, they may or may not exceed the limits in the new model. Please let me know if there is anything else I can help answer.
I am still missing a reasonable explanation why a 10 user standard setup should have the same amount automations as a 35'000 one (their max, not that I'd want to be in those shoes...), unless a) atlassian really does not want us to use automation or b) they really want squeeze even more money out of larger customers.
Atlassian Team members are employees working across the company in a wide variety of roles.
October 2, 2023 edited
@Haddon Fisher Thank you for your feedback. The usage tab right now should show data for the whole month of September. If you are not seeing that in your dashboard, please reach out to support and we will take care of you.
@Andrew Morse, the usage tool allows you to see total runs per automation rule for September, but the more helpful portion at the top is limited to the current month. So I will have to multiply the current counts by 30 to get a more accurate estimate of my monthly usage.
I am confused about JPD though. It says it's going to continue to be unlimited. For how long will this be true? Is this because of the 90-day trial?
@Haddon Fisher if only 5% of customers are affected, then I don't understand the reasoning behind the decision. Only 5% of customers need to upgrade, so the increased revenue is not that much. However, the 5% customers affected are dedicated customers who have invested a lot in the product and are very unlikely to churn. That may also be part of a reasoning that goes like this, "hey, 5% of our customers have put so much effort into our product that they are unlikely to churn, so let's make a good profit on them". I buy the argument, but I think that there is a side effect that should not be underestimated, and it is “bad reputation”. Who are the customers that invest in making Jira better? Many of them are the bad ass customers that promote Jira and are an inspiration for other customers. Even if the %5 customers are locked-in and must accept to pay more, they will spread a bad reputation that will have a big influence on the 95% customers. Time will tell if the side effect is real or not… if increased revenue from a marginal customer segment performed so well that bad reputation didn’t matter at al
453 comments