Automation to assign ticket to manager

[ayoung]

I am tasked with creating an automation for an Agent Coaching Jira Boarding I am creating. I have chosen to use Jira work management for this as management need a high amount of automation written for this board to reduce workload and a simple list view that is sortable to be used by the business. 

Requirements:

• Agents are not notified of ticket creation
• Team Leads are assigned the ticket on creation based on agents name picked on form. 
• When agents name is selected from a dropdown field THEN assign to that agents Team Lead

I thought maybe a look up table would do the trick but I have not experimented with them yet, and I don't want to over engineer this if there is already a functionality that exists to populate an assignee based on the value in another field in automation. 

Company has 1500 Jira users so an add on license for this is not an option due to the cost of doing so, as only 20 users will use this functionality. 

Is this possible? If so what is the most effective way to make this happen?

---

When value is selected in red box - blue box is automatically populated. 

Sample of what a lookup table structure could look like if that is possible to use for updating an assignee field. With Key populating the drop down on Agent Requiring Coaching and Value populating Assignee field: 

[Bill Sheboy · Accepted solution]

Hi @ayoung 

From what you describe, it seems there is a mapping of many-to-one for:

Agent Requiring Coaching -> Agents Team Lead 

Perhaps try the Lookup Table first, although that has a limit of 200 rows.  Do you have more than 200 Agents or Team Leads?

For some ideas on using Lookup Tables, please see these two articles:

• https://community.atlassian.com/t5/Automation-articles/New-Automation-action-Create-lookup-table/ba-p/2311333
• https://community.atlassian.com/t5/Automation-articles/Update-Create-lookup-table-action-improvements/ba-p/2427798

Kind regards,
Bill

[ayoung]

Hey Bill thanks for the reply. I have been messing with this for about a half a day based on your reply, somehow I cannot seem to get what I am looking for out of this. 

The drop down list for the Agents Name is: customfield_11772

(I assume it will not populate from a drop down list from the keys in the lookup table and I must create my own drop down list by hand typing in all the same names as I have in my lookup table) not even sure if that is right? 

I simplified the lookup table name to just Agents. 

Then in the automation,  I am using the following to try to map the value I choose in field 11772 to the assignee from the lookup table beside that value.  

Then added this edit field edit line of code trying to follow the line from the article you posted:

{{example.get(issue.assignee)}}

But it leaves assignee as unassigned on the ticket.   

{
"fields": {
"assignee": "agents.get("customfield_11772")"
}
}

End result should be:  Kate Canejo should be the assignee, As I chose Nadim Hawa from the drop down list.  Not sure what else to do with this but running out of time to fix it also.... 

[Bill Sheboy]

When doing things in Jira Cloud automation rules with user fields, the account ID value must be used to set a field.  You tried using the display names, which would not work directly.  (Please see the end of my long post for more info on searching by display names.)

Here are some suggested adjustments to help...

• I recommend naming things like tables and variables so they cannot collide with fields or smart values, possibly causing errors.  For example, always add the prefix of table to lookup tables, such as with tableAgentToLead, and var to variables, such as varAgent
• For your table, its keys should be the account ID of the agent and the value the account ID of the Lead
  • One way to find those account ID values is using JQL, by typing in this...
    • assignee IN (type in user name)
    • Jira will replace it with the account ID value that you can use in the rule; it will look like this: 557058:d4494c78-f68a-4cac-8470-7cf6d2f491a1
• Your customfield_11772 is a user-select field, and to get the selected value's account ID for the lookup table use, try {{issue.customfield_11772.value.accountID}}
• Putting that all together, your rule does not need to use the JSON edit.  Instead, using the Assign Issue action, select Smart Value from the list, and enter the smart value in the next field:

{{tableAgentToLead.get(issue.customfield_11772.value.accountID)}}

Please try those adjustments, and if you run into problems, please post images of your complete rule and the audit log details, and describe the symptom.

If you still want to use the display names of the users in the table, that is possible, but will require an extra step before the assignment to call the REST API to find the user by their display name.  If you want to try that, please review this how-to article and REST API function:

https://community.atlassian.com/t5/Jira-Software-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828

https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-user-search/#api-rest-api-3-user-search-query-get

[ayoung]

Hi Bill, 

Thanks so much for this thorough response. The Jira user ID lookup for the Assignee makes perfect sense.  Figured out how to get those ID's and mapped them to a table on my end and tested them by using them in a Jira filter and it swaps it for the user name when pasted so I know I have that part down.

The technical issue currently is half our customer support team agents in the drop down are contracted and not in our Jira system to look them up.  So I have to stick with Text Values for their names. I prefer a drop down, vs text field, to ensure no one typos a name and breaks the look up table value (hoping that is possible) 

I ran a few tests today which say "success" but they did not actually update the assignee. Pasting some screenshots below: 

Look up field on ticket: 

Full Rule Screenshot: 

Create Lookup Table (used just one row for simplicity of testing) 

Edit Issue Field (Assignee): 

Smart value: 

{{tableAgentToTL.get(issue.customfield_11772.value)}}

I also tried (same result, success but didn't populate the field): 

{{tableAgentToTL.get(issue.customfield_11772)}}

Audit Log of Success: 

I attempted to add an audit log of :

Initial value - {{fieldChange.fromstring}} Modified value - {{fieldChange.tostring}}

 to see if I could capture what it "thinks" it is doing to the assignee field but as you can see it showed up blank in the Action Details - Log Action section, so that may not work for this class of field change.

Assignee Field Results (Should populate me as a user): 

Thanks for your help on this Bill, I am hoping this is some silly mistake I have made and not something that simply cannot be done. 

[Bill Sheboy]

First thing: well done experimenting to get it to work!

Some adjustments and I believe you will have it done...

Your table now contains the Agent user's displayName for the key and Lead user's accountId as the value.  To find the lead for an agent, try this:

{{tableAgentToTL.get(issue.customfield_11772.value.displayName)}}

User fields have lots of attributes like this.  Please look here to learn what else is available for those fields: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-users/

Is your Agent a required field?  If not, what do you do if the field is empty at issue create, or changed later?

And FYI: your rule trigger is Issue Created, and so the changelog and fieldChange smart values have no values as they apply when issues are updated.  Please remove using those in this rule.

[ayoung]

Your table now contains the Agent user's displayName for the key and Lead user's accountId as the value.  To find the lead for an agent, try this:

{{tableAgentToTL.get(issue.customfield_11772.value.displayName)}}

---

The Agent Name field type is: Dropdown actually. Since of the 150 total agents, 65 are contracted from other companies, I could not use the people (user) option. Our contracted agents could not be selected using the "people" field type, because they do not have Jira licenses with us.. So its just plain old text in a drop down list - could be vegetables or colors even. Just happens to be peoples names for the Key, so I can understand the confusion there, that I was using a user type field. 

Is your Agent a required field?  If not, what do you do if the field is empty at issue create, or changed later?

---

Great call out. Yes, once this goes live that field will be a required field. Required fields is just one of the last steps I do so its easier to create test tickets without having to fill out everything.  I'll duplicate this rule if I get it going so that it also works on issue update if they change that agent name.

And FYI: your rule trigger is Issue Created, and so the changelog and fieldChange smart values have no values as they apply when issues are updated.  Please remove using those in this rule.

---

Done! Thanks for the clarity!

[Bill Sheboy]

If the custom field is just a dropdown list of text values, then .value should work as the parameter in the lookup...as long as they exactly match:

{{tableAgentToTL.get(issue.customfield_11772.value)}}

[ayoung]

Thanks Bill. That is what I was trying this morning in the sample above, that says success but does not change the assignee. Going to play with this a bit more then give up the ghost on this. 

I have just been testing outputting the lookup table value in a custom text field instead of trying to set the assignee, to see if it will give me"712020:ae259ba6-85e8-43b5-9575-9b8b0f3486a1" as my value,  and even that shows blank instead of having any value.  

So strange!  I really appreciate your time & efforts here :) Thanks so much!  Sometimes I try to make automation in Jira do way more than it was ever intended to haha 

[Bill Sheboy]

Oops...I just noticed you are using the Issue Created trigger, correct?

It is possible for that trigger to fire so quickly that some data is not yet available to the rule, leading to unexpected results and occasionally rule errors.

The fix is to always add the Re-fetch Issue action immediately after the Issue Created trigger.  This will slow down the rule a bit by reloading the data before the other steps proceed.  Please try adding that and re-test.

[ayoung]

Thank you so much Bill for sticking with it - I had given up! 

It was 2 things. 

1. My table was called  TableAgentToTL and I was using a get command on tableAgentToTL with a lower case t.  The table names are case sensitive, never spotted my error originally as this does not produce any kind of audit log error and just says success vs. table does not exist or something.

2. The re-fetch was the final step needed to slow it down enough to get the data out of the table. 

Thank you thank you!