Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Will there be new Features in the Automation for Service Desk for Legacy Features?

Deleted user Oct 27, 2020

As i read this Article ( today, at first i was glad, that Automation would be all in one place in Service Desk Projects. But then i looked and saw that not all Features of the Legacy Automation were present in the new Automation for Jira.

Two Examples i found (there might be more) that are missing:

The Trigger for Time in Status
Right now in Service Desk Legacy Automation i can set a Trigger for a specific Time an Issue is in a Status. I didn't find an equivalent in the new Automation.

Check for Agent or Customer Role in Comments
Right now in Legacy i can react to a Comment differently if it was written by an Agent or a Customer of the Service Desk. I can react to a Comment in the new Automation, but i didn't find a way to check if the Triggering User was a Service Desk Agent or a Customer.

Since the Information in the Legacy Area tells me, Atlassian will migrate my old rules when the Legacy Automation is phased out i assume there will be new Features for the Automation otherwise it would break a lot of my Projects.

Can anyone from Atlassian comment on this?


Best Wishes



A Feature that is also missing:

The Trigger "A linked Issue was transitioned"
As far as i have seen this very important Feature is also missing from the new Automation. We use this to update Issues in Service Desk based on their linked Issues in Jira Software Projects. This is very important for us. How would i do that in the new Automation?

3 answers

Hi Michael, this is not a full answer (you can do the role check now), but I am mainly echoing both of these questions and adding one more detail.  Right now the new Automation will not handle everything that we need and the audit log needs to be searchable by issue key.

If the rules are going to be migrated, I am assuming it will handle these things, but I will list them out.

We need the following features before deprecation (there may be more that I am forgetting, but these are critical):  Time in Status trigger, Linked Issue Status trigger, and being able to edit the Request Type field

We need to have unlimited triggered rules across projects (we at least need to be able to trigger from a single project, but then take action with a linked/related issue in another project... it is really bad that that is locked down to be considered a global rule at that point).  Global rules should be things that are looking at all projects for the trigger, but single project rules should look to only that project for the trigger and then be able to take action on any project that the user setting up the rule can administer.


Then, for the auditing, it is great that you can see what happened on a particular issue in the Recent rule executions section on the full issue view screen, but then when you click on one of those links, it does not send you to the Audit Log... it just sends you to the rule details (which could have changed between execution and your investigation).  That link should bring you to that particular line in the audit log.  And/or make the audit log searchable by issue key like JSD Automation (legacy).

But, you can check the role or if it is a customer with a User Condition (top one would be your comment as the trigger example, then I just showed that you have other options for the user that you are checking too):  Screen Shot 2020-10-28 at 12.26.09 PM.pngScreen Shot 2020-10-28 at 12.27.36 PM.png

Hey Greg,

thanks for the hint about the User Condition, i didn't notice that.

I also didn't notice that we are currently not able to change the Request Type.

I hope somebody from Atlassian reacts to this soon.

Best Wishes

Yup.... I figure since a specific deprecation date is not yet set, I will wait a little before reaching out to Atlassian (and maybe someone will comment here before then).  We currently use four different methods of automation and they all have pros and cons which force us to actually need all four depending on the use-case.  Maybe this automation will eventually become the true champion.

Like Deleted user likes this

Another question in this area. As far as I know there is a limitation to the amount of triggered rules in Automations - at least that has been the case where we had installed this before this was moved to replace the old automations. We use automations hundred of times during a normal day and the old max with I think it was 1000 a month will be a HUGE problem, actually this will make our Service Desk more or less useless.

0 votes
John Atlassian Team Nov 01, 2020

Hi all,

I'm the designer for the new automation experience. Firstly, thank you for taking the time to leave your feedback, I really appreciate it. 

Let me start by explaining the goals of the recent changes to JSD automation:

  1. We combined the two automation items in the settings sidebar to reduce confusion and improve discoverability of both services. While experienced customers like yourselves may not have run into this problem it was a significant pain point for newer customers.
  2. We also want to make it clear where we will be investing in the future. Where possible please try to use the new automation experience. We are aware that the new automation experience is not at feature parity and we will continue to work on this before migrating your rules to the new experience.

We decided to make this changes now to give everyone time to learn about the new experience. Hopefully this means by the time we have feature parity and switch off the old service you won't have any problem in setting up new automations.

I'll now go through each of the specific features you have mentioned, and please let me know if I've misinterpreted anything. This is my understanding at the time of writing, this will change in the future. 

  • Time in status trigger - This is a known feature gap but is not on our immediate roadmap (however we are exploring something similar which might help). We are publicly tracking this here:
  • Edit the request type - This is a known feature gap and there is some separate work which we are waiting on before we can look into this. One issue blocking this is the availability of this in the REST API from the JSD team. We are publicly tracking the here:
    Also please note you can update the "issue type" by using the "edit issue" action.
  • A linked issue was transitioned - We have "Branch / related issue" component which should work for this. You would probably start with an "Issue transitioned" trigger and then add the branch where you can perform actions on the linked issues. 
    Screen Shot 2020-11-02 at 9.30.23 am.png


I hope that helps bring a bit more understanding to our recent changes as well as our future direction. Please let me know any other feature gaps you're worried about. We will provide more communication about changes in the future.

Oh also, don't forget to check out the Jira automation space on community for updates, tutorials and questions.


Thanks for the update. Will there be any limitations to the amount of rules triggered?

I hope you do not plan to remove legacy automation before all this stuff is fully implemented in the new Automation 

Deleted user Nov 02, 2020

@John Thanks for your Reaction.

I am using the new Automation a lot already, but about the "Linked Issue was transitioned" Feature the current Functionality of the new Automation can not really cover this.

On one hand, cross Project Rules eat up the Automation Budget for Rule Execution and would limit how often this would work.

On the other Hand there is a huge difference if i have to create this rule for every linked to Project and not only in the Service Desk Project where everything culminates.

E.G.: I have a Service Desk Project TSD and a few Development Projects A to Z
        Right now i only need to create the Rule "Linked Issue was transitioned" in the TSD Project and it reacts to Transitions in all Projects from A to Z, if there is a linked Issue that was transitioned.
        With the new Automation i would have to create a Rule in all the Projects from A to Z or a Global Rule which would trigger with every Transition in those Projects no matter if there is a linked Issue or not (which is very messy). Every Trigger would also eat up one Execution and would basically nullify this Functionality for anything but test purposes.

I hope you intend to create a similar Trigger for the new Automation, because otherwise we loose a very big Possibility for Automation with our Service Desks.

Best Wishes

P.S.: The Time in Status is also very important, especially for Service Desk Issues where it could lead to serious consequences if something is forgotten.

Hi John,

Thanks for the response and the transparency.  I think it is great that you combined the two automations in the sidebar and I can see how that would help new users (no qualms there).  And the new automation is awesome, just has some gaps right now, as you know.  I am super excited that Atlassian actually partnered with Code Barrel to bring better automation into the ecosystem and make it more stable (and we didn't even use Code Barrel before... we use other vendors and have custom scripting).

Like Michael was saying about linked issue triggers, cross-project becomes very difficult and we don't have enough automation execution budget to do what we need.  Maybe the execution limits will be removed when feature parity is reached and the legacy automation is retired?

Two other related things:

  1. Is it possible to allow watching in that Code Barrel instance?  I like to keep an eye on those (good work going on there).
  2. Do you have something in the works to allow the . shortcut to work when you are in the Automation section of a project?  As admins, we use that all of the time to navigate throughout the instance to change admin settings.  It works in the Global Automation section, just not within the project automation.
Deleted user Dec 18, 2020

@John I am just building a new Service Desk and i try to use the new Automation as much as i can. The things i found:

* There is a more accurate workaround for the Time in Status then the one mentioned in your Issue (

This would be me workaround for a Time in Status Canceled for 10 Days:

status = Canceled AND status changed to Canceled before startOfDay(-10) AND NOT status changed from Canceled after startOfDay(-10)

 The Difference is that this also checks if the Status was changed away from Canceled during this time.

* Additional to the Functionality Gap with A linked issue was transitioned that was already discussed here i also found a new Gap:

Currently it is not possible to check if a Comment was public or internal (in Service Desk Projects) for the Issue Commented Trigger.

Screenshot 2020-12-18 103945.jpg

Screenshot 2020-12-18 104035.jpg

This is important if i want to make automated Status changes based on comments, like i currently do.


Best Wishes


Hey Michael, good callout on that time in status workaround.  For the check on internal vs public comments, you need to add an advanced compare condition like this:

Checking for Public Comment.png

Deleted user Jan 07, 2021

@G Thanks for the Advice i now use the New Automation for this too.

The only Thing i now still use the Old Automation for is, when a linked Issue is Transitioned (as described above). Since i find the alternative Solution to Trigger from the Software Project to the Service Desk instead of the legacy Option very unpractical and hard to maintain.

So @John from Atlassian answered all questions accept the most important one which is " IS THERE A LIMIT TO THE NEW AUTOMATIONS AS THE LEGACY ONES DO NOT" !!!!

Hi @Kugan Gnanasegaran 

The new automation system allows for unlimited rules within a single project (the same as the legacy automation system).

The new automation system does have limits on cross projects rules, however this was not available in the legacy system. The legacy system did have a "linked issue transitioned" trigger which will be will be considered a single project rule (i.e. unlimited).

Kind regards,


@John When will this unlimited "linked issue transitioned" trigger be available in the new Automation?


Best Wishes

Hi @John thank you for getting back to me promptly. That is perfect and will put many customers at ease. Can this information be added to this link which we are being directed to from the message within the legacy automation page?


John Atlassian Team Apr 01, 2021

Hi @[deleted] ,

Thanks for your patients while I followed up on timelines. The team who are building these features are currently planning the work. I’ve asked for them to create a community post with the features they plan to build and time frames (if possible). 
Please hang tight a bit longer for them to finish planning, sorry that we haven’t had much communication since the initial announcement. We’ll try our best to make sure any future announcements hit the right balance between announcing early and providing the right level of detail.

@Kugan Gnanasegaran thanks for the suggestion! I’ve asked the team to add any updates they have to that page. 

Kind regards,


Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Service Management

JSM Jira Automation: How to Send SLA Breached Notifications

Hi Everyone, In   this tutorial,  we will show you how you can monitor an SLA, and send notifications before or after the SLA has been breached.   SLA Threshold Trigger The SLA t...

688 views 5 12
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you