Introducing our new packaging model for Jira Cloud Automation

[Rune Rasmussen]

After having made changes to our most "expensive" automations to try and keep us under the new limits, I found that there is no way to get a day-to-day overview of automation usage by the new limits, making it very difficult to gauge whether or not it will help us "stay afloat", so to say.

After reaching out to Atlassian support to hear if I just couldn't find it, or if they could provide me with a daily report, the answer in short is that there is no such overview and they can't do it either.

So now a new feature request for a more granular overview of automation usage based on the new limits has been created:
[AUTO-929] Detailed and product-specific Performance Insights - Create and track feature requests for Atlassian products.

[jolyon]

Unlimited Automations per project has been something we have always leveraged to make our Agents lean and efficient. It was always that way and we knew that if we had global automation then these would be counted as a whole.

We primarily use one Service Desk Project, yet it feels that we are being railroaded into the Enterprise plan (we use Standard) just to support the number of automation we run per month.

There are no more features that stand out on the Enterprise plan, like nothing that makes it a must have. Yes, we have tried JIRA Portfolio 1.0 when it came out, and then JIRA Portfolio 2.0 when that came out and it didn't give enough value to increase tier, that main thing was creating tickets as a peer to Epics & global board without resorting to complicated JQL.

To put this automaton cost in practical terms - we will blow the Standard automation limit across the account in a day or so on our Standard, current plan.

We have  125+ Agents this is the tangible cost change from going from Standard to Enterprise so we can run the usual number of Automations.

• 125 Agents @ $21 per month = $2625 per month x 12 = $31,500 annually
• 125 Agents @ $47 per month = $5875 per month x 12 = $70,500 annually

So that's a price increase of $39,000 to run the number of automation that we have for years. This I might suggest is the reason that there are so many comments in this thread that verge towards not exactly being 100% enraptured with this price increase, via forcing a tier change.

[Rudy Holtkamp]

@jolyon how many executions do you think have on a monthly basis?

[jolyon]

Looking at the total today (17th of October) we have had 92,037 across all JIRA and JIRA Service Manager projects 🥹

Below is a chart from almost the end of last month on the main Service Manager  Project

[KC Wong]

We wouldn't need automation so much if the default list of workflow post functions is not such garbage.

Go ahead and create a new test domain. Don't install ScriptRunner, create a workflow and see how many post functions are there. 

[Michael Lawrence]

Is there any update on a u-turn / significant overhaul on the number of allowed single project automations that we will be allowed to run per month?

This 'upgrade' is coming at a review point for the start of the next fiscal year, so I am sure many companies are now reviewing budgets and plans.

Please @Atlassian inform us ASAP if there will be a change to your stance so we know if we need to seek an alternative product.

Many Thanks

[Rudy Holtkamp]

@jolyon A few questions/remarks:

1. How/where did you get this graph?
2. Is it accurate? If I visually combine success, error, throttled I don't seem to come to the total (which is also on a log scale).
3. Is this the 'old' count or the new count method?
   In the old method 'Success' runs are considered successful if there were no errors. But the rule could stop at the first condition and not execute a change. In the new method runs that stop add a condition which did not have execute an action don't count.
4. If all rules are counted against the new method and you still have a rough 100.000 runs, this means that you have this doubled by the end of the month. A premium license of 125 x 1000 rules won't cut it either. 😖

[Jack Brickey]

@Michael Lawrence , I encourage you to open a support ticket for your question.  To the best of my knowledge/expectations I do not anticipate any notable changes.

[jolyon]

@Rudy Holtkamp I'm getting the graph from Performance Insights graph - howto doc in 

https://support.atlassian.com/cloud-automation/docs/view-performance-insights-for-automation-rules/

I didn't know about this report until recently 

1. Project > (it's a Service management project ) > Projects Settings
2. Automation > (The table of your automations > find the mystery ellipses menu on the right
3. Select View performance insights
4. Then select your time range in the current month of 1h, 1d, 1w, 1m)
   

It will give you a table as well showing each automation and when it has run or not (automation names redacted in this case)

[Rudy Holtkamp]

@jolyon can you (or your Jira admin) take a look at: https://yoursite.atlassian.net/jira/settings/automation#/tab/new-usage

This wil give you an insight in the usage according to the new method.

[Brock Jolet]

Just gonna leave this here: https://www.atlassian.com/company/contact/contact-ceos

[Petr AST]

It's been exactly a month since my comment on the first page and, unfortunately, it looks like Atlassian has no plans to change anything. Each 14-page comment contains enough feedback to draw conclusions.
We are all very disappointed with this update, there is no clear reason for it other than the commercial side of the issue.

However, why do basic functionality like sending webhooks, sending emails, or setting entity properties require automation runs count? What alternatives might there be?

In the case of a webhook, for example, through the standard functionality, you cannot send a custom body(https://jira.atlassian.com/browse/JRACLOUD-63205). In the case of emails and properties, there are no alternatives. 

It's good to add these actions to exceptions as well as log action, create variable, create lookup table, refetch issue, and look up..

[Bill Sheboy]

Hi Community!

First thing, I am not an employee of Atlassian or any marketplace vendor.  With that disclaimer out of the way...

I fully support people helping to answer questions from other community members...in most cases.

However this "packaging model change" is leading to specific licensing and billing questions.  I strongly encourage customers with such questions to directly contact Atlassian Support (or your reseller).  Everyone with a paid license can have their site or org admin do that here: https://support.atlassian.com/contact/#/. 

That support team will have more accurate information than any of us users will have.  And I certainly hope that Atlassian planned for the reaction to this change, and so will have anticipated most common questions (and answers) on usage impacting licensing / billing.

Thank you.

[Charlie Gavey]

Hi @Brock Jolet @Lara Jones @The_Contractor 

I'm very sorry to hear you haven't yet received a response. Are you able to forward details of your query / support tickets to me at cgavey@atlassian.com, so we can follow this up internally and make sure the right team gets back to you?

[Charlie Gavey]

Hi @Rune Rasmussen

To view your Automation usage by individual product, head to the Usage Tab (rather than Automation Performance Insights). You can read more about this here: https://support.atlassian.com/cloud-automation/docs/view-your-automation-usage/

The Usage Tab is visible when accessing Automation through Global Settings, so you'll need global admin permissions to view this.

[Rune Rasmussen]

Ahoy @Charlie Gavey 

What I need is not the regular automation usage overview. It is a more granular view of the usage with the new rules.

We've been given a month to adjust our automations to these new rules, which is incredibly short notice.

So it would be extremely helpful to have day-to-day statistics of the new automation usage, so we can monitor the usage trend properly when we make changes to our automations.

Currently we have updated our most expensive JSM automations, but because we can only see month-to-date usage for the new rules, it's very difficult to gauge whether the changes will be enough.
Right now I can only see that it seems to be enough.

Example
If we could see day-to-day usage, It would be easy to see something like this:

Monday: 800 automation usages
Tuesday: 700 automation usages
Wednesday morning: Adjust automations to accommodate new rules
Wednesday: 300 automation usages

Even if something like this can't/won't be made available in the UI, being able to export a CSV file would also be very good. Then at least we could do some Excel magic to track the usage trends.

[Adam England]

@Charlie Gavey 

Are Atlassian acutely aware of this thread and the potential repercussions it can have on your entire business model?

If anyone in Product Management were to suggest this ANYWHERE else they would consider it to be a lose/lose situation.

For existing customers, you can actively see that they are making arrangements to move elsewhere.  Some great posts above here reflect that.

For new customers, you've just torpedoed one of the things that made the Jira platform scalable and cost-effective where if you had to tender/scope 5 similar work management solutions there's now a whole host of better options.

It begs the question, why you can't have a fair usage policy or suggest "Automation Bolt-ons" which are priced fairly in place so your current customers and new customers can work with you on automation runs?  Surely you must see from your side those customers who have automation attached to everything that basically run their business.  There's some companies who have less then 25-50 licenses, why on earth would you suggest an Enterprise tier solution which doubles the cost for this other than plain-as-day price gouging?

Also - on your website for new customers... on the pricing it says "Unlimited" until you click in.  Bit naughty.

[The_Contractor]

@Charlie Gavey  I very much appreciate the offer. I have relayed to my fellows. We'll see if they bother spending their time.

Even if you get Support to respond, we're likely to just get the party line response of what the changes are, to rework the rules and to consider upgrading. 

We know all that. None of that fixes our customers' showstopping problem.

The over-300 posts here highlight that.

Most recently, @Adam England articulated this super well (thank you Adam!). 

Project-level charges going from unlimited to nearly nothing with 6 weeks' notice is crazy.

Providing tier options that don't make sense, resulting in many companies (including small companies) needing enterprise licensing, again, crazy.

If this was truly thought through by Product, you'd have changed the model to only change limits on global automation.

OR

There would be some level of pay per use (bolt ons, like Adam described, as well as others).

And in either case some how build the system so testing new rules or changes to rules wouldn't affect limits (or at least minimally affect limits).

----

Saying it from a different angle, this may not seem to Atlassian that this change is on the order of scale as Server to Cloud but it is. This change with automation is affecting companies' ability to operate. Not a change in convenience or luxury, but impacting their ability to function and deliver their products.

Server to Cloud you gave us how many YEARS to iron things out?

We now were given 6 weeks?

Can't help but laugh at this point.

[Charlie Gavey]

@Rune Rasmussen Thanks so much for clarifying, I've passed that detail on to the product team, along with the feature request you shared.

[Jean Dupree]

How can people using automation for jira server tell if they are at risk for exceeding the limit?  It doesn't look like theres a way to get answers from the interface.  Would the cloud migration tool help?  

[KC Wong]

@Jean Dupree  If you read the article itself you'd have the answer.

Search for: Preview your usage in the new model

Not that the data provided is satisfactory against the tight deadline. 

[Rob Horan]

@KC Wong I believe that the option you mentioned is only available in the Cloud.  This is a fairly important consideration for customers who are looking to migrate from Server to Cloud, especially if Premium is out of their budget.

I've been trying to help a team with this recently, and as far as I can tell, the only way to get any answers is by querying the database.

https://confluence.atlassian.com/jirakb/identifying-the-number-of-automations-running-in-jira-1188398393.html

I gave this page to a team that tried to run it, but they could not get any valid information returned. This team relies on automation for various functions, and they have had many successful rule executions in the past month.

[KC Wong]

@Rob Horan Yeah, I have a client about to migrate from Server to Cloud that is in the same boat. But since the limit on automation isn't in my scope of migration, all I can do is warn them about it. 

[Rob Horan]

@KC Wong warn them how, though?  How will they know if this is going to be a problem? I assume the queries in the KB I posted can help, but people will not get the correct information back if they are not executed correctly.

I was glad someone asked about this because I had been considering asking here or in a new post about how to check Server/DC execution counts as part of migration prep.

[KC Wong]

There's also the issue of what counts towards the limit.

The query tells you the total execution count, if it is not close to the limit, you are safe for now. 

But if it is close to the limit, then most likely you will exceed the limit in Cloud too, but you cannot be sure. You may need to modify all your automation rules to keep track (e.g. call a REST API to increment a count). 

And after all these comments, Atlassian is going full ostrich mode, head-in-the-sand I-cannot-hear-you.