Hmm seems like my demand has been around for almost 10 years now.

At least Sub-Tasks should be assignable to Collaborators. And Collaborators should be able to transition Sub-Tasks. I get that they should not have the ability to use the full stack of JSM tools, especially communicating with a customer and acting like an agent. But if out 1st and 2nd Level Agents need to have small chunks of work done by developers, they should be able to write this down in a Sub-Task assign it and get it done by a collaborator. Only "mentioning" them will not work since that is quickly missed. This would also allow configuring OLAs between support units and developers to ensure the customer facing SLAs.

So:

• Make Sub-Tasks assignable to Collaborators
• Make Sub-Task transitions also to be triggered by Collaborators

Im really dissapointed that this feature is not yet enabled. We will be considering moving to alternate platforms if we cant achieve this. Its a real dealbreaker. 

How do other companies go around it at the moment? It cant be that you guys are duplicating service desk tickets for your developers, right? It doesnt make sense. 

This requested was created in 2014 and its 2022 and I am still looking for this feature. 

Re JSM team, this is a very powerful feature that can enable work robustness for many service desk teams. 

Ed seems to have missed the point.

Yes if there is significant dev work to do, then new tickets should be created and managed in sprints like everything else.

BUT

The SD Agent needs to know who is holding the baby at any given time.

So an gent should look at the ticket and see that it is assigned to a developer or a Team :Lead.

This applies equally to a case where no development is required, merely "Expert advice" as to one where development is needed (albeit hte first should resolve faster).

Collaborators should be able to be assigned and to assign.

Thus when the question is answered ( or the fix released) the ticket can be assigned back to the agent. In is not necessary for Collaborators to update hte Status of an SD ticket but the assignment should reflect wo is working on the ticket at any time.

I have this same issue in my org. Support agents need to push an issue to a developer for additional technical support. I tried editing the permission scheme but that does help because Service Desk overrides the permission scheme.
https://confluence.atlassian.com/display/SERVICEDESKCLOUD/Managing+collaborators
Collaborators should create issues in their own project (outside of the service desk project) to track internal or long running work. This allows the team of collaborators to assign and log work on issues and use their own workflow for resolving their own issues. For example, when a support team runs into an application bug, this bug should be created as an issue in the development team's project. The development team can then use tools like JIRA Agile to allocate the bug into a sprint and see it through to an update in the application. Separating customer issues with internal ones also allows the support team to link multiple support tickets to the single underlying bug, avoiding duplication for the development team.

Don´t make us search for workarounds on this, this is common sense, we just need to assign issues to developers exactly the same way we have been doing always, I just do not understand de logic other than try to charge extra $25 dolars per user. If this is the case just tell us and we could validate our options but at least not feel disspointed because of your lack of interest in good user experiente.

Hope to see this fixed real soon.

+1.
The agent role has the function of a first level support. The agent would try to solve the incident first by himself/herself and recover the service. If he/her doesn't succeed, the incident would be assigned to the second level support, which normally would be a developer or a system engineer, who is not member of the service desk team. This JIRA user/role should be assignable and thus be responsible/accountable for the ticket until it is resolved and re-assigned to the agent.
Cloning only makes sense if it is not an incident but another issue type like change request or bug that is typically dealt with in development teams. Cloning means that the agents loose track of the ticket or have to track it in another JIRA project and for the customer the comments and actions no longer visible too. This workaround actually lessens the usefulness of JIRA Service Desk.
From a service manager point of view, service management (SLA monitoring, reporting, etc.) is more complicated and requires a much higher effort.

+1