Hi,

As explained in one of my support ticket, we have some of our customers working with us on the support tickets, and they have a Jira Software License.

They don't understand why they can't do what they can do through the Portal, in JIRA.

It doesn't make sense from a user perspective that a user who has access to Jira must go to the portal to transition, put a public comment or do anything that a classic customer can do.

Don't take it wrong, our customers don't have Agent roles. They have access to Jira to see the Kanban from the Jira software which contains also JSM tickets.

: idea: when an user has the Jira Service Desk Customer role + a Jira Software license, he should be able able to everything that he can do in the portal, in Jira UI.

I hope it helps. Today, the UX and UI are not harmonized, and our customers get a bit frustrated.

I need to assign issues in JSM projects to JSW users rarely, once-twice per year, so I don't want them to use JSM licence for whole year if they need it twice.

It would be nice, if they could edit issues with JSW licence or at least transition and close the issues. Transitioning without JSM licence seems to be something that would not impact the sales of JSM as Customer Portal users can even do transitions in portal. Current workarounds I know are:

• assignee who doesn't have JSM licence but has JSW licence, can open the request in portal and then resolve it

• assignee who doesn't have JSM licence but has JSW licence, can execute automation rule, that will close the issue

They both seem stupid and annoying. I would really like to JSW users being able to transition JSM issues. 

+1, please enable this feature!

+ 1 Really necessary and not worth paying a complete agent license

Wow, our team really needs to let Jira software users transition JSD issues. We shouldn't all need agent licenses just for this. Please enable this feature!

+1. Our desired workflow is to create a subtask in a service desk project and allow non-agents to interact with that subtask normally apart from communicating with customers. Currently this is not possible, however, as JSD requires that everyone who interacts with a JSD task in any meaningful way be a licensed agent. It is not practical or desirable to license everyone who could ever be assigned to a service desk subtask to help with an issue. As a workaround, we are creating duplicate issues in separate, internal projects and then creating the subtasks in those. This is just horribly unnecessary. We would like to buy agent licenses for our customer-facing employees only while still allowing internal folks to collaborate. This is the behavior that was suggested during the sales process and this current handicap appears to directly contradict what was described.

We need our collaborators to be able to transition and edit issues but don't want them to be able to make customer facing comments. There is no option for this. Either they are assigned Browse Project permission where they cant add customer comments but also cannot transition / edit issues or add them as a SD Agent meaning they can transition/edit but can also add customer comments. This limits collaborators and really they are not collaborating at all, just commenting.

Any idea if Atlassian thinks about giving back some permissions to the collaborators?

Is there an official statement from Atlassian regading that topic?

Our whole Service Desk has been built around the "old" license scheme - it seems to became useless in an instant after applying the new license. This is really a shame!

Totally agree with Amanda and Jon.

Agree with Amanda - this limitation of roles in terms of Agents and Collaborators has a massive impact on our future use of JIRA, even with the more modular system Atlassian have provided in JIRA 7. Totally understand that Service Desk as a standalone tool (separate to JIRA) is a less costly offering than other tools of its ilk, but the permissioning around having to have Agent licences to do anything on a ticket or be assigned one is flawed. The term collaborator is used as someone who collaborates - ie helps on the issue to provide a resolution, thus should be able to have tickets assigned to them and perform basic functions like move it on a step in a workflow or edit and add data. Otherwise, even by adding a comment, there is NO way to record their help.

Collaborators need to be able to transition issues to actually be collaborative. In our pilot build out we used Collaborators and workflow transition steps to handle necessary functions before passing back to the agents, and now without this functionality we are unable to proceed with Service Desk

I am also astounded by this backwards move. The beauty of Atlassian products in the past has been complete control admins have over configuration of these systems.

This is a major step back in my implementation and while we love having the ability for non-license count JSD users, it came to us at a great cost of completely breaking our internal support structure.

Not being able to edit fields and manage watchers is a major step back, requiring me to use agent license seats for reporters.

I am actually stunned that JSD not only takes away permission control but also renders all other role permissions useless. Fact is that only agents can work with issues from a JSD enabled project. None else can edit, transition or assign issues. The other JSD roles are useless. A collaborator cannot collaborate. The role should be called "commenter" because that is all they can do in the end.
We have thousands of users in our environment that need to work on issues. They need to edit them, assign them and transition them so the work gets done. They are not agents in the JSD sense, they are workers, real collaborators if you will. And what I can read from the other comments here, that is how the world works out there.
After we enabled JSD for the first project it took 15 minutes until we disabled it again because nothing worked anymore. Production got to a halt. I am very disappointed. An absolute No-go for this product.
I have no idea how this permission concept made it into the product. It does not reflect how service teams work, definitely not in large environments. The only reason that comes to my mind to only allow agents to work on issues is that Atlassian wants to make money out of this, a lot of money. $45000 for more than 100 agents? Really?
Please allow the JIRA permission schemes to work in JSD enabled projects. Give control to your customers about what the JSD roles can or cannot do in a project!

I agree!! Collaborators must interact with issues of SD. In our model we have the SD team (agents) for the first analisys of ticket but when an issue go to "1 level support" we need other persons (programmers) that analyze and work on it.
I'm not able to assign the ticket to programmers ("collaborators") and this is a limit! Also, programmers are not able to load log work for example and it's a second limit.

Strongly agree!!

We're currently using Service Desk v1 (JIRA user based), but we're thinking about switching to service desk v2 (Agent-based). We're in the process of 30 day free trial and noticed a lot of issues with permissions. We'd like to allow collaborators to edit or transition the issues. In our case, we have different stages of triaging the issue. When issue first gets created, it gets transitioned from "Open" to "Level 1 Support". After Level 1 is done with their work, the ticket gets transitioned to "Level 2 Support", then to "Engineering". After "Engineering" is done with their work, they have to transition the issue back "Level 1 Support" for them to contact customers to deliver the fix,etc.
Without this, we'd rather stay with the old version and things work just fine. Please let us know if this is possible. We need to make this decision before the 30 day free trial expires!

I absolutely agree. Having the restriction on 100 agents is an obstacle for us to fully deploy Service Desk in our workplace. Due to the sheer volume of collaborators and staff we have involved in supporting a large number of tools and applications, this is a must, if we are going to push it as our primary service management system.

Totally agree - we are currently working with Portal v1.x and the benefits of us growing our use of the Portal to take over a lot of archaic functions in our company is why I'm pushing for more use of JIRA and Portal - however the v2.x issue with Agents and Collaborators is causing huge pushback re costings. It makes no sense that a collaborator on a call from the Portal cannot do simple JIRA functions - Agents just have greater access, ok, but please please please change the model to allow collaborators to action workflow elements, have tickets assigned to them etc ... otherwise you've created completely useless function in JIRA. This is causing negative feedback on what has been, to date, a great tool for our business - the benefits it WAS bringing meant we were bringing more and more of our day-to-day roles into the Atlassian world ... but this is a stopping point for us.
Everyone is screaming for this - please listen!

this is a common use case, and it is quite surprising that it was not considered as 'necessary' for the standard Service Desk usage model.

By mis-assuming that either, everyone in a development shop will happily just purchase agents license for the 'techies' (the cost of which is prohibitive, since we are talking an entire development staff: developers, testers, analysts, etc.) or that the bottle neck of having two separate projects that now must have issues linked and kept in sync by the help desk agents - the service desk offering provides only very limited benefits until this can be resolved.
It may be that Collaborators would require some type of licensing beyond the base JIRA license, to account for the added service desk/development integrated functionality.
But requiring that anyone needing to act on a service desk ticket to have an agent license (even if only employing base JIRA features) is really misconstruing the intention behind all the negative feedback on the version 1.0 licensing.

Please provide a resolution to this ... fast. Really hinders the offering and selling of this add-on.

I completely agree. This restriction - especially in the light of the fact that there is also an absolute limit on 100 agents is extremely restrictive and prevents us from being able to deploy service desk in production.

This one is nagging more people. See also;
https://jira.atlassian.com/browse/JSD-931
https://jira.atlassian.com/browse/JSD-861
https://jira.atlassian.com/browse/JSD-884

And the discussion thread on https://confluence.atlassian.com/display/AOD/Managing+collaborators

If you agree - please contribute/vote up!

It seems that Atlassian is leaving the path towards ''Dream big, work smart, deliver fast'' and starts introducing silo's itself. A pity, to use an understatement, 'cause it limits the potential of Servicedesk - even to the point that the added value becomes questionable.

Strongly agree.

We use JIRA Service Desk 2 with 10 agents and 50 JIRA Users. The JIRA Users are Service Desk Collaborators who help us resolve problems. I want to allow those Collaborators to be able to Edit Issues.

Why? For example, they often need to edit an issue to change its workflow status or tag it ("ready to push to QA server"). The ability for collaborators to edit, update and tag issues is critical for us.

But we cannot get it to work. The JIRA Service Desk documentation says it is a "major permissions error" to allow collaborators to edit issues:
https://confluence.atlassian.com/display/SERVICEDESK/Resolving+permission+scheme+errors
(That explanation in the bottom of the table does not make any sense to me.)

When I add "Edit Issue" to the permission scheme, it still does not work. It does not let collaborators edit issues. Similarly, I also want to add the "Assignable User" permission for collaborators, but that also does not work even if I add it to the permission scheme.

If anyone knows a work-around, please suggest it.

Strongly agree.

We would like to make use of this product but the restricted permissions break our current projects if we created a service desk from them. Only agents are given the ability to do routine actions like create links, assign users, transition to a different state, etc.

Wish you had kept the old pricing model but opened it to customers (would have been an easy fix). It remains as impossible to use as it was before. Too expensive due to the limitations of the over-arching service desk permission scheme.