I understand that these project roles are related to project permissions schemes. However, is there any reason why I couldn't just update JSM project permissions schemes to use the project role of, say, Project Member and get the same results?
I'm looking to simplify the amount of project roles we have to make managing project permissions schemes and administering projects more simple and straight-forward. And having different roles with the same functions simply because one is for JSM and the other for Jira just seems unnecessary. Am I missing something else, here?
Hi Jennifer, this is my understanding: JSM treats users differently whether or not they are Agents. JSM Agents have different functionality which allow them to respond to customers or not. Jira Software users can be collaborators on JSM issues where they are not interacting with the customers, but able to assist on JSM tickets. These would be part of the Service Desk Team. If you Jira users that you don't want to have access to the Customer Project, they would not have that role. Those types of users could also be Internal Customers, where they can submit tickets, but not act on them.
Hope that helps.
Thanks, Dan. But I guess my question is, isn't all that treatment for the different roles managed in the project permissions scheme for that project? So couldn't I modify all the permissions to remove the Service Desk Agent role and replace it with the Project Member role and now Project Member would now have all the same functionality that Service Desk Agent previously had?
Or is there some other functionality built into the JSM project type that relies on those specific Project Roles in order to work properly that we, as site admins, have no insight to or ability to modify and therefore making the application of those specific project roles critical to maintain functionality?
The reason I'm asking this question is that when Project admins are adding users to their JSM projects, there's confusion about whether to add them to the Service Desk Agent role versus the Project Member role. Having both options is tripping people up and seems superfluous if you just update your Project Permission Scheme to use the Project Member role instead since that's what's used on every other non-JSM project.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The typical project roles for JSM are - Administrators, Service Desk Team (i.e. one with agent licenses), and Service Desk Customer. All other roles that you may see in your env are for non-JSM projects (i.e. Jira Software projects) which should not be utilized against a JSM project setup.
Users assigned to the JSM project - should only be assigned to one of the above roles. I agreed with what @Dan Breyen stated.
Lastly, as mentioned in your reply back to Dan - "Project admins are adding users to their JSM projects" - Are you saying that the admins want those users to access the JSM issues via the project UI? By default, a typically user can only access JSM issues via the portal UI.
Hope this may also helps.
Best, Joseph Chung Yin
Jira/JSM Functional Lead, Global Technology Applications Team
Viasat Inc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks, Joseph. Yes, I understand what those roles are for. I'm questioning whether I can update the project permissions scheme to use other roles instead and still have the same functionality.
When I say project admins are are confused as to whether to add the "Project Member" role or the "Service Desk Agent" role, I know that in the current set up they should use the "Service Desk Agent" role. However, if collapsing the roles and just making one role "Project Member" makes it less confusing, why wouldn't I so long as I've updated the project permissions scheme correctly? I just can't understand why they made separate roles that could easily be used interchangeably so long as the permissions schemes were updated.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Jennifer for your clarification. You can definitely go with your route on setting up other roles for your projects via project permission adjustments. One thing that you need to know that you are diverting off from the default out of the box setup, and everytime when you create a new project you will have to ensure your custom changes are implemented.
Lastly, any new changes from Atlassian's JSM product, they will continue to use the out of the box setup. Thus, it means that you will have to keep on top of those changes so your customizations are not impacted.
Hope this helps.
Best, Joseph
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.