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?
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?
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.
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):
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.
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 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.
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
@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.
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.
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:
@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 (https://codebarrel.atlassian.net/browse/AUT-1244)
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.
This is important if i want to make automated Status changes based on comments, like i currently do.
@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.
We often have questions from folks using Jira Service Management about the benefits to using Premium. Check out this video to learn how you can unlock even more value in our Premium plan. &nb...
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