Hi. I've established a simple SLA that starts when a Service Desk ticket is created and stops when we designate an Assignee to the Request based on Assignee: Changed condition. It works fine in this setup.
The problem occurs when someone clones a ticket and the Assignee field is already populated, so the Assignee field doesn't change per se. I also create automated sub-tasks which grabs a username from another field in the form and populates the Assignee field with it.
Ideally, I'd like to base the SLA simply around the Assignee field not being empty but this condition doesn't appear in the SLA criteria to select. I have Project Admin only, not system. Is there a way to do this in JQL?
Community moderators have prevented the ability to post new answers.
Hello @Richard Imbrogno
Yes you can add JQL to SLA, under goals just add a new rule
What this does is start SLA only if Assigne is unassigned.
All remaining issues no target means, that SLA won't be set/start on those issues.
BR, Olga
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Does adding the option "Assignee: From Unassigned" to the Stop criteria do anything?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Liam. It didn't unfortunately. I think because there's no real 'change' in the field this is the challenge as the change happens instantaneously.
Just thought about something that will fix this in the interim. I will add an additional label on the automated subtasks and I'll exclude that label from the SLA counter.
As for the manual cloning of tickets it's one team member whose tickets are auto-assigned anyways so the SLA trigger is not needed for his tickets to begin with.
I think I have my workaround but would be good if there's a system-based solution that addresses this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sounds like the workarounds are a good interim, which is great.
We have similar challenges in our own instance, so hopefully Atlassian will beef up SLAs in the future
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just an update. This work around is good with the auto-subtask creation but does not work with the cloned tickets at this point. For those who are using the Clone process I've asked them to manually add the same label as above to those specific requests and that has allowed me to bypass the SLA as a result. Kind of a hack-job but it'll work for now :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Get the most out of Jira Service Management
Solve customer problems efficiently and deliver outstanding service experiences.
Learning Path
Adopt ITSM practices to deliver exceptional service
Become familiar with the principles and practices that drive ITSM. Then, learn how to configure and use Jira Service Management to implement them.
Atlassian Certified Associate
Jira Service Management Agent Essentials certification
Prove you know what's essential to providing efficient and resolution-focused service in Jira Service Management.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.