Automation for Jira - OUT, what's next?

[שגיא גואטה]

We all encountered with Atlassian new automation-counter method. Instead of UNLIMITED automations for a single project, now we'll face a limit of 1700 successful executions per month for Jira no matter if it's a single or multiple project.

If you haven't met that article yet please read here

Obviously this is something most of us can't accept easily, and as a community we can work together in order to find a solution to avoid unneccessary limitations and keep our high productivity.

I think it's a nice timing to find solutions to our automation issues that this topic will occur due to Atlassian bad move.

Is there any addons that you're thinking to use due to this change? any thoughts how you'll adapt to the new situation with Atlassian Automations? :)

UPDATE: I've found a very good solution for this issue, by using an already exist addon in my Jira Instance: JMWE addon apprently have added to their tool-box an event based action, which is basically Jira automation adaption to JMWE. There's not limit using events, and if you don't have that addon it'll help you improve your workflow configurations, and also will allow you make any automation you'd like :)

[Jack Brickey]

Current thoughts....

• Rule construction and testing - create a free instance of Jira to perform all automation creation and testing before applying to your production site. I am quite liberal with my project automation rules currently. I will need to reconsider this approach now, so as not to unnecessarily impact the limit. This will be cumbersome as I will need to re-create any number of custom fields, and configurations from my various production projects.
• JSM Legacy Automation - I have been moving away from this for sometime now, and actually recommended to various clients that they do so as well. I expect that I will continue to use it more now. However, this is a risk as I fully expect that one day it will disappear altogether.
• Workflow Post Functions - any of us that have been prior to the intro of A4J are quite familiar with the use of workflow post functions. However, when A4J was introduced into the product, many of us began gravitating toward it as an alternative to post functions for a lot of obvious reasons. The recent news will certainly drive me back to using Post functions whenever possible so as not to unnecessarily draw from the automation bank account.
• Remove the slop - let's be honest here. The bigger the glass, the more will tend to fill it, The more memory we have the bigger our software programs will become.  With unlimited rules for individual projects, we could be sloppy with the creation and use of these rules. Now we will need to carefully consider using automation. As admin's, we will have to ensure that we have good justification to create a new rule. we will need to ensure that we write very specific targeted rules such that there isn't unnecessary executions. The one good bit of information on the new behavior is that only successful automations will count. That truly critical considering the new quantity limitation.
• Another nail in TMP? - If Post functions are an accepted partial solution then less TMP and more CMP will occur. Admins may wish to turn off allowing any user to create TMP since (AFAIK) any member of a TMP project  (or at least the project admin) can create Automation rules. Disclaimer - I may be incorrect here and a Jira admin may be required. I do not do much with TMP today.

....I will add more thoughts as I think of them. One thing we as a community may wish to do is to leverage a tag for posts that are focused on automation conservation, e.g. automation-conservation

[Inna S]

Manual creation of a sandbox / testbed does not look realistic to me: automation rules run is affected by fields, field values, screens, workflows, user permissions, other automation rules and data volume. Good luck recreating all these accurately.

[Gerardo Dalena]

In my humble opinion, the only way to circumvent this limitation is to abuse postfunctions whenever possibile. However, one critical thing that postfunction lacks are the if/else construct, so it won't be a complete replacement. The cheaper alternative could be to create a server that can interact with API and let edit fields as some M2M user, however there are costs related to server and development.

Another critical thing for us is the custom text in email notifications. Right now, A4J work very well compared to the barebone notification system. I don't think it would cost too much to implement these things in the basic Jira... Again, a workaround would be to use some webhook toward a server that reads the content of an issue and create a custom mail, with costs related to mail, server and development.

Just to clarify my needs, right now, we edit fields based on the content of other fields, and this is to help some users that are a bit "distracted". Removing this functionality will surely lead to confusions among certain users and less accurate reports that, for sure, will get my boss angry :) Also, mail notification is a must for a lot of people (especially seniors...) since nobody likes Jira dashboards for some reasons.

I know that there are paid extensions that could mitigate this necessity, however my company won't allow any more purchase on this ecosystem since it can no longer be trusted.

I'll keep following this thread hoping that the community can put out some new tricks :)

[Brock Jolet]

Our marketing teams are already using this. Time to see if it can support our tech departments.

[Jack Brickey]

I think we should focus this thread on solutions associated with Atlassian product and Partner offerings not replacements. The issue at hand is solving new limits on Automation. While this decision is unfortunate it isn't a deal breaker for the entire product, at least for me. I continue to be a fan of the product regardless of this decision. This thread is focused on ideas of how we might work through the decision within the Atlassian ecosystem.

just my $0.02

[Anthony Guevarra]

Would migrating all of our automation to Scriptunner be an effective workaround (dev time/costs notwithstanding)? My understanding is that SR uses the Jira API and thus wouldn't be hindered by the automation limits.

[Paul Krueger]

If that works, Atlassian will just buy them, integrate what they have into Jira automation and then we'll be back in the same mess we're already in.

[Omer Meshar]

Well, at least we will buy a few more years until they do that, and at least it will be costly for them...

[Brandon Fish]

As an admin of a 2,000 user instance that currently has 406 automations, there just is not a feasible solution with out-of-the-box tools.  If we were to proceed under the announced rules and current permission structure, I would have to immediately do the following to enact a draconian-level of control:

1. Uncheck "Allow project administrators to manage project rules" from the global automation settings page
2. Verify that team-managed project admins can not create or manage automation rules.  It is not clear from the Atlassian documentation if changing the setting affects team-managed projects.
3. If team-managed admins can still create automations: Disable Team-Managed project creation and demote every team-managed project admin in every project.  This will effectively turn team-managed projects into admin-managed projects.  Maybe somebody can test if the global setting affects team-managed projects, otherwise this could be a huge deal
4. Generate a list of all 406 automations and prioritize them the best that I can, then start optimizing the ones at the top (mine are always optimized already) and disabling the ones at the bottom.  If something can be done via workflow, it will be moved there.

 We were already using ZERO global or cross-project automations because the limit was so low regardless of how many users we have.  I basically told everyone "no" who asked.  That's what the entire automation system will be now.  Nothing new, keep minimum.

Scriptrunner could be an option, I've never used it.  I (believe) it's cheaper than moving to premium, but it's not cheap.

Another option would be some sort of external integration like with Zapier or one of the other cross-product automation solutions.  It could solve some of the simple things but won't work for some of the more complicated automations I have setup.  It will be a heavy lift for sure.

We were very fortunate that we just moved from monthly to annual billing last week (happy coincidence) so we essentially have a year to explore other platforms or bite the bullet and upgrade.  I would normally lean toward "upgrade" but I also don't like having a gun pointed at my head.

[Inna S]

Hi,

I'm a new Jira admin. 90% completed the migration from a different system (management decision). Done all the setup design myself and implemented the processes we used to have over there with Jira automations and workflows.

I believe I'm well positioned to compare and propose an alternative solution that does not use Jira automation at all.

Here is what I've built with that other system we had:

the tool webhooks + MS Power Automate (aka MS Flow) + the tool API.

That tool webhooks and API are superior to Jira's so things were easy.

Jira webhooks are not pretty because all the custom fields are 'customfield_342', and because they send all fields with no regard to the issue type, so you have hundreds of mostly irrelevant and not so friendly data. But you do have everything you need in the payload.

MS Power Automate premium license cost is about $15/month/user.

Our service user was happily running thousands of flows with no major troubles.

It is a low code platform that lets you properly program the process. Text, array, object processing functions, math and dates, native integration with the rest of the Office 365 and tons of other plugins. Run history that makes it easy to debug.

I managed without any extras. For the only missing capability I wrote a simple Azure function and that was it. 

Comparing to Jira automations, MS Power Automate is a different class. All the annoying limitations in Jira Automation do not exist there.

Obviously, they do not 'know' Jira (existing connector is very basic). So you will need to use Jira API to do things. You can create your own connector using the API definition, but this may be too much. I managed without.

It'd require a switch in the way you approach the automation, but I'd say it is worth trying.

[Sami Shaik]

This move from the Atlassian forces us to reconsider the move to the cloud. Every month, a surprise (not in the customer's favor) keeps changing our commitments to our management. 

[Omer Meshar]

Does anybody understand what are the system rules that are not counted for? Do they even exist?

[The_Contractor]

Hi Omer, 

The OP that started this thread states:

Are there any rules that won't count towards usage?

The following actions won't count towards your usage:

• System rules that support core product functionality are unmetered. We will roll out the new packaging with two system rules implemented for JSM:

  • Attaching a risk assessment form for change requests

  • Transition issue in the project on deployments

• Actions that run and only perform: log action, create variable, and create lookup table won’t count toward your usage.

Link to OP

IMO, a very limited set of rules. 

[Jack Brickey]

@Omer etal....

I encourage you to monitor this Original Announcement for any/all Atlassian feedback/info. This post here will not get the necessary attention and in fact the thread has gone sideways from the intended purpose so I plan to drop.

[Omer Meshar]

@Jack Brickey I read the announcement. Three times at least, and I still can't figure out what are system rules. Can you?

[Nena Kruljac]

"System rules that support core product functionality are unmetered. We will roll out the new packaging with two system rules implemented for JSM:

• • Attaching a risk assessment form for change requests

  • Transition issue in the project on deployments"

I guess it is something we don't have yet.

[Omer Meshar]

I guess so...

[Bobby Bailey]

Hi! I realise I am a little late to this thread, just wanted to address a couple of question here. For clarity I am a Senior Customer Success Manager with ScriptRunner.

To address what Anthony Guevarra asked, ScriptRunner for Jira Cloud does use the Jira REST API to interact with Jira. We do not enforce any limit on amount of executions of scripts, whether they be Event Based Listeners, or Scheduled Jobs, and regardless of the projects they are configured to execute on.

To answer Brandon Fish, ScriptRunner would be cheaper than moving from Standard to Premium, ScriptRunner For Jira Cloud pricing ranges from $2.50 per user for 11-100, to $0.03 per user at the 30k+ tier. You can check the pricing for your particular user tier here.

Also, just to note that ScriptRunner's flexibility and customisation is a core part of our heritage, heavily achieved with scripting over a point-and-click UI. There's a learning curve for those new to Groovy, but one that you'll be well-supported on with documentation, example scripts, webinars and beyond.

We are working on features and releases to simplify this process and make it more accessible for everyone so keep an eye out! And if you would like a demo or have any further questions about ScriptRunner and if we can help with your automation needs, please email me and my team at customersuccess@adaptavist.com and we would be more than happy to help.

Kind regards, 

Bobby

[Anthony Guevarra]

Hi @Robert Bailey we just signed an annual Standard contract with Adaptavist and are moving all of our automation over to ScriptRunner. We're a 140-user JSM shop with over 60k automation runs per month so from our perspective it's a no-brainer.

Given way Atlassian absolutely bungled the rollout of the new automation pricing, we're glad we found a fallback.

[The_Contractor]

ScriptRunner has saved my butt and my fellow independent contractors. 

Thank you for a great tool!

[Brandon Fish]

While ScriptRunner likely has the capability to perform most of the same functions as Jira Automation that is going to be a HUGE lift to convert 420 rules, especially for someone (me) not familiar with groovy syntax.  And since only Admins have the permissions to create and maintain ScriptRunner scripts, that will be an added burden.

I checked our October stats.  39,999 rule executions.  Just needed one more for an even 40k!

[Paul Krueger]

We'll certainly be looking at both ScriptRunner and the PowerAutomate options. We're running Standard with 100 users and about 10,000 automation rule executions per month. That's 2x what the default limit of 5,000 would give us. Upgrading to Premium will give us 100,000 executions, which we don't need. 

The ridiculousness of this is we're still using the same resources (it's all API calls), Atlassian is just pushing us out of their native tool to alternatives. 

[Inna S]

It looks like they have a very much inefficient design that did not bother them while the majority of the users run on-prem.

Now they pushed customers to the cloud, but their design is so much resource consuming that they struggle to keep up with their own cloud provider cost. Because AWS is not cheap at all. So they will do everything to pass the cost on to customers.

This will buy them some time, that they may use to redesign the most inefficient parts. At this point I'd be curious to read one of the famous blogs of their CEOs on this.

Just kidding, they are not _that_ open.

[Yatish Madhav]

Hi - thanks for this post and reinstating that we are a community :)

What are your/everyone's thoughts on setting rules as mulit-project where 1 of the projects is a JSM project to 'piggyback' on the larger limit? ie. had a rule that ran on a Software project. Now, to allow the counter to be off the high automation rule counter (JSM projects counter bucket), you add multi project scope for the rule and add a condition to check that the following actions are only after a 'is the original project' condition?

I am still feeling the bite of this limit and had to unfortunately upgrade to Software Premium to keep the automatons intact and avoid the rule aborts.