assign issue to non agent

[Andre van der Elst]

I'm in the process of evaluating JIra Service Desk 2.0 and have a question:

• when I try to assign an issue to a user who is not an agent I get 'user cannot be assigned issues' , even though the user is an assignable user according to the permission scheme (ie: has the 'developer' role in the project roles and the developer role has the 'assignable user' permission)

Is this expected behaviour or should I check the permission scheme for a wrong setting ?

[Geert Graat · Accepted solution]

Hi Andre,

This is the expected behavior. In Service Desk projects, you can only assign issues to agents. People in the Developer role are probably collaborators, meaning they can only view issues and add attachments and internal comments to them. See https://confluence.atlassian.com/display/SERVICEDESK/JIRA+Service+Desk+permissions for more information.

Regards,

Geert

[Stanislav Rehak]

I have to disagree on this one! It is totaly unexpected... and worst illogical. I hope Atlassians will reconsider this.

[Roman Fordinal]

Rehak, illogical when you thinking about it as user (agent or developer). but because for Atlassian it is not about customers (we), but about money, they are shitting on our heads. yes, it is absoluttely logical to have agents to communicate with clients and developers to resolve issues and log work into issues. but: less agents, less money for Atlassian. We are solving this weird sittuation by copying issues into projects (and because "copy" feature is not available, we are copyiing it manually).

[Michele Longhi]

Just crazy. Developers and Agents are two different things. Developers have to be assigned issues. It will be logical the opposite: Agents cannot have assigned issues, but only assign or collaborate to the issues.

[Jan Sunde Knudsen]

@Geert Graat Any chance this restriction will be removed? Last feedback from you guys was almost a year back..

[Gustavo Zaera Holo]

Please consider removing this restriction. It is right downward counter productive to keep two JIRA projects to manage one Service Desk contract.

[Venkat Imadabattini]

I have to disagree on this one! It is totaly unexpected I hope Atlassians will reconsider thi

[Rob Lacroix]

I concur. Illogical

[Gezim Shehu [Communardo]]

Doesn't make sense whatsoever.

Who was the customer that said "Yes I like this" ??

[Muriel Buyse]

Same here. the cost for the tool is so high because of the assign issue. 

[dchisholm]

The majority of our problems with JSD come from how it breaks communication between Tier 1 (Agents) and Tier 2 (Software) users.

Atlassian should formalize the Collaborator user.   They can make a special permission or an intrinsic role to do this.  Users that have this permission/role:

• Must have a Core or Software license (i.e. can't be a Customer) 
• Can be assigned JSD issues but cannot edit, assign, log work on, nor transition JSD issues

We would still clone the JSD issue into a Software project for Tier 2 users to do their work, but we'd be able to get Tier 2 users' attention on updates to the JSD issue by assigning them JSD issues.  We've have a workaround to do this now, but it's kludgy.

[Marcus Lum]

I also have to disagree with this, cause customer might be someone who have approval rights & we agents need to assign to them for approval, please remove this restriction as this really makes no sense if the approval process is change & we have no way to assign to them but to give them license when there is no need for them to handle the ticket other than approval process is a waste of resources . 

[Jack Brickey]

Customers can be approvers today w/o having to be assigned the issue. Customers cannot be assigned issues but you can make them an agent if you want to for some reason. of course this means they will be added to your billing.

[Carl Madson]

This is nuts. Any intelligent product or system engineer would ask the user community what their typical workflow might be, and they'd surely hear "Customers send us requests for help, which we assign to developers." Nobody I asked said "I'd want to create a new project to manage those issues" or "I'd take in the requests and copy them and convert them to internal issues" or "I'd make everyone special agents" or any such nonsense.

Take an existing team of developers and a JIRA project with all of their issues. Add a connection to the customers. The logical integration should be clear – not two walled gardens with some interaction manager copying requests and tossing them over the wall, and then copying status information manually into comments in the original requests. Who thought that was desired? Who told you they wanted that?

Now I have an existing project with broken assignments to existing developers just because I added Service Desk to the project. Even old issues can't be assigned to valid and (supposedly) assignable members of the Development role and developers group. Tell me that's a feature.

I've recommended JIRA to various company teams for years and have used it actively in many ways, but you've lost me completely with this. It's absolutely the opposite of what I was hoping for, and not at all what I've come to expect from Atlassian.

[Stanislav Rehak]

I have to agree on this one! 2Atlasians: Is there any chance this will be possible in future? Collaborators should be able to log work on request as well as to be set as Assginee.

[Sam Bosell]

2.5 years later and I realize the market for the service desk is not the same as the market for JIRA in general.  Most software support systems need the ability to assign a developer the ticket and the service desk does NOT allow that unless the developer is an agent.  I doubt any of us need the developer to interact with the client (comment internally only) but Atlassian's business model, in this case, goes against their core customers.  It will only end up hurting them in the long run.

[Desiree Graste]

Anyone knows where atlassian stand on this one? I still totally agree with Carl. I'm running in this problem already a couple of years!

[Nic Brough -Adaptavist-]

They expect you to use "create related issue in development project".  The idea remains that the SD issue is for talking to the customer and tracking the request, and if work needs to be done by developers, it should be created separately so the dev team can manage it in a development process.

[Desiree Graste]

Thank you Nic. I know how Atlassian wants us to work. But if you make a nice workflow it doesn't need to be separate. My opinion is that a company uses the different products how they need it, not how Atlassian wants us to use it ;-) and I think we pay enough for it. Or they just need to change the money making model and listen to want their users need and already ask for years. It's such a small adjustment in their software and will make a lot of user happy. 

[SD Admin]

Indeed! We have both team in one company and it is duplicating the work for the developer to create a new ticket as the clone doesn't work cross project! We use linked issue but this only when the developer created the issue before hand. But what about the create issue via customer portal? Agent not able to assign non-agent(developer) and agent have to write a comment to have developer pickup the ticket and re-create a new one in Jira software and next to have it link...

So much work....are there any workaround?? We seriously need to push this bug/ enhancement. 

Please be considerate. Thanks

[Nic Brough -Adaptavist-]

The "workaround" is simple - use JSD as intended.  Create and use the linked issue so the developer has a separate issue to plan and track through their process.

[dchisholm]

I agree with the create-and-link issue approach, but it does create a communication gap that's hard to bridge.  Agents, developers and customers at times have to collaborate, and it can be time consuming if the agent if always the go between.  For example, if a developer adds a comment to a request and needs customer feedback on it, how is the agent notified of the new comment in order to then publish it to the customer?

[Adrien Morel]

And, anyway, the "create linked issue" feature has gone away. My friends, Atlassian is begging for cash.

[Petr Musil]

@Adrien Morel I can still see this option as of 04/10/2019

[Leevi Graham]

This is a deal breaker for me as well. I want a couple of agents assigning tasks to the relevant developers and having the rest of my team take action on technical issues. Cloning issues is going to be a big overhead.

[walter barrios]

x2

[Bart Van Belle]

you also got my vote on this one !

[Roman Fordinal]

btw: and cloning is available only into same project, also customer is receiving confusing message about creating duplicate issue in Service Desk! after cloning is available "move" function.

[Jurgen Imbrechts]

Hi, is there anybody who found a solution to this problem? Maybe a work-around or another plug-in?

I'm a service desk manager, I handle communication with the client.

When an issue is raised it's automaticly assigned to me.

I acknowledge the issue, if it's a problem in the code, then I assign it to the right developer so he can fix it.

Then he assigns it back to me and I finish up with the client. I'm the Service Desk Agent, he is a collaborator.

I would think this is somewhat a standard workflow?

But this isn't possible in the current configuration. I would have to change all my colleague-developers as Service Desk Agents. And thats kinda strange because they are not agents, they are not expected to interact with the customers.

I'm surprised to see a behavior like this in a bug-tracking tool.

Anybody with the same problem as me and found a solution?

Or maybe somebody from Atlassian who has a solution?

[Andre van der Elst]

thanks for the quick answer. This probably means we can end our evaluation though  

[Geert Graat]

The question is what you want to accomplish using Service Desk. We use it for our support department which handles all customer communication. In case development is needed, an issue is cloned to a development project.

[Andre van der Elst]

our project-managers/support-staff would like to see SLA reports, so we thought we could get away with getting agent licences just for them and not for every developer. But cloning issues and copy/pasting comments back and forth just to get around a license restriction is not something I'm going to pursue. Anyway, there's a few more things we're going to try out before we stop eveluating. (cross-project SLA reports is one of our requirements)

[William Rojas (Black Diamond)]

Have to agree on this thread, not only is this behavior misleading, but it looks to be 'undocumented'. Even if I remove the Service Desk Team role from the Assignable User permission and keep Developers and Collaborators only, once the development project is setup as a Service Desk, I lose the ability to assign issues to Developers, unless those developers are also given service desk agent permission. The code seems to be hard-wired internally to check for that user being part of the Service Desk Agents group regardless of the permission scheme defined for the project. So in reality this indicates that one would likely never enable service desk features enabled against existing development projects... not if every developer in that project is now required to have an agent license even if they have no intention to perform any Service Desk functions. This should at least be more clearly documented. Especially since it's not quite simple to undo. Can someone from Atlassian comment, is this how one should advise clients then: "Don't use Service Desk with existing development projects, unless you purchase agents licenses for each developer."

[Peter Straub]

It's not only a question of licensing and the related costs. Developers shouldn't have/see the SD agent functionality. Developers are used to the standard JIRA UI, have their "My Issues - Inbox" with a lot of other issues from their project(s) they currently work on. Clone, Move & Link is a workaround that makes the incident "information stream" move away from the service desk: As an agent or service manager I no longer have a single overview about all the incidents, but have to check two JIRA projects at the same time. The customer is cut off from any comments and information exchange that takes place in the project JIRA. The incident has to be kept "unresolved" in the SD JIRA project until the issue in the developers JIRA project is resolved. The SLA monitoring and reporting will cost much more (manual) effort. This way JIRA SD is not leveraging the standard JIRA functionality and eventually lowers the overall value not only for the customer, but also for the agents, the service manager and the entire organisation.

[William Rojas (Black Diamond)]

It seems to me that limitations in the product were wired in, in order to address licensing and costs concerns. If is is about getting a bump on the collaborator licenses, since this group is now not just developers but also helping to resolve customer tickets, then a reasonable license cost on collaborators would be appropriate. But to assume a collaborator can only comment on an issue and never really 'work' on it is really short sighted especially with how projects that are both used for development and service desk incidents actually interact. Many of the examples in this thread point this out.

[Clemens Perz]

Huh, very weird! Renders the whole system useless. You have roles and permissions and you cannot set them up as you like - the given behaviour is internal, not to be seen in the permissions.

I added a user to assignable users and guess this should mean I can assign issues to him. Pustekuchen! Does not work as reflected in your permisson settings. Very confusing.

Thou shall earn all the money you want, but please dont make the product kaputt for it!

And why can I actually activate a service desk for an existing project without beeing warned that the behaviour will change drastically? Let me see what happens once I deactivate the service desk - will there be a proper cleanup or is it broken?

Very very very weird idea.

BTW, not surprised that the number of comments from atlassian guys is pretty low ...

[Odwin Rensen]

This tool has such create potential and as a servicedesk ticket platform does what it needs to do, but in real life it often does not stop at the servicedesk. When it is code related or the issue needs a higher tier of knowledge these issues need to be assigned to different teams outside service desk.

Not being able to do so, totally renders this tool useless for us.

[Bart Van Belle]

+1 for Roman.

Indeed, a "normal" workflow would be that tickets can be assigned to a 2nd level support team (eg. developers) when the 1st line support (typical helpdesk) decides to escalate the ticket. There should be a transparant way that those tickets can easily be escalated to another level and that then these "collaborators" (developers) can transition the issue through the (escalated) workflow and indeed besides logging comments also be able to log their work spent. Atlassian has a really strong potential Helpdesk solution in house that can compete with the "older" more constituated helpdesk systems out there, but the strict licence policy with agents-collaborators etc makes it difficult to get a solid foot in the ground for companies (like ours) that are looking for a solution to both use JIRA for helpdesk (customers) and development. Indeed there sould be a distinction that "agents" deal with the "end users / customers", and "collaborators" are assigned to a ticket on a 2nd line support level, but it is very strange and really uncomprehensible (besides ofcourse the extra licence fees Atlassian can collect from this (weird ?) licence policy) that on a "normal" JIRA project users in developers role can transition issues through a workflow, log work etc... (if ofcourse the project permission scheme allows them to).

So people at Atlassian: please reconsider this because with Helpdesk in your product portfolio you have a REAL strong product to compete with the "big" Helpdesk systems (like BMC Remedyforce, CA, etc...)

[Jeff White]

Is it even possible to 'clone' an issue to another project as described above?  I know that I can move an issue from a SD project to another project, but that effectively leaves no trace for the customer in the SD project?   but I'm not sure cloning will help either.  I don't see how to clone a source issue to a target clone issue in another project.   

[Roman Fordinal]

nope. cloning into another project is not possible (crazy, uh?). only in two steps: 1) clone issue into same project (and customer are receiving duplicated notification about issue creation :)) 2) move cloned issue into another project

[Bart Van Belle]

an other "alternative" could be that you use for instance the "create on transition" plugin (Bob Swift), so that you can add a transiton to your servicedesk worfklow to "escalate" a ticket (create and link a new ticket to the servicedesk ticket) to eg. a development project. You can than automatically copy subject, summary and other fields from the "parent" ticket to the "child" ticket. So when the "child" ticket is solved, you can eg. post a comment / email to the "parent" ticket so that the helpdesk agent is aware of the fact that the ticket got solved by the 2nd line support team. Not "ideal" but can be a solution...

[Clemens Perz]

I am actually not so worried about the numer of licenses. If it would be like you need to have the user who works on these tickets in group foo, otherwise he cant, and the members of group foo is what is counted in the license ticker and you pay what you need to pay - or decide to use another product, I would be fine.

What makes me mad is that I cant change this intensionally as broken implemented process. Where everywhere else in JIRA I can customize everything, here even my changes will not change anything. This is bad. And its not what JIRA stands for.

Just make sure people can work the way they want to with your product. Should be rule number one. Or not?

[russell illsley]

You have never used JIRA Agile then.....

[Clemens Perz]

Does it have similar issues or restrictions? Would be nice to know. So far I did not run into them.

[Roman Fordinal]

"they can only view issues and add attachments and internal comments to them"
i was always thinking that developers are for developing on issues, also logging work.

Enabling ServiceDesk for project has serious consequences!!!
Developers are not longer able to work on own issues!!!

And that is a blocker bug.

[Ismael Garcia]

Nothing has change from the original post on this topic, is very sad to see atlassian doing so wrong, very disappointed.

[alexandru pau]

Hi 

We were also planning to start trialling JSD and realised the problem in keeping the 2 systems interconnected by the limitation added on Agents vs Developers roles. 

Since the only interaction a Developer could have with JSD tickets is through comments, he would further need to use linked issues following regular JIRA workflow which creates an overhead and latency for Agents activity. This we see it as the main problem, since Service Desk operators would need to constantly check linked issues or comments to proceed with further actions on main JSD ticket 

After further investigations we ran into a possible fix added by Atlassian through JIRA 7.0.0-OD-08-002 bux fix release 

Basically it relates to AUTOMATION feature which could (hopefully) trigger a when / if / then effect from linked JIRA issue to JSD ticket (from example if a linked issue is closed then the main JSD ticket does a transition to it's own workflow status)

Find more information here until will be able to provide a feedback based on self confirmation 

 https://confluence.atlassian.com/cloud/18-october-2015-to-24-october-2015-780870807.html

http://blogs.atlassian.com/2014/12/collaborate-developers-using-jira-service-desk/

[Clemens Perz]

I see there is a new Service Desk 3 coming - tried to figure out if the behavior has changed by reading the information available, but it seems not.

Would be nice if ppl who did the upgrade could share if there has been a change of mind. Just out of couriosity, as my management has already decided to drop JIRA in favour of a much more expensive product that does not impose a certain workflow for the sake of a doubtful sales pitch.

[Joe Barneson]

FWIW – I had stories with subtasks outside of my service project that I "moved" into the service project. The subtask's assignee was a not assigned as a service agent and was retained as the assignee.

This is a terrible workflow to retain assignee's in the service center – but I wanted to share out if others felt they could tolerate it.

I too, like many others, will not being using the service center until it allows my collaborators (team members) to be assigned to subtasks. 

[Markus Dengler]

totally agree - absolute useless if it is not possible for collaborators to log work at least;
Assigning JSD Items to developer or creating a related issue would be great

[A]

The new version (Agent based) Service Desk is total useless as far as permission set up is concerned.  Just like someone above stated, They have the roles and the permissions, but you can't set them up as you like.  Totally confusing and frustrating.  I'm in the process of evaluating this new agent-based version, I've been getting permission related issues constantly.  I think non-agent based version work perfectly fine.  It's more straightforward, easy to follow as far as permissions, roles are concerned.  What you see is what you get unlike the agent-based (what you see is not what you get). 

[russell illsley]

Its just a way for Atlassian to force us to buy more licences.

this is poor.

its normal in any real IT world  an IT Service Desk operator would assign a ticket to an Engineer to execute - two separate functions who would both work on the ticket.

[Todd Sherman]

This totally pissed me off!!! I spent hours trying to figure out this permissions problem, thinking I set something up wrong only to read this? 

[Fuad_Hasanli]

Hi, not only me have this problem. Customers raises request via Customer portal. Our agent created duplicate of request in software or core project. Let's say it OK. In duplicated task our developers or support employees works on tasks, and customer doesn't have any information what going on in background. It's makes complicated for customer to get info about his/her request. 

[Patty Yost]

Having read through most of the comments on this thread, the underlying theme seems to be that Atlassian wants you to have a Service Desk license for any user that is assigned to an issue.  BUT -- they not only require a license, they require that users be in the Service Desk Team project role to be assigned to an issue!

We created a separate project role in order to limit the permissions for a group of users, but did give them 'Assignable User' permission AND gave them a Service Desk license. We can't assign tickets to them unless we add them to the Service Desk Team!!  Please fix this, Atlassian!!

[Patty Yost]

I was wrong! We gave the 'Service Desk Agent' permission to this group and they can now be assigned issues, yet still have the restrictions that we put in place on other permissions.

[Rich Hale]

We have a bit of a different model:

• Agents (x17 to 30) will talk with customers, and always enter the issues.   They didn't want to work through the limited customer portal view, so I needed to give them permissions at the internal project level also, and customize that "create" issue screen, with about 10 required fields.
• Developers (x3 to 6) will work customer issues directly.   Thus creating them as JSD Agents made the most sense.   

I've priced a few service desk products, and I'm thinking even having the developers as agents, but having these two systems so tightly integrated into a single (SaaS) solution, is still a great savings over other platforms, all things considered.

Keeping in mind, JSD is designed specifically as a customer oriented portal with feature sets around that solution and set of problems, linking these issues to solution oriented JIRA tickets in other projects is really not a bad idea, nor too time-consuming.   You can allow developers to "view" these JSD tickets as part of that model.

[dchisholm]

We have added a custom action on our software projects called "Add as Participant".  If a development issue is linked to a JSD issue, this action will add the developer as a participant to the JSD issue, and that allows the developer to add public comments via JSD's portal view to collaborate directly with the customer.

[Rich Hale]

good idea

[Nicolas Millier]

@dchisholm your idea was interesting and before trying to make a custom action I try to add a simple Jira user (not JSD agent) as a Participant on a task but I still don't have the button "Share with customer" under the comment field but only "Comment internally". 

Is it still working for you ? If yes did you change any user right or make configuration change ? 

Thanks for your help.

Nicolas

[dchisholm]

It's working, but the Jira user must open the request in the JSD portal view to add a comment.  They cannot add a public comment from the Jira issue view.

It's not ideal but one advantage is that the Jira user sees  the comments exactly as the customer does, and I think that improves the context  for their public comment.  E.g. it's less likely to publicly reply to an internal comment.

Also be aware, after becoming a participant, the Jira user can receive notifications (depending on your notification config) whenever changes are made to the request.

[Jerry Ryan Ishmael]

tldr;

I skimmed through most comments but I don't understand why those issues that need 'escalation' to a developer do not have a linked developer ticket through JIRA? 

[Jan Odvárka]

I was able to implement JIRA SD into production with system of SD issues and linked issues into the separate projects for HW engineers/ SW administrators / etc. 

Everything is now working somehow, JIRA SD with Insight CMDB and custom fields is able to let me create and choose everything.

Powerbox SLA is able to show SLA on Service Desk issue to non agents assigned to linked issue. 

Automation for JIRA is able to provide comments copy/paste from linked issue to main issue and than send email to the Service Desk mailbox.

I can send notification with variables in subject and body, but with MANDATORY PREFIX, which causing a lot of problem for many of our customers.

I will kill for possibility to let 2nd/3rd lvl support to update statuses/comments on the main issue without need to make two tickets for 1 issue.

[Jack Brickey]

I assume you mean 'and not have to give 2nd/3rd level support users agent properties'. If you want user to be able to edit/transition they have to be agents.

[Jan Odvárka]

Well most typical use case

SD agent creates an issue

SD agent assign himself as an "Agent" 

SD agent choose SAP administrator named for example Bob :) from the list and assign him as a "Resolver"  

we are still on the same issue

SD agent has own permissions to use transition to go through whole workflow or only for defined steps (defined by admin)

Resolver Bob has  his own permission to see running SLA, all details, add comments, updates, but he has also possibility to use transition for changing status in the workflow. This could be restricted by mandatory approval from Service Desk agent, but he has to have rights for transition from Created to In progress, In progress to pending (waiting for customer) and from In progress or waiting for* to Resolved.

Each transition done by Bob can be set as "have to be approved by assigned Agent, so Atlassian will still have almost the same licencing policy restricting to non agents to be fully operative in SD issues/projects.

I hope that I wrote it clear :)

Kind regards

Jan

[Deleted user]

I understand the reason for only allowing agents to be assignee of a request, as they effectively manage the request but would Atlassian consider allowing sub-tasks within a service desk project to be assigned to anyone with the 'Assignable' permission.

My use case would be:

I have a workflow status called 'Bug fix in progress' that requires creation of a sub task assigned to a developer to be transitioned to and can only be transitioned to 'Bug fix complete' when the sub-task is complete.

This overcomes the 'developers' exclusion case but allows separation of front line agent workflows and that of any support or operation workflows that may come into play to resolve the request.

Another thing, what if 'Request participants' could transition? This would allow and agent to add a participant at a particular status and they can then transition when they have completed there part.

[Bart Van Belle]

First of all, I don't understand Atlassian's "logic" to allow only agents as the assignee of a SD request (except for the licence cost ofcourse) nor the "logic" that "collaborators" can only comment on SD requests (to collaborate goes a little bit further than just "commenting" as far as I am concerned. What we at our company intend to do is to have the SD project in a *separte* JIRA instance with limited numbers of "agent licences" (so that they can act as the 1st line support) and then have another *separate JIRA instance* installed where an SD request can be "escalated" to (meaning a new JIRA ticket is created in the 2nd instance with a copy of all the data of the original SD ticket and then fully syncrhonized bi-directionally). So the 1st line support agent would then in a workflow "escalate" the JIRA to the 2nd JIRA instance where the ticket *can* be assigned to users with *assignable" permission (logic) and when done/more info needed can be replicated back to the SD JIRA instance. There are some commercial tools / plugins available in the JIRA community to do this replication which are *far* less expensive that let's say buy a bunch of "agent" licences for your developers....

[William Rojas (Black Diamond)]

Andre:

The global permission scheme that JSD 2.0 introduced requires that a user be in the service-desk-agents group before you can assign a service desk issue to that person -thus taking up an agent seat in your JSD license.  Collaborators are only allowed to comment on an issue, but cannot be granted assignable user... even if your permission schemes says so, the assignment won't be allowed.