Reasons to keep Automation for Jira with addition of ScriptRunner?

[Tim Graffam]

Hi folks,

We're planning to add ScriptRunner to our corporate Jira environment. We currently have Automation for Jira, but the general consensus seems to be "everything you can do in Automation can be done in ScriptRunner (plus more in SR)" and as a result we're considering removing Automation to save on maintenance costs.

While Automation for Jira certainly has a much lower learning curve, is there any other reason/s to consider keeping it alongside ScriptRunner?

Thanks!

[John McKiernan]

Hi Tim, 

I saw your support issue but will answer here also :)

First of all, thanks for your message and honesty also. It's a really interesting question. I will try to answer as comprehensively as possible. 

“Everything you can do in Automation for Jira can be done in Scriptrunner’

Automation for Jira can do most of the same processes but with a lot less hassle. Our focus has always been to make it easy for anyone to automate Jira. 

Scriptrunner is a powerful tool, capable of a lot and run by a good company. It can also do some complex things that can only be achieved with scripts. However, there are things that Automation for Jira can do that Scriptrunner can’t. To mention just a few:

1. In SR, there is often a bottleneck of information. It might be you that writes and maintains all the scripts. Any time a change is needed, it relies on this person. If Jira updates, you need to update all of your scripts. If that person leaves, you are in trouble / or you hire a partner to write the scripts for you, which can cost a lot. 

With Automation for Jira, rules can be created and edited by project admins (if you give permissions) and it is quick and easy to create automation rules. We take care of all Jira updates so you don’t ever need to change your rules. The learning curve is minimal and we consider our support the best in the business if there is anything you are unsure of.

2. We have service limits to protect your instance. Automation for Jira was built and still supported by a bunch of former Atlassians. Performance is something we spend a lot of time on. Same goes for security. Other apps can cause problems with things like high memrory usage, etc.  

https://confluence.atlassian.com/jirakb/known-major-problems-with-3rd-party-apps-in-jira-946618564.html

*(by the way, I don’t mean to denigrate other apps, that’s not the way we work. I’m just trying to lay out the facts for you  ) 

Recently at Jira Day in Poland, one of the Atlassian Partners actually gave a talk comparing Automation for Jira V Scriptrunner V JSD built in Automation. I think it gives a really fair, unbiased comparison. I have included a link to the video here (it’s in 3 parts). I’m sure if you reached out to them, they would be happy to offer an opinion too.

https://www.linkedin.com/feed/update/urn:li:activity:6543218553749811201/

Lastly, there is the compromise! I actually think the two apps complement each other nicely. I’m not sure whether you are aware that we have a third party integration with Scriptrunner. It means that you can build 95% of your automation rules with AFJ and if there is anything super complex needed, you can use the integration. The downside is that you need to pay for both apps.

Apologies about the long answer to your question but I hope it is comprehensive enough to help you make your decision. If you have any other questions - fire them through!

Cheers,

John 

[Chirag Harendra]

Hi Tim -

I'm Chirag, Product Marketing Lead for ScriptRunner at Adaptavist. John's points are all valid and reasonable. I don't really see us as direct competitors, many customers have both. As John said there is an integration to ScriptRunner allowing you to fill in any gaps you find in A4J.

There are a long list of differences between the two plugins, for instance we have a large library of JQL functions that requires no coding knowledge whatsoever, plus ability to extend the UI with web fragments, access to resources like external databases, a variety of calculated and other fields, changing how Jira components behave etc etc. If you are only looking at the automation side of ScriptRunner, our offering for less technical users would be AutoBlocks.

Undeniably it's true that A4J has a key advantage of delegating creation of extensions to project admins (as can AutoBlocks), which is possible as the capabilities are not unlimited as they are in ScriptRunner. Given a simple task of say, creating a subtask when some condition is met, a user without programming experience will definitely find it easier in A4J. But when requirements change such that you need to change the state of the subtask if it exists, or create 10 assigned to different users, it may be easier with ScriptRunner.

Long story short, we see these different automation solutions as mostly complementary - our focus is on improving the experience for slightly more technical users, e.g. by adding Code Insight to improve the authoring experience. We don't try to compete for users that prefer to point-and-click as that is well covered by A4J, AutoBlocks, and others.

Many of our customers have alluded to ScriptRunner being the first answer to anything custom in Jira, along with our growing collection of scripts in the Adaptavist Library, we believe we're better equipping new and existing users to maximise the true power of ScriptRunner.

Whether you need both then is up to you, I'd be more than happy to answer any further questions you may have about ScriptRunner.

Thanks,

Chirag

[brbojorque]

I prefer to use ScriptRunner but I believe it compliments with Automation for JIRA. 

For complicated stuff, we use ScriptRunner but for basic automation, we use Automation for JIRA e.g Slack integrations, cron job like feature by adding labels to a task etc.

For ScriptRunner we usually use it to manipulate Sprints / Workflows and Calculations, Behaviour is a neat feature aswell which Automation for JIRA does not have.

[jira guy]

You would probably end up spending more of your engineers time for writing complicated groovy scripts.

It used to take lot of head banging and going though community forms to get the results I needed. It has great community support though. I could do same things inside Automation for JIRA with least effort. I love the smart values. Lot easier to use. 

That said, I do have both Script runner and Automation for JIRA. But script runner is least used since we got the paid version of automation for JIRA. Script runner is just limited when it comes to out of the box automation.