Can I make an asignee of a bug someone who is not a service desk agent?

Now if I enable Service Desk for a project I can assign issues only to ServiceDesk agents. 

Is it possible to assign the issue to someone who is not an agent?

5 answers

1 accepted

4 votes
Accepted answer

The short answer is as I understand it (still experimenting with Service Desk) is no.

Not sure if you are discussing customers or developers here.   I will assume developers for the moment.

Service desk has a concept of collaborators for developers.   They are not assigned service desk issues but you can use mentions to get them to look at the issue.  Collaborators must be JIRA users.  If the developer needs work on the code, he should create his own issue since the issue will need to follow a different workflow.


You can still link the two issues (development and service desk) together to show the relationship.

Thanks for providing this important bit here, Norman, as it seems to me the Collaborators part is still confusing a lot of folks.

Norman is correct, only agents can be assigned and work (transition through WF) of issues in a JSD project. But Collaborators can be engaged and if really necessary, assist by working on linked issues from a project in which they can fully work.

The misconception is caused by a single workflow per issue type and a single assignee where we logically need multiple workflows per issue where the workflow is controlled by the user role with assignees for each role (customer support, documentation, QA, coder, designer, project management, etc). I have not found any tracking system that does this though and JIRA has a good chance of getting there if they start solving their long term outstanding issues. If you think what Service Desk is doing, how can you have a single issue assigned to the agent and assigned to the developer? You cannot do this without multiple issues as Jira stands to date. If you did assign the customer support issue to the developer, the agent technically loses track of his issues. Yes, you can start adding fields but you will not have a different workflow.

Hi Norman, "You can still link the two issues (development and service desk) together to show the relationship." Please be honest, this is not straight forward. And very time consuming too. Imagine, that you'd have to link each support request to a !!especially created!! issue in another project. (Some companys must be able to distribute issues through out all jira-users - agent or not) Let's say it would take 30 seconds. Calc up to 20 issues per day per employee. Based on about 200 employess we are talking about = 2000 minutes per day!!!! Only for creating an issue in another project an linking it. Please think about it that: Well, in some cases agent-based is really good. One agent with many many customers. But if you have a structure in which every single jira-user (employee) must be able to be assigned -> no chance with service desk. Regards, Mario

I want to be clear I am an user of Atlassian products like you and I have no relationship with Atlassian other than that. You are asking for an opinion here and I want to be clear it my opinion and not Atlassian's. I am trying to avoid the pissing matches that seems to be getting more common lately. I will agree you need to understand how the tool works and that is not good thing since we are working around the tool instead of the tool working for us. Once the discussion between the agent and developer is done, the developer can create his issue. This discussion can be quite long. The developer issue need not have the same summary/description as the customer issue. The time spent by the developer to document the conclusions by creating his development issue is not a waste of time in my opinion. Doing the linking is busy work since it needs to be a step you should remember to do however it gets done. This process is crying out for some automation even if you clone and move the issue into the development project. The developer can change his summary and description after the fact. I don't like it either that in many cases we are duplicating issues due to how JIRA works. The fact that JIRA Cloud limits plugin support is a major issue and does make this process painful. There are plugins for JIRA Server that could ease the pain which I will be looking to myself shortly as well. Assuming one of the plugins works, it should ease the use pain factor. Again, I have no relationship with these plugin developers, but I am very greatly they make their plugins available to others.

Oh Norman, please understand that I don't want you to be on anyones side. Furthermore I wanted to know your opinion about the agent-based. Thanks for your statement!

There are many facets to the concept of agent based. Are there particular issues not addressed by my previous response you want my comments onr? I know pricing is not covered or the type of organizations where SD may not make sense in are some examples. I do believe SD 2 is a product that could be used in organizations while SD 1 was greatly less so.

I understand that we have different workflows, but now I see that if I want a developer team without agent access to create an issue assign it to someone i need to separate Service desk project and the Software project because if the service desk was enabled for an existing JIRA project only agents could have been assigned to the issues.

For me it is ok to have two separate project one for the development team with standard JIRA issues and one for Service desk.

I was expecting a workflow like this:

Customer report -> Pick up by an agent -> Assign a developer (not necessary agent) ->

Feedback to the agent ->Feedback to the client

If I understood Norman Abramovitz correctly I would have to create separate issues and link them as for example blockers to the service desk request.




The developer needs to be setup as a collaborator. The developer can then add comments to the customer issue while the customer issue stays in the queue for waiting for development. You can use mentions to notify the developer. The developer could create an issue if he needs to because he needs to follow a different workflow for making changes. If the feedback does not require a development issue, he can comment back directly to the customer issue. You cannot just assign the issue to the developer.

We really need the option to be able to assign subtasks to Collaborators.

No need for subtasks to be visible in Customer portal for end users/customers.

Hi Krzysztof, in our case, that's the show stopper of service desk to us. Cheers, Mario


Guys I think to eliminate the duplicacy, I mean Developer creating his ticket and wasting time in linking issues, I think if we can make the different roles engaged in that ticket sees their respective status that should be good by directly assigning ticket to developer instead of Collaborator field.

I have put the very high level thing where it gives basic understanding of what I mean. The comments exchange, email notifications everything remains same for Agent-Customer & Agent-Developer relations.

I feel the current model of Service desk is not very effective for "small to mid size companies" (Not a negative comment but the truth) where customers are mostly internal stake holders. What is the point in Developer creating a ticket. Instead a customer can directly email Developer. Except for we miss SLAs, again which is not a very big thing in small to mid size companies


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,944 views 19 22
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you