nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

unknown

As i read this Article (https://support.atlassian.com/jira-service-desk-cloud/docs/what-is-legacy-automation/) 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?

Thanks

Best Wishes
Michael

---

Edit:

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?

Accepted answers

All comments

Kent_h68i7i

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.

Greg D

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.png

unknown

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
Michael

Greg D

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.

JD_sjez00

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:

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.
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: https://codebarrel.atlassian.net/browse/AUT-1244
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: https://codebarrel.atlassian.net/browse/AUT-1750
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.

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. https://community.atlassian.com/t5/Jira-Automation/ct-p/automation

Thanks,
John

Kent_h68i7i

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

Marco_1rbs8k

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

unknown

@JD 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
Michael

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-desk

jira-service-desk-cloud

automation