Auto-assign Jira issues by custom field, with a fallback?

Question

I’m on Jira Cloud and trying to set up an automation rule that assigns new issues based on the value of a custom field (a single-select called “Team”). Each option should map to a different assignee.

I’d also like it to fall back to the project lead when the field is empty, so nothing ends up unassigned. Right now I have a rule with a few separate conditions, but it’s getting messy and I’m not sure it’s the right approach.

Is there a cleaner way to do this in one rule, for example with if/else blocks or smart values? Or is it better to split it into separate rules per team? Any examples of how you’ve set this up would help.

Josh · Answer

Hi @James Arthur, you can do this in one rule, and the cleanest way is a lookup table rather than one If block per team.

* Trigger: Work item created. Add Re-fetch work item data right after it so the Team value is definitely loaded.
* Action: Create lookup table. Name it teamOwner. Each key is a Team option, spelled exactly as in the field. Each value is that person's account ID (not the display name).
* If/else block:* If: Advanced compare condition, first value {{teamOwner.get(issue.customfield_XXXXX.value)}}, condition "does not equal", second value left empty.*      Then: Assign work item, choose Smart value, {{teamOwner.get(issue.customfield_XXXXX.value)}}* Else: Assign work item, Smart value {{project.lead.accountId}}

* The Else branch covers both an empty field and a new option nobody has added to the table yet, so nothing ends up unassigned.

* Two gotchas:
* - Use the field ID (`customfield_XXXXX`) rather than issue.Team. Jira Cloud also has the built-in Atlassian "Team" field, and a custom field with the same name can resolve to the wrong one.
* - Lookup keys must be text and are case-sensitive. That applies to the table name in .get() too.

* When the team mapping changes, you edit one table instead of N conditions. If each team really maps to one owner and you don't need the fallback logic, Components with a component lead (as Matthew said) is the zero-automation option.

Matthew Sinclair · Answer

I would suggest employing Components before you engage automation to do this based on a custom field.

https://support.atlassian.com/jira-software-cloud/docs/what-are-jira-components/

Components can have a owner and autoassign when employed - theirs also a hierarchy if there's a default assignee and other aspects.

Also if you need a teams field to use as an identity/group without employing a custom field you can look into this:

https://support.atlassian.com/platform-experiences/docs/what-is-the-teams-app/

Keep in mind its basically a "group" designation - not necessarily assignment - but it could help. (Although you can bind a team to a group in the Org Admin level but that takes away the openness of access/management)

If you end up employing automation as you initially want - you can use IF/Else nodes that compare results to a custom field value - but be warned - depending on your frequency of traffic you should be aware of steps consumed as you will be metered when the new usage rules take effect in December.

See if Components help narrow your scope for automation rules/needs and go from there.