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; } } }

Allow manual ticket re-assignment after automation rule

John Smith_rynu9e

Hi all, I currently have automation rules in place that assign tickets to users based on certain ticket criteria. I have things built to use the triggers "Work item is created" and "Work item is updated". I use the trigger "Work item is updated" so that they can quickly correct certain fields and the system will auto assign as needed. However, I am trying to come up with a way to allow my Agents to be able to manually re-assign these tickets to other users on their team without the auto-assignment rule kicking in again and assigning the ticket back to the original user.

Is there a way to accomplish this? Or will I need to remove the "Work item is updated" trigger from my rule?

Accepted answers

All comments

Bill Sheboy

Hi @John Smith -- Welcome to the Atlassian Community!

Without seeing your rule and all the assignment criteria involved...

One way to solve this would be to capture who assigned the work item in a custom field (with an automation rule). Then your rule triggered on other field updates could check if the "assigner" was not an agent before proceeding to re-assignment checks.

Kind regards,
Bill

John Smith_rynu9e

Thanks Bill. Attached is an example of this rule.

Can you help explain how your suggestion would be built?

Bill Sheboy

Ah, your rule is using the generic Work Item Updated trigger...

Let's start with the {{initiator}} smart value is the user who performed the action which triggered a rule. And, work item assignment is a different event than updating, and so that would use a different rule trigger than an update.

So for the update, you could check the {{initiator}}, or the "User who triggered the event" with a condition to check if they are one of your agents with a User Condition. I recommend mapping out the logic to decide how to handle the cases, for example:

when a non-agent updates / creates the work item, try to set the assignee
when an agent updates / creates the work item, and the assignee is empty, continue to try to set the assignee
when an agent updates / creates the work item, and the assignee is not empty, do not proceed

For assignment, another rule specifically triggering on that could check if someone other than an agent tampers with the field, perhaps setting it back to the previous value using the changelog smart values.

Finally, as your rule could be triggered on updated or created, I recommend adding the Re-fetch Work Item Data action immediately after the trigger. That will mitigate any racetrack timing errors from the create not getting the data fast enough for the condition tests.

John Smith_rynu9e

Thanks for this Bill. I'm having a hard time visualizing this without being able to see it from the Automation screen. Would you mind providing an example screenshot of how this might look from a creation standpoint within Jira?

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management