You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Sometimes, it is necessary to use the department or location the user belongs to in JQL filters. Natively this option is not available in Jira even if this value is present in the user's profile.
The details like Department, job title, organization etc, that are shown on an Atlassian account's profile or that are synced from the IDP are not available to be used as a field in Jira. There is a feature request suggesting the implementation of this ability:
The option presented below could be a workaround which would be useful to populate a custom field based on the subdomain present in the user's email.
The following are pre-requisites for this to be a success:
The smart value to get the domain part of the email address is "reporter.emailaddress.split("@").last"
As shown below, I was able to get a custom field called 'Dept' populated with the value based on the reporter domain. Here, the custom field Dept was of type Text field.
The rule runs when a new issue is created or when the reporter field changes and the field Dept is not populated with a value as shown below:
We can now use the field Dept in a JQL query - for example to get a list of tickets created where the Dept is set to Location 2 as seen below:
Note - 1:
The trigger used in my example above is Field Value changed. As per the documentation, this includes any changes to the field value (Value added, value deleted or any changes to the field value) due to any of the actions as highlighted in the screenshot below.
So the value of the reporter changing/being set when the ticket is created would also be included in this trigger.
Note - 2:
If there are many if/else clauses to check, a lookup table could also be created for this purpose, thus also simplifying the automation rule, but that is out of scope of this article :)
Including the documentation for that below:
Cloud Support Engineer