Introducing our new packaging model for Jira Cloud Automation

[Matthew Patton]

Seems like you are in trouble if you ware the only one building automations for your company.  Only 1000 per user, but only 1 user is doing for a 1000 people.  Would I have to create an automation account for each large project?

[Lara Jones]

@Kevin Bui  Wouldn't it have made more sense to stop counting executions against our total on the 14th of Sept through the end of October so people can start making changes today?  

You've only given us a month but we can't actually do anything these two weeks as I understand it because the old billing is still in place. So if I start making changes today,  anything I do counts against our existing plan with the lower number of executions.

The more I think about this, the more terrible this entire situation feels. 

Why the short notice?  You realize that for some of us, this is a major lift, right? 

[Haddon Fisher]

I was pretty ambivalent about these changes until I got to the part about single project rules counting against your usage limit. I feel like (once again) y'all are missing the point here.

You spent all that time and money buying Codebarrel and integrating Automation deep into Jira because it made Jira so much better. Replacing all of that manual ticket management freed up a huge amount of time and energy, which made people more productive, which made Jira look better, which led to higher and more spending with Atlassian. We use Automation as a key component for so many critical business processes that the recent Automation outage was reported first to the Jira admins by our People Operations group, not IT or any of the development teams.

Making it more restrictive and\or expensive for people to use Automation is not going to drive people to the higher tiers; people will build less rules, which will lead to worse data, and make Jira less palatable as a tool.

In the comments above, František Špaček _MoroSystems_ calls out one major problem already: project administrators can be enabled to build their own automation rules for use in their own project. This made it safe for Jira administrators to delegate the creation and maintenance of teams' business logic to those teams. This in turn allowed those teams to actually use Automation because as a two-man admin team, I do not have the ability to manage 1000's of rules for my 1300-person company. 

I'm curious to see what our usage preview looks like; I suspect it'll be pretty bad, but with this many users on a premium tier we might be OK. Of course, OK in this instance just means "perpetually on tender-hooks for the moment when some project admin uses up our entire monthly allotment by accident OR taken out to the whipping post when I tell everyone we have to disable their Automation access".

However, I feel for anyone on a small-to-medium sized tier trying to get non-Agile folks onto Jira.

[Nathan Trout]

Completely unacceptable to treat loyal customers this way. This on top of the price increases coming are going to force companies away from your products. Atlassian, what are you doing??

[Jim Bren]

This is going to represent an absolute deal breaker for us and as has been said above, feels like a disgraceful breach of trust.

Additionally, announcing such a major change less than 45 days before it goes into effect, and only giving us the last 30 days in which to evaluate the impact is, well to be blunt it is offensive. 

for the most part Jira is a great product that does it's job well for us. this change will immediately make it utterly useless.

@Kevin Bui 

[Leonardo Souza]

@Kevin Bui and the entire Atlassian team,

I want to join the chorus of frustrated voices that have already spoken about this issue.

Atlassian's decision to include single-project automation in the usage count is disappointing. It feels like a deceptive tactic and a significant breach of trust.

We heavily rely on single-project automation and have invested substantial time in their development and maintenance. Often, they fill gaps and provide features that should have been included in the core product.

This move by Atlassian is profoundly disappointing.

[Lee Page]

Wow.

To better serve you, we're removing the foundation of your house.

But for roughly twice your current price, we'll let you rebuild and use the kitchen.

This is perhaps the most disrespectful Atlassian move yet.

[Leonard Hussey]

Very important to consider, imho:

If "Log Action" or "Create Variable" or "Create Lookup table" will not count towards the limit, then:

- for consistency, each Automation rule result should show as NO ACTIONS PERFORMED when any of these is the only actions executed before the end OR before a filter stops further processing.

As of now, the creation of a variable or log action or lookup table do show as "SUCCESS" execution result.

I've just tested all 3 use cases and in all 3 cases, the result of the automation is "SUCCESS". Then, if the insight statistics are checked (the current ones) they show as successful runs.

My test: I've tested the 3 variants as:

a) being the first action before a filter that stops the run -- result = SUCCESS

b) being an action after a filter that is fulfilled and before a filter that stops the run -- result = SUCCESS

c) being the one single action in the automation -- result = SUCCESS

How will the usage counts ensure that these do _not_ count toward the limits if on each automation their use ends up showing as SUCCESS?

[Stephen Solomon]

Fortunately my rules are efficient enough that our JSM only does about 2000 tasks per month, but this does disincentivize creating more rules, which is likely the aim. Can't see a reason for this other than Atlassian seeking to reduce server bills. 

I'd definitely be in the very angry group if these changes didn't include bumping the global limit from 500 to 5000.

[Francois Bousquet]

How dare you to only give us 30 days to evaluate if we fit in the new process by releasing the new analytics on October 1st? 

That's not enough time for us to see a trend.

In addition, if we want to switch to annual to postpone the change, we have to make up our mind before October 18 since you announced a price change at the same time.

These are all sales tactics only geared towards profiting from your position of power where many customers are locked in your model.

Upgrading from Standard to Premium is not a small step, but it is a major change that translates to 250% price increase! You are effectively forcing it onto many organization with a 45 day notice.

Good luck keeping our trust after that.

You should seriously consider the following options: 

1. Keep the per project automation unlimited
2. Change the Standard limit to be per 100 user instead of 5000 total. 
3. Charge by usage and skip forcing people to Premium. 

[mariusz_dalewski]

This is unbelievable. We spend several weeks of work on automating the addition of single project type rules, because that's what support instructed us to do (global rules have a problem with context when run from cron) and here you go.... Has anyone out there thought about your (still) current clients and the consequences of this change?

This is not some game where you click and the world changes. We planned the migration for a year, changed all processes under it, recreated the automation because obviously nothing works as it should, and here is another problem.

Good job Atlassian!

[Thomas H.]

giving a 11 Standard user Installation the same limits as a 1000 Standard user one and not even allowing customers to pay for higher limits?!?  are you actively trying to get larger customers to move away from your products now that they where already forced from hosted to cloud?

what an awful move considering >50% of all data/maintenance questions seem to have "just use automation" as the only viable answer due to the lacking native capabilities of the products.

[Adam Bower]

Everyone already said what I think, so I'm commenting here just to add that this downright egregious. Small / mid-size businesses that rely on automation for operations will cease to use the product, unfortunately for both the businesses and Atlassian.

[Joseph]

Are there plans to increase the number of steps that can be created in a single automation rule? 

We have some complex rules that calculate the Risk and prioritization of bugs based on many different criteria, and because of the massive limitations in the steps and interacting with data, they have to be broken down into multiple rules. 

[Dave]

Edit 20230920 Automation- The penny dropped - Does this mean that when we update a comment / close a ticket / change a field on a ticket does this mean $$$$$$ for our company?

How can I tell how many automations are sent a month? is there a report

If that Automation goes to five people is that counted as one Automation? or counted as 5 Automations?




As normal I received an email advising a price increase so I thought I'd read about it click on some links to see what it is all about before I advise my managers and so I was across it. - I'm not really.

Read the email to try and understand it then I clicked on this link- I should have stayed in bed.

We use JSM (standard) have 10 Users + some other 3rd party apps. have several projects with limited tickets.

We pay yearly and are paid up until mid May 2024- so no changes should apply to then if anything.

I didn't know that we had Jira rule limits - I think these new costs will not effect us 

It looks like the current cost is 2100:00 USD and will be 2310.00 USD estimated. 

[Rowell]

The 5,000 monthly limit will for sure be hit within our organization as we are averaging 11,000-12,000 tickets monthly. There are one to two automations that run for every issue created. This is why we spent so much time maintaining project-level automation. If it weren't for the multi-project limit, we could have configured this as a global automation. We never complained about this. 

At this rate, it will impact our business and customers badly if automation stops running. The alternative of upgrading to Premium is not a wise choice for a small company with less than 100 users.

If only we could have the option THIS EARLY to see our "preview" for a few months back so we can plan accordingly instead of waiting until the end of October to see a full month's data. This kind of change is a business change and is something that can not be rushed in a 2 month-window.

[Srini Chakravarthy]

@Guido Menardi Thank you for the question. The packaging change is only related to the number of available rule runs. There is no change to the daily processing limit. 

[Majken Longlade]

I have to agree with the sentiment that this feels like bait and switch. We've been clearly getting moved towards using Automation instead of Workflows for any advanced issue management, and now new limits on Automation. Does this mean Workflows will get some love? We have many rules that could easily be triggered from a workflow step, rather than needing a listener, but the available post functions don't cover the use-case. (I'll add a specific example when I come across one.)

If I'm understanding correctly, the limit a rule counts against depends on the project type? So if we have Premium of one Jira product, and Standard of another, but do most of our automation in the Standard type projects, we don't get the benefit of the rules we're paying for in the Premium product?

[Mullin_ Joe]

This is not true - you didn't increase the limit for Premium users.  Every other plan received an increase except for Premium.  You should bump it up.

[Jacob]

Hi @Kevin Bui

Can you please clarify if an automation rule has multiple actions how that is counted e.g.: 

• Trigger: When an issue is created
• Action:
  • send email 
  • Assign issue 
  • Transition issue

Does this count as 1 execution or 3?

Also does customer notifications counts since it is basically an automation rule?

Thank you.

[KC Wong]

Have you heard about the dumptster fire that is Unity the 3D game engine? 

You'd think maybe John Riccitiello (Unity's CEO, former Electronic Arts CEO) and Mike Cannon-Brookes are related by blood. 

[Rob Horan]

What will happen when:

• A rule conditionally takes action and the condition is not met yet the rule executes successfully - will it count even though no action is taken>
• A rule spans multiple products?  Can a rule be counted against more than one product per execution?  If not, which product does it count against?

Also, the 1,000 execution per user, is that a pooled sum?  For example, if there are 50 users, can one user run 49,999 executions and another run only one, and still be OK?

[Han]

We are very disappointed that a single project automation included in the limit in this change. We will seriously consider continuing to use Altassian products. Maybe we should find another project management tools to replace Jira.

[František Špaček _MoroSystems_]

@Kevin Buithanks for the reply, I did not know I can turn off Project Admins ability to create automation. That helps a bit.

Been a day to think about it more and I now see how the devil's in the detail. I've got few more questions and points (from Atlassian partner point of view):

1. Currently when company wanted raise the limit of automations they only had to get one Premium product (either JSM or JSW) if they used both. Customers usually picked JSM premium because that's what really help them solve problems and Asset database really is a game changer for many. While JSW premium brings very few things on the table and they remained on standard with that. This move helped them to have enough rule executions in the whole instance to effectively not need to manage single project automations in JSW projects (and JWM/JPD projects too). Now, having a split limit for each app, this probably might have a large scale effect on lot's of customers that built their Jira around these information and from this point of view I agree with the rest that 45 days prior the change goes in effect is really not that much time to think all of it through and fix everything immediatelly. Not to mention that while it might not be a direct problem NOW for lot's of customers, this change will effectively halt any further automation development if they are already somewhere around 75 - 80% of the new limit. So we are not talking only about current status but how it will affect future automation consideration for another bunch of customers.
2. It is not clear how will the split limit be used for multiproject automation that involves different products. Will the automation be counted towards the product that triggered the rule? Or to that one that will be affected by it? This might potentialy create lots of misunderstandings on the admin side of things. I still think that single limit accross the Jira was much easier to understand.
3. If the Premium variants have automation per user bought why can't we have same for the Standard? This would easily solve lot's of limitation problems for companies from the point 1 of my text here - e.g. when they have 50 JSM Premium agents and 300 JSW people (which is pretty common). Now they would have over 50k execution for whole Jira but from 1st of November they will have 50k for JSM and 1700 for JSW standard which is not going to work anymore. Having e.g. 200 executions per user bought (so you can still advertise to have 5x bigger limits in Premium) would help us a lot and also would unify how the limits are calculated and make it easier in the long run. Also for some companies that would mean buying a higher user tier would effectively solve problem with small limit and would probably be cheaper too.

Thank you.

[Guido Menardi]

We CAN'T do what we were doing with all these limits:

• Process limit: 3600s/12h
• Less automations: New execution limit
• 65 components by rule. We can't improve the rules

I didn't heard any solution or new way to continue working with JSM.

We have a Premium licence, but this is not enough.

Bye, see you arround Atlassian!

PD: Can you explain me why in some places says that Agent limits is 5k and others 10k?

Plan selection 5.000 agents / JSM Pricing 10.000 agents