It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

JIRA: Is it possible to set issue assignee based on "Issue Type" automatically?

Gavin Fowler Oct 17, 2011

I have a need to set the issue assignee automatically based on the "issue type" selected (i.e. out of box: new feature, bug, etc). I know this is possible through the use of components, but i really need to make determination based on issue type rather than component selection.

Let me explain further....

I have many jira projects (60+), where the use of components is widely accepted by my user community. However, for one project I'm attempting to use JIRA as a small service/helpdesk solution. Within this project, i have created a suite of new issue types like: "Faulty Printer", "Faulty Laptop", "Faulty Application". When a specific issue type selected, I show different different custom fields during the create issue process. This allows me to display specific fields for issue type. For example, I an issue type "Faulty Printer" is selected, I only show custom fields related to printers (i.e. a drop down list showing printer fault types). This all works very well and the users are pleased with the user interface.These users do not see components at the point of entry.

The one issue I'd like to resolve is how can i automatically assign the issue to a dedicated resource name i.e. "Bob Hope" when the issue type is "Faulty Printer".

I guess an alternative would be to automatically set a component "printer" (in order to leverage the auto assign feature of components) when a issue type is "Faulty Printer". I hope this makes sense??

I currently have the "JIRA Misc Workflow Extensions" and "JIRA Suite Utilities" plugins installed but as far as I understand that neither of these plugins support automatic assignee based on issue type.

does anyone have a method to do this? supported /free plugin would be preferable as i do not have budget.



7 answers

1 accepted

20 votes
Answer accepted
Justin Rand Nov 07, 2011

JIRA can do this for you straight out of the box!

Create separate workflows for each issueType. Create a workflow scheme for your project mapping those workflows to the specific issueTypes. Then (in the workflows) using the stock post function "Update Issue Field", set your Assignee field to the desired user for each individual issue type in the "Create" transition.

3 things to note: 1.) To get to the "Create" transition, click on the "Open" step and "Create" should be one of the Incoming Transitions. 2.) When adding the post function, be sure to place it after the "creates issue originally" function or you will get some nasty errors. 3.) Be sure to delete the post function "Assign the issue to the reporter" otherwise your issue will get re-routed to the reporter.

Srini Srini Nov 07, 2011

This will be the quick and straight forward option and will work if you know who the issue has to be assigned to. If the user has to be changed later you just have to update the workflow.

This is the pretty simple solution.


Paul Goodsell May 21, 2013

This fix works great elsewhere in my workflow but when I place it on the transition between 'Create' and 'Open' it tricks the transition from 'Open' to 'Allocated' into thinking that the issue has already been assigned. Thus, it misses a state. Does that make sense? Anybody know a fix?

randy zhu Jul 30, 2013

In 5.x, when adding this post function it must come before "Creates the issue originally".

Network Operations Aug 08, 2014

For versions of Jira with "Agile simplified workflow" enabled, this is not an option. Jira handles the workflow and you are "forbidden" from tweaking it in manners described here. Which sucks, because this is exactly what I have.

End result is that I have to recreate my project/board/workflows from scratch to be able to do this.

Vs. "these issue types go to this user" capabilities. Progress? Of a sort I guess.

Sooxin Sep 18, 2018

Agree with @randy zhu. For version 7.10, it works when post-function is before "Creates the issue originally".

1 vote
Sander Brienen Nov 07, 2011
We always advise to minimize the use of plugins as much as possible. If it can be done with out of the box content, then choose that solution. Plugins will once get in your way when wanting to upgrade to a newer version of the product. That is the reason I voted up the third answer. I think it is a better solution.
Mark Bednarski Apr 04, 2013

I know this is an old post. But I was right now looking for a solution as I have the exact same problem. I will try to use Script Runner plugin as I need this for many other things as well.

The general recommendation seems to be to use different workflows. But this is producing a huge overhead if you want to change your workflow and you have to do the very same change on multiple places again and again.

David Skreiner Oct 19, 2016

LOL, difficult. I totally agree on your "use as few plugins as possible" stance for financial and security reasons. Unfortunately Answers makes it look like Atlassian would disagree:

Many users here on Answers are plugin developers who are mainly out to make a quick sale. I've seen questions on here where an easy workaround without plugins exists ... but no one said so, instead they offered two different commercial plugins. 

This is very harmful to Atlassian's reputation in my view – even in the JIRA Admin course I took years ago, I was warned about missing features and glaring bugs which require expensive addons to fix, about users requesting stuff that I won't be able to implement without spending a lot of money, and the guy even ranted about how Atlassian never fix problems if there's a paid addon that they can sell instead. While that trainer was obviously frustrated and exaggerated a lot, I quickly got to understand how he got that impression.

1 vote
Peter Milakovich Aug 25, 2013

There's a ticket open since 2004 that may eventually address this:

Shane Day Nov 05, 2014

Well, it should be addressed sometime this millennium.

David Skreiner Oct 19, 2016

Since only 170 people voted for the feature, it'll never be implemented. They closed that 2004 issue as a dup now, instead pointing to an issue from 2008. The new one has less than thirty votes.

(Some of the more popular issues have Thousands of votes ... Not sure if these might be faked by someone telling all his colleagues to vote for a feature, or other unfair methods.)

0 votes
Jobin Kuruvilla [Go2Group] Community Leader Oct 17, 2011

You can write a JIRA Listener that does the same.

Gavin Fowler Oct 17, 2011

Thanks for the quick reply Jobin! I'm not really a developer, do you know of any good resources where i can view custom listeners in JIRA 4.0 (preferably with examples)?

Gavin Fowler Oct 17, 2011

Many thanks! It will take me some time to absorbe this information, but it's defintily the runnign start i needed. perfect!! appreciate the support :)

0 votes
Samuele Pretini Oct 17, 2011

I thinks that you can create a Workflow post-function instead.

I have created a similar post-function for set the Estimate Time based on Issue type. You can, in the same manner, do your work.

Really you have to develop your own post-function, package it and install as plug-in in Jira, but all is very simple. You can read the documentation about developing the custom plug-in.



Gavin Fowler Oct 17, 2011

Many thanks - i'll look into plugin creation (dust of that old developer hat). Any advice on quality resources to review would be very useful / appreciated (or code snippets by PM?) wld be most welcome :)

0 votes
Drew Peifer Jan 24, 2013

I've upvoted Justin Rand's answer because it really is the easiest, most light-weight solution to your problem. I have the same issue myself, and it took me about 20 mins to implement and test the solution listed below.

However, I now have 2 more workflows than i did 20 minutes ago. If every department in my company wanted this functionality, we would easily have over 50 workflows for less than 30 projects. The JIRA-mindset for this problem seems to be catering to the use of issue type schemes, screen schemes, etc. to create a hierarchy of events and conditions that automatically modify workflow actions in the background. The problem with this is that it makes even minor problems incredibly hard to debug unless the debugger is also the workflow creator, because a single field may act differently from project to project, issue type to issue type, screen to screen, etc. and you have to debug from the bottom up, checking field permissions, screen configurations, project contexts, etc. The complexities of these hierarchies can be VERY intense, even if the end-result is a minor change in field behavior.

We currently avoid multiple workflows (in some cases) by adding extra transitions to the workflow with unique labels, and while the transitions are basically the same, each has a unique post function. E.g. A tester may click "ready to test in environment B", which just changes status (because code passes environment A), but a developer would click "available for testing in environment B" which adds a post-function notification event to alert testers to the code's availability in environment B. This requires testers and developers to understand the post-functions though, and is error-prone.

A simple solution (that is currently impossible out of the box for JIRA5.x) would be to create conditional post functions such as...

if (issue_type == 'johnsIssue') {assignee == 'userJohn'} else {assignee == defaultAssignee}

to my knowledge, this is still not possible in JIRA5.

0 votes
Ian Mayoh Apr 07, 2013

Couldn't agree more! I have 2 near-identical workflows and the only reason is that I need specific issue types to go to different people otherwise I could use the same workflow. Means twice the effort if I need to change anything common to both and I need to make sure that I make the same change(s) to each --> user errors! Having conditional post-functions would solve this and other issues that I have.

Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published in Next-gen

Introducing subtasks for breaking down work in next-gen projects

Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...

980 views 12 15
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you