Allow manual ticket re-assignment after automation rule

[John Smith]

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?

[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]

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]

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?

[Bill Sheboy]

Hi @John Smith 

As I do not know all of your cases, or how you want to handle each one, me creating a rule may not help as much.  I recommend building a test rule with a Work Item Created trigger, and adding the User Condition to test the scenarios, perhaps writing to the log to confirm the results.

For example, if you assume a create will only update the assignee for ones not created by agents:

• trigger: work item created
• action: re-fetch work item data
• user condition: user who triggered the event is not [add your agents]
  • This one could also test with a User Group if you have one for agents
• action: write to the log -- This will try to assign

Then use test work items to verify the behavior needed.  If the logic is more complex, use an if / else block for the different situations.

And for your "Existing Tool" field, if there is a one-to-one match between values and assignees, you could use a Lookup Table to simplify the logic for assignments.

[John Smith]

Thanks Bill. Admittedly, a lot of what you are sharing is going over my head. Would this be a brand new rule? Or an edit to an existing rule?

[Bill Sheboy]

It would be a new rule to test it...and what you describe seems to confirm why using a test rule would help.  By creating it, you will learn what is possible and how to adjust the conditions for your needs.  I would start with the simple test rule, and ignore the part about the lookup table for now.

[John Smith]

When attempting to build a test rule, I believe I am getting as far as your last suggestion of "write to the log". The only option I see from the Automation screen is to "Log Action" which, to my understanding only writes the action being made to the audit log. Is there another action I should be looking for?

Attached is just a mock up as an example. To make sure I am following what you're suggesting so far and trying to understand this step by step. 

[Bill Sheboy]

That is a good start, and...

I recommend not adding conditions directly to the trigger, and instead add the conditions after the Re-fetch Work Item Data action.  (The new feature to add conditions directly to triggers can have timing problems, causing side-effects.)

For the "Add value to the audit log", this is to confirm the behavior is as expected by writing fields / smart values or just a text message.  It helps diagnose rule problems.  After the rule runs, look at the audit log to observe what happened, and then make rule adjustments.

[John Smith]

Ah ok, got it. Thank you. I noticed that feature was available recently but have not tried it yet in any of my rules. 

Ok so, if I am following correctly. I should add an IF statement after the Trigger that checks that the initiator is not a customer. Instead of having it included in the trigger itself. Then follow by keeping the Re-fetch action. And finish with the log action. 

Am i on the right track still? 

• Trigger - Work item is updated
• If - Initiator is not a customer
• Action - Re-fetch work item data

From here, how would I prevent the ticket from being reassigned back to the original assignee, if my primary rule is set to assign certain fields to certain agents?

[Bill Sheboy]

If I understand your question...Let's say we are using conditions to decide if we should assign a work item to "Bill".  I could add an additional condition so it does not assign when it is already assigned to that person:

• ...
• if / else block
  • some conditions to decide to assign to "Bill"
  • user condition: assignee is not "Bill"
  • action: assign to "Bill"
• else / if 
  • more conditions to decide assigning to someone else
  • ...

If instead you mean preventing assignment to whomever it was ever assigned to in the past, that is quite difficult and requires using the REST API to check the changelog...and may indeed not be possible with a rule.