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. 

[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