Introducing our new packaging model for Jira Cloud Automation

[Patrick Russell]

@alexander_tzonkovI think they tried this approach with the advanced roadmap and the sandbox, not sure how effective it was for their sales however.

They also took away project archiving from the standard plan when they first introduced the premium tier.

[alexander_tzonkov]

Thanks @Andrew B for the fast reaction and good insights. I will definitely escalate this but having so many negative reactions / comments should also raise a flag to Atlassian to rethink this decision.

[alexander_tzonkov]

@Patrick Russell Absolutely - We have turned to Premium especially for the Advanced Roadmap for a period of time (as I was using Portfolio previously) but I was not so happy with the feature for the usage of our context and switched back. For the Archiving, which should be again a basic feature, is not a game changer that can be beneficial for going Premium. The same is with Confluence Premium I think as I was researching it in details.
I would definitely prefer to pay smaller amount for a specific feature (let's say unlimited automations which is in smaller price - $0.5 per user) instead of going with the whole Premium package.

[Peter Fjelsten]

@Slava Gefen - I agree. Makes absolutly no sense.

There is just one possible explanation: forcing users to Premium (which is vastly overpriced in my opinion) 

[Adam England]

It's laughable at this point, I've been going backwards and forwards on a support ticket and they act like it's something completely out of their control.

Let's look at the facts.

• Share price dropped 4 fold post-pandemic as a whole host of other solutions are out there and shareholders are understandably concerned.
• Compute costs are up.
• Drive to the cloud vs self-managed/hosted.
• Security issues and major downtime in the last 12 months.
• Huge investments in potentially cool technology but the fundamentals aren't fixed.  Did anyone ask for video conferencing in Jira i.e Loom?
• Shoe-horning in AI, when no one asked for it.
• Pressure from the big players who are rolling things out that is scarily close to looking like their "darling" products.  Have a look at Microsoft Loop and wonder how they are going to sell Confluence when it's free with a 365 sub.  Even SharePoint lists and Power Automate are coming closer to replicating Jira's core selling points.

For Atlassian, this is riding on customers who are too far deep into their suite being embedded into their business and to squeeze every last drop out of subscriptions and it's a gamble on them if loyalty pays, or people decide to export everything out of Jira and restart their journey elsewhere.

As mentioned before, this would be a whole lot more palatable if they gave us options to grow with them.  Automation bolt-ons would be ridiculously easy to implement but they don't want to.

They have a plugin and 3rd party app store and they say that adding an Atlassian Bolt-on for Automation is too complex and this is helping standardise their automation pricing model?  Forgive my British, but it's bloody nonsense and they know it.

[Dominik Březina]

@Adam England 

I just had a look at Microsoft Loop I am like, WOW! I am very glad you mentioned it here cause I didn´t have idea something like this exists and for the first hour try it looks very good!

Our company tries to get some knowledge base collaborative software and Loop actually might suit our needs!

The funniest thing is our main candidate is currently Confluence and since this new packaging model for Jira Cloud Automations I was defensive against it so our implementation wasn´t so fast as it generally would be. Now I will try to reopen the investigation and go after alternative solution.

Also reading other comments I didn´t know project archiving used to be part of standard licence. It looks like Atlassian doesn´t hold back and can screw up their customers any time when their greedy needs arise.

[Archi Apronti]

We already are 72% usage. Yet Atlassian says this arbitrary change in pricing only affects 5% of accounts @Kevin Bui ?

[KC Wong]

Atlassian can't hear you over how awesome their new get-rich-quick-scheme is. 

[Andrew B]

@Archi Apronti I commend you tagging the Atlassian poster, but they won't reply as your question is not a PR opportunity.   I suggest you raise a case and seek detailed advise on how to optimize usage.  In terms of the 5% question - what motivation do Atlassian have to be up-front-truthful about the impacted community? 

In GREAT news - thanks @Adam England for the Microsoft Loop reminder.  I was aware of loop but not the recent progress... it's GREAT - the team LOVE it.  Good bye confluence bill (direct result of this discussion thread).  

[Sam Dean]

Not sure if you can post video content, but funnily enough, one of our employees just posted this:

https://www.youtube.com/watch?v=LPCUAgzUt2k

Anyone had a go at using ClickUp?

[Adam England]

@Sam Dean 

I reviewed Clickup, and where it falls short for us is a combined service management and pm tool.

However, I'm just going to drop this here on the miracle that @Kevin Bui sees it. 👇🏼👇🏼👇🏼

[Kevin Robertson]

We quite literally have no other option now than to move away from Jira Service Management.

This has completely and utterly broken the way that we utilise the system.

[Michael Lawrence]

17 pages and counting... still no reply from Atlassian

[Andrew B]

And what do Atlassian do when the usage gets to 90%?

Email all project users with an [UPGRADE] email & link. 

(and just so we are clear; no, not the JIRA admins, just the Project Team members). 
Just great for creating unwanted helpdesk traffic. Can't find a way to turn it off so raised a case.  Pointless I know, but they can share the pain they caused.

[KC Wong]

@Andrew B 

Can't wait to see what shenanigans will happen when it reaches 100%.

[Sam Dean]

It would be funny if it wasn't so problematic, but I remember being advised by an Atlassian tech support team member that it was better for users and Atlassian alike if we set up triggers for automations after individual actions e.g. create issue, comment added etc. rather than scheduling them. That's because it meant quicker automation actions being delivered for us, and for Atlassian a more widely distributed load on servers in the cloud, meaning less peaks and troughs of activity which could cause their systems problems... All this has appeared to turn that on its head.

It may be a coincidence, but I am now noticing scheduled automations failing in the audit log due to things like JQL searches throwing back too many issues (when there don't appear to be many / any in the search) and errors which I haven't seen before that say "service unavailable".

Atlassian must have foreseen that adding limits to the number of executions would force people to schedule more automations. Could this be what is causing these executions to fail, perhaps?? If so, then this was predictable, and something I mentioned to a colleague a month or more ago.

[Andrew B]

Well @KC Wong Here is what happens at 100% - the Dashboard has clearly not been tested for non UTC timezones, or maybe not tested for any timezone outside where developer/tester was.  For those of us early in the global day our dashboard was advertising "All Stopped" for half the day which appeared to be not true - things were working - it seems.  I'm still trying to get clarity on the "unblock" time from Support, and they are having a hard time understanding the question. 

[Patrick Russell]

Which is especially funny @Andrew B given Atlassian started as an australian company, so among the first to start their day :D

[Andrew B]

Yes @Patrick Russell as an Aussie it makes me sad and feel betrayed - but well, Atlassian don't care because what % are AU of the global market?  And, if they pump more $ into marketing they just get more sales and can ignore this dumpster fire - right?  Atlassian Product team seem to have exited this discussion a few pages back now. Onto the next project no doubt.  

Anyway, insights into what REALLY happens when automated limits are busted. 

1. EVERYTHING is based on UTC. (Oh, except the Automation Usage Dashboard, it's confused, see my post back a bit.  Any reference to UTC on the dashboard? not that I could see.)

2. Dashboard reports "automations have stopped running" which is NOT TRUE, Because > see #3.

3. There is a grace "period" ; I quote from the support team (I added the underline font) "Whilst the product did exceed the limit for November by 151 executions, none of them were blocked because we allow a 5% grace period for all customers. So for your limit of 5,000, you won't get blocked until you exceed 5,250 rule runs." (JST-941706)

So, Atlassian just wasted some more hours of our time today making unnecessary adjustments because Atlassian don't seems to care about sharing full and complete information - accurately. 
 
I'm in a similar situation to @The_Contractor . I signed this company onto JIRA, my next gig, no. 

Cheers

[Slava Gefen]

Hey Guys,
[AUTO-1007] Separate billing option for Automation limits - Create and track feature requests for Atlassian products.

Description

Customer would like have a separate billing for automation limits. With new execution limits they would like to have an option to pay for automation in specific rather than buying a Premium license for the whole product.

Some customers do not want to use any other Premium feature but still use only A4J and pay when limits are reached and get upgraded.

Vote 👍 Click 

Regards
Slava

[Paul Krueger]

@Slava Gefen Vote submitted

[Julia Foden]

@Kevin Bui 

As a former "Automation for Jira Pro" customer (when it was a third party app before Atlassian brought it in house), I used to have a banner telling me that I had unlimited rule executions for the lifetime of (my) Premium plan. Those were the words and I relied on them.

For Atlassian to break that commitment now is a shocking disgrace.

[Sam Hepworth]

@Slava Gefen: Voted :)

[Patrick Russell]

I just found old emails from how it went down in 2020 when they purchased and integrated the automation app into Jira.

At first they already wanted to set/maintain limits:

If you're using Jira Software Standard, you will now have 2000 monthly rule executions (*Jira Service Desk Standard will now have 5000 monthly rule executions).

If you're using Jira Software Free, you will be limited to 300 rule executions (*the same for Jira Service Desk Free).

For reference, the Automation for Jira Lite app included 300 monthly rule executions.

But then:

We have listened to customer feedback and increased the automation rule execution limit. There will now be unlimited automation rule executions at a single-project level across all Jira Software Cloud plans. All customers will be able to use global and multi-project rules also but there will be monthly limits depending on your plan, as per table below.

[Adam England]

So, I have some good news that isn't super clear with the Atlassian documentation.

Scenario (like us).  You utilize Jira Software Premium but only have Jira Service Management Standard.

You can move your automation rules from Project to Global and set a rule "If only X Project".

This means we can go from a 5000 hard limit in JSM to 100,000 using Jira Software Premium and migrating our automation to Global.

"Global rules will be billed to the product with the highest automation limit."

If you don't have Jira Software Premium you could purchase licenses which will bump your automation up by 1000 per user.  10 licenses will give you 10,000, etc., depending on your billing period and situation.

This is possibly the only way to scale in increments for those looking into the void of automation limits without doubling your Atlassian bill.