Creating the Service Desk Customer role on Next-Gen for provisioning with Atlassian Access

[#1]

The new Jira Service Desk Next-Gen project type comes as the simplified solution for easy to start and use for your help desks, without needing a Jira administrator.

One of the differences in comparison with the classic project type is that customer permissions should be managed only on the Customers tab, leaving the internal project access area for internal use only, which makes sense.

Recently, I've worked together with a customer who wanted to leverage Atlassian Access's user provisioning to automate the access grant for portal-only users of their company, these users have Atlassian accounts, so that's feasible.

On classic projects, you just need to use a provisioned group and grant it the Service Desk Customer project role within your Service Desk project, but as things are different for Next-Gen, this role does not exist, where to now?

In order to solve this problem, I went through a round of testings with the new simplified permissions for Next-Gen and got the result that allowed internal users to become customers on Next-Gen projects through Group assignment (Which can happen through user provisioning):

Create a new role, let's name it Service Desk Customer and then grant it the following permissions:

Work on "<Service Desk Name>" requests

Act as an agent and communicate with customers to create, edit, assign, transition, link, and log work on any "<Service Desk Name>" request.

•  Assign any request
  Add someone to or modify the assignee field on any "<Service Desk Name>" request.
•  Edit any request
  Change the summary, description, and update custom fields on any "<Service Desk Name>" request.

 Create requests internally

Create "<Service Desk Name>" requests internally and fill out their fields upon creation. 

Collaborate on "<Service Desk Name>" requests

Leave internal notes and attach files to any "<Service Desk Name>" request.

•  Add attachments
  Add attachments to any "<Service Desk Name>" request.
•  Add internal notes
  Leave internal notes on any "<Service Desk Name>k" request. 

Explaining the permissions

• The Assign any request is granted so that customers can create tickets on the portal, even for issues starting as unassigned.
• The Edit any request is granted so that customers can share the issue with other customers or internal users on the portal.
• The Create requests internally is the initial permission to allow to use the portal, dependent on Assign any request.
• The Add attachments and Add internal notes allows to upload attachments and add comments on the portal.
• Though some of the permissions says "internal", they work for the portal as well.

Test results

The users provisioned into the servicedesk-customer provisioning group created were granted customer access to the portal, without issues to raise tickets, share them, transition them to support through comments (With the proper automation in place), seems pretty good.

I wanted to share this as it might help other people and also detect any outstanding missing permissions in case of different Service Desk Next-Gen project configurations.

[Aaron Geister]

Do you need automation to make this work and can that be the outline role and permissions needed alone to accomplish this?

[Rodrigo B_]

No need for automations, the permissions above should be sufficient, but share any challenges you had when applying the instructions!

[Aaron Geister]

@Rodrigo B_  Very good work here. I love this, and its very helpful as we transition to the next step of Atlassian to be able to carry our older settings as we are used to those from the classic projects.

Keep up the good works.

[Rodrigo B_]

Thank you for the kind words, Aaron! It makes me happy to know that my article helped you, I will keep it up!

[Oto Tabares]

@Rodrigo B_ We were excited about this approach until we found a serious issue.

Unfortunately, when granting employees customer access to team-managed JSM projects using this approach, they also gain agent access if they have Jira licenses. Needless to say, this is a considerable issue when you need to keep the service desks confidential.

Is there any way to accomplish the following?

* Grant customer access to team-managed service desks using an Atlassian Admin group. In particular, we're looking to use an IdP-synced admin group to automate the addition and removal of customers across our service desks.

* The approach must not grant "customers" (employees) agent access to the team-managed service desks if they have Jira licenses.

* Our service desks have content that is meant for internal use only, so opening up the service desks to the public is not an option.

I love Atlassian products, but I'm struggling to believe that our only option is to manually update the customer list on every service desk with every onboarding and offboarding. 

[Rodrigo B_]

Hi @Oto Tabares

Thanks for reporting that, as the article is from 2020, it's possible that something changed.

May I ask some clarifications?

When you say that users gain agent access if they have Jira licenses, are those Jira Service Management licenses, or other Jira types?

Thanks!

[Oto Tabares]

@Rodrigo B_users gain view access on the JSM projects regardless of which Jira license they have (JS, JSM, or JWM).