Setup an automation to auto assign Jira work items depending on a custom field

[Mireya Cintora]

Hi! So just like the questions states, I would like to make an automation that:

If [custom field] is Client A, then assign the work item to [assignee] John Smith.

Current Process

Due to our limited knowledge on using Rovo, JSON and advanced skills, we essentially created an automation that is simple but not long term efficient. Meaning when there is a shift of assignments in our company, we have to manually update each component. On top of hitting our max component limit of 65 has been reached so we had to create a duplicate of this automation.... it is terrible. 

Context

Note that we have both an onshore and offshore team. Mean if Client A, then certain work items will be assigned to onshore, while the rest of the work items will be assigned to the offshore rep. 

Ideas

With all the new updates Jira has come out with, I feel like there has to be a much better way of dealing with this. Below are some ideas that I have thought of

• Rovo
  • Create a page or database, with all assignments
  • Integrate Rovo into an automation? Really not sure how to since I heard this via a Rovo webinar
• Groups
  • I have created a group per client, but unfortunately the groups I cannot assign different roles i.e. onshore vs offshore
• Teams
  • Same issue as above

Honestly, any feedback or ideas I am willing to try since our client list is increasing each month and our current process is no longer efficient.

[Trudy Claspill]

Hello @Mireya Cintora 

What type of field is the custom field you are evaluating? Looking at your image of your rule it seems like your custom field might be "Facility" and it might be some sort of selection list, but is it a single-select field or a multiple-select field? Or is it a Labels field, or the Components field?

You said that issues for a given client might have different assignees based on this custom field.

- Do all clients have the same set of values for the custom field, or does each client have their own set of values for the field?
- Do you have a method that you are first identifying the client for each issue, and then the possible values for the custom field?
- How many values do you have for your custom field currently that need to correspond to different Assignees?
- If you have values per client, what is the maximum number of values you would have for any single client?

Depending on the answers to the above, there may be a more efficient way to build your rule than the IF component you have shown.

Is setting the assignee the only thing this rule does?

Can you provide screen images (or a scrollable image) showing the entire rule? 

I ask the above two questions because I'm not clear on the logic of your rule. You have a branch for "For most recently created work item". If your rule trigger is "Work Item Created" then there should not be a need for branching, and that would eliminate some rule components.

[Mireya Cintora]

Sorry it wouldnt let me post so I took a screenshot of my response:

[Trudy Claspill]

Hello @Mireya Cintora 

In your above reply you said:

"I just created a global cascading field to replace the Facility field"

A cascading field means you have have multiple levels:

1
|-- 1.1
|-- 1.2
2
|-- 2.1
|-- 2.2

What will those levels represent? Is the top level a Client, and the child level the Facilities for a Client?

In your clarification you did not say anything about associating Reps to Clients. Is all that association done only at the Facilities level?

Can you provide some samples of the values for the cascading field, their use in Epics and Child issues, and example Onshore and Offshore Reps that would be assigned in each case?

I will make a disclaimer at this point. I have no experience with Rovo, so cannot offer any advice on whether or not it has the capabilities to create a solution for your scenario. The only advice I can offer would be around the use of Automation Rules and other features like customizing Workflows.

[Mireya Cintora]

The way the cascading field works is:

1. Client A Name

1.1 Location 1

1.2 Location 2

Correct, who ever the Client is, the levels do not matter, is what will associate to the correct rep. 

Epic

• Facility: Client A - Location 2 (Levels will not be taking into consideration for who it is assigned to)
• Assignee: Onshore Rep A

Child

• Facility: Client A - Location 2 
• Assignee: Offshore Rep A
• If this child work item transitions to a Denied status, work item will be re-assigned to Onshore Rep A for further escalation

It is ok, I am willing to try anything. I just mentioned Rovo since it was mentioned on the webinar.

[Trudy Claspill]

Thank you for that additional information. That is helpful. I have additional questions.

1. Will multiple Clients have any identical facility names? Can Client A and Client B both have facilities with the same name but different Onshore and Offshore Reps? If Client A has a facility named Location 2 and Client B has a facility identically named Location 2, would those locations have the same Onshore and Offshore Reps?

2. How many Facilities do you have?

3. How many Onshore Reps do you have?

4. How many Offshore Reps do you have?

5. When do you want the Assignee field to be filled in; i.e. any time the cascading field is changed?

Depending on the answers to the above, you might be able to use a Lookup Table in an Automation rule to lookup the value of the cascading field and get the associated Onshore Rep, with a second table to lookup the value of the cascading field and get the associated Offshore Rep. That rule could be triggered by a change in the cascading field value. You could also imbed logic (an If-Else block) to choose the lookup to use based on the issue type, or make two rules - one for Epics and one for non-Epics.

If you needed to update existing issues because the people associated to the Facilities changed, that could be done with a second, scheduled rule, but you would have to duplicate the Lookup Tables you created in the other rule, updating the tables in all relevant rules each time the associations changed.

Another solution to consider would be leveraging a third party app like ScriptRunner. With something like that you could create a script that would look at the Facility value, look at a table within the code that has the associations, and set the Assignee. That would avoid the limitations on Automation rules regarding component counts and Lookup Table entry limits.

Here's another option.

You flagged your post as applicable to Jira Service Management so you have access to Assets. You could create an Asset Schema to define your Facilities, adding a field for the associated Onshore Rep and Offshore Rep. In your issues you would use an Asset Custom Field instead of a Cascading field, and you would select the Facility from the Assets. You could use an Automation rule to get the Onshore and Offshore reps defined for the Facility asset, and set the Assignee field accordingly. 

[Mireya Cintora]

Can you walk me thru creating a LookUp table?

[Trudy Claspill]

Did you review the documentation for a Lookup Table?

Be advised that a Lookup table is limited to 20 entries. if you have more combinations of Facilities and people than that, the Lookup Table solution is not your best option.

[Bill Sheboy]

Hi @Trudy Claspill 

Lookup Tables can handle up to 200 rows since the last round of updates.  The UX conceals that a bit when they added paging to add more.

https://community.atlassian.com/forums/Automation-articles/Update-Create-lookup-table-action-improvements/ba-p/2427798

Kind regards,
Bill

[Trudy Claspill]

Thank you, @Bill Sheboy !! 

I did not try adding the action to a rule myself. I pulled "20" from the image that is currently shown in the documentation.

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Create-lookup-table

[Mireya Cintora]

If its the 200 entries that is perfect! How can i get started by using the assignee as a smart value?

[Trudy Claspill]

Hello @Mireya Cintora 

I want to revisit the requirements to make sure I understand them correctly.

1. You have a Cascading field that has two levels - Client > Facility

2. You want to set the Assignee based on the value in the Cascading field.

3. You are dealing with Epics and child issues.

Question 1: Are you wanting to automate the setting of Assignee for both the Epic and its child issues?

Question 2: Do the child issues also include the Cascading field?

Question 3: If so, does the field in the child issue automatically get the same value as the parent Epic? 

Question 4: If the answer to 3 is "yes", is there automation that keeps Cascading field value synchronized between an Epic and all its children?

4. Onshore Rep is assigned X facilities.

Question 5: Are the facilities assigned to an Onshore Rep associated with only 1 client, or may they be facilities from different clients?

Question 6: Can there be more than one Onshore Rep for a given Client with each Onshore Rep being responsible for a subset of the Client's Facilities?

5. Onshore Rep has some number of subordinate Offshore Reps, each one assigned to some number of facilities that are assigned to the Onshore Rep.

Question 7: Do Offshore Reps get only 1 facility or might they have more?

Question 8: Do Offshore Reps ever get associated to more than one Onshore Rep?

6. Only Onshore Reps are assigned to Epics.

7. The Onshore Rep assigned to an Epic is based on only (?) the Client portion of the Cascading field. (See Question 6)

8. Child issues are assigned to Offshore Reps, primarily, but may get assigned back to the Assignee of the parent Epic in specific circumstances.

Question 9: Is the setting of the Child issue Assignee based on the Cascading value in the child issue, or the Cascading field value in the Epic, or a combination of the Onshore Rep assigned to the Epic and the Cascading field?

Other things that need to be considered:

a. What events should trigger the setting of the Assignee field?

Issue creation

Update of the Cascading field (in the parent and/or the child)

Update of the Assignee in the parent

Removing a child from an Epic

Adding a pre-existing issue to an Epic

b. If the Cascading field is in both the Parent and Child issue what happens if the values are out of synch?

c. Do you ever "promote" a child issue so that it becomes an Epic? Do you ever "demote" an Epic so it becomes a child issue?

The scenario can become quite complex depending on the answers to the above questions and could require multiple rules.

The creation of the Lookup Table will depend on the Trigger event for the rule(s) and for which issue the event occurred. Some data will have to be pulled from that trigger issue, or maybe its parent when the trigger issue is a child, and used to compare to the keys in the table to find the right value in the table to push into the Assignee field.

I actually think it might be easier to set this up using Assets, and build the automation off Assets rather than a Cascading field and Lookup Tables.

[Joseph Chung Yin]

@Mireya Cintora 

I agreed with @Trudy Claspill asks.  Once we obtained more clarifications from your end, we will be in a better place to offer our suggestions on your issue on hand.

Looking forward in your replies.

Best, Joseph Chung Yin