Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,466,652
Community Members
 
Community Events
176
Community Groups

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

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.

7 comments

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

Rodrigo B_ Atlassian Team Mar 27, 2021

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

Like Aaron Geister likes this

@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.

Like Rodrigo B_ likes this
Rodrigo B_ Atlassian Team Apr 07, 2021

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

@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_ Atlassian Team Jan 16, 2023

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!

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

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events