Controlling Customer Access Across Multiple Service Desks

[Deleted user]

UPDATE: There is currently no resolution for this issue right now. Please see the accepted answer below for details.

----------------------------------------------------------------------------------------

After reviewing a number of open questions (see this, this, and this, among others) and articles about the subject, I'm still unclear as to the current state of customer portal visibility across portals. At it's core, the question I have is simple: How can I create multiple customer portals but only allow users' respective access to each?

Scenario:

All Atlassian products mentioned are Cloud-based.

Our company develops custom applications for clients. As such, we have Jira Software projects that manage those activities. However, as an app is released for client usage, we have a need to allow clients to submit tickets to us (troubleshooting, bugs, support requests, etc.) via a Service Desk. We have multiple clients, which would necessitate multiple service desks. However, within each client, we do not have an ability to manage users one-by-one (some of our clients have hundreds of employees which change constantly), so we want users to be able to sign up for access to their respective service desk, and not be able to see other client's portals (or even know that they exist). Based on the various instructions I've come across (namely this, this, this, this, and this), we have our system configured as follows:

Jira Service Desk - Configuration:

• Can customers create their own accounts? Yes, by signing up or sending a request
• Can customers access and send requests from the help center without logging in? No

Jira Settings - Security:

• Project Role: Service Desk Customers (no default members configured); displaying as not used in any notification, permission, issue security schemes or workflows

Jira Settings - Issue Attributes:

• Permission Scheme: Our JSD Permission Scheme (which is shared across Service Desks) has the following permissions granted to the "Service desk customer - portal access": Browse Projects, Assign Issues, Close Issues, Create Issues, Delete Issues, Edit Issues, Link Issues, Modify Reporter, Move Issues, Resolve Issues, Schedule Issues, Set Issue Security, Transition Issues, Manage Watchers, View Voters and Watchers, Add Comments, Delete Own Comments, Edit Own Comments, Create Attachments, Delete Own Attachments

Project Customer Permissions:

• Who can access the portal and send requests to <Service Desk Name>? Customers my team adds to the project

***Note: When I flip this over to "Anyone can send a request via the portal or <servicedeske-mail>", this opens the respective portal up to be visible by all customers. This appears to be the key point of failure. However, at least one project needs to have this option to allow for Sign Ups...

Desired Experience:

A user selects their portal link (either via an intranet page, e-mail or however; it shouldn't matter), they are sent to the Service Desk to sign-in. Either they sign-in with their existing account, or they can choose to "Sign Up" and create an account. After signing up/in, the user is redirected to their sole service desk portal where then can initiate a ticket.

Again the moment I allow "Anyone" to be able to send a request within a given project, what it delivers is that all client users can see all client portals that have the "Anyone" option selected - the exact opposite of what I want. And when I don't allow "Anyone" on at least one service desk, the ability to sign-up for an account goes away entirely.

Questions

• Have I just totally biffed something regarding Project Role or Permission usage? Surely it's not expected of a project admin. to go in and manually assign project roles post-customer-registration (as I don't see a way to automate this via workflows).And given that Customers don't auto-populate in the People section of the Project Settings, I don't know why this would be necessary either.
  • Do I need to apply the "Service Desk Customers" project role instead/in addition to the "Service desk customer - portal access"?
  • Do I need to create a unique permission scheme for each project? I'm not sure how that would actually get me towards my desired experience.
• Given that the user registration appears across portals (....atlassian.net/servicedesk/customer/user/signup?destination=portals), how would the user's account become associated with the intended portal?
  • Am I forced to have a "dummy" portal (read: poor experience) with "Anyone" selected just so a user can sign-up for an account for a different portal?
    • Presumably, the user is then defaulted into the first/only portal where the "Anyone" option is selected?
• How can I create multiple customer portals but only allow users' respective access to each?

[Deleted user · Accepted solution]

As I feared, based on my support request on the matter (in an effort to hopefully isolate any configuration issue that may have been the culprit here), Atlassian has confirmed:

Currently, the possibilities presented by Jira Service Desk allow its projects to either be completely open (customers can signup and access all projects on this config), or closed (only your team can add customers to specific projects).

They did share a couple of enhancements intended to address this issue:

• JSDCLOUD-1939 - As an admin I would like to have users who register via public signup on a specific portal to only have access to that portal.
• JSDCLOUD-3540 - More flexible portal-specific customer signup

It looks like they're in their infancy in the grand scheme of open Jira issues (only a few years old, and only a few voters/watchers). I encourage everyone to vote/watch those issues.

I guess my only recourse for the time being is - short of jumping ship to another ticketing tool - to configure a "master" service desk which has only one request type: Account Request. I'll plan to direct all sign-up requests there, and then I will manually create and assign customers to their respective portals. Not the greatest solution, but at this point, I don't really have another option...

[Diana Mbau-Kariuki]

I have tried all the options given and none seem to work.

[Paul Boorer]

Am facing what seems to be an identical issue -

Jira Cloud : How can I control which Service Desk's are shown in the Help Center

Requirements pretty simple -

• Jira Cloud
• Have several Service Desks
• Service Desks are for various external facing applications with different client user bases
• Clients create ticket with unique email address for each Service Desk
• Service Desks are open so users can create tickets without being invited to join - this is open as we don't want to administer and manually manage onboarding them
• When clients log into the Help Center they can see (and potentially create tickets in) all the Service Desks which are not related to them

Desired behaviour is that a client only see's the appropriate Help Center and can only access the Service Desk Portal that relates to the ticket they have raised.  We have completely different client bases per SD so they will never overlap.

Have searched and read plenty of articles and it seems this simple setup cannot be met with Jira Cloud.

Hoping it's solved soon

[Jack Brickey]

@Paul Boorer , find a customer that can see projects that they should not be able to see. go to the offending project and check to see if the customer is anywhere in the Customer list. Be sure to check both the root customer level as well as and organizations. Visibility of projects in the Help Center is controlled thru the Customers function.

[Paul Boorer]

Hi @Jack Brickey 

I mean in the Help Center

I have tested this and an external user that sends a request to a Service Desk and then creates an account to manage the request can navigate to all other Service Desk's Help Center Request Raising screen.

Ideally they'd only see the one for the SD that they have raised an issue in

[Jack Brickey]

did you check what i suggested? are these customers listed in the other projects. The way it should be working is like this...

Project 1 has customer A, B, C, D

Project 2 has customers A, X, Y, Z

If A logs into portal then they will see Project 1 and Project 2 and can open requests for either.

B,C,D will only see project 1

X,Y,Z will only see project 2

so if you don't want "A" to see Project 2 please make sure they are not a customer of Project 2. If you confirm that they are not a customer of P2 and indeed they can see P2 then please reach out to Atlassian Support.

[Deleted user]

@Jack Brickey, I think the issue arises when you want to allow users to sign-up.

If it's not feasible to to manually administer users via the "Who can access the portal and send requests to <Service Desk Name>? Customers my team adds to the project" option, there is no way to keep individual service desks "private". See the note from the original post:

***Note: When I flip this over to "Anyone can send a request via the portal or <servicedeske-mail>", this opens the respective portal up to be visible by all customers. This appears to be the key point of failure. However, at least one project needs to have this option to allow for Sign Ups...

Essentially, there's no way to allow sign-ups for a project unless it's available to "Anyone". So it isn't possible to allow only users to access a "private" portal in order to sign-up for an account with access to that portal only. What's missing from your scenario is I have customer M (out of a customer base of hundred or thousands; thus it is not feasible to manually add these customers in advance), who isn't currently a user in any SD project. How do they get access to only Project 2? The (unfortunate) answer is that they have to be added manually, which then sort of defeats the purpose of sign-ups (within multi-SD instances; sign-ups obviously function as intended when you allow "Anyone" permission, say in the case of a single SD instance).

There is some additional system behavior that occurs when a project is open to "Anyone", the project auto-adds all existing customers in any project to the target/Anyone project. I feel that if it were at least possible to manage this aspect, we might be able to achieve a desired functionality, but based on the response I received from Atlassian (see above post), that's not in the mix as of current.

Alternatively, let's say I have Project 3 - which is set to "Anyone" access. What happens is that all customers (A, B, C, D, X, Y, & Z) are immediately added as customers in this project. Then, customer M is able to request access via a sign-up. Customer M should really only have access to Project 2, but this isn't feasible, because they also have access to Project 3 due to Atlassian default adding all customers to the project. So there are two issues:

1. Customer M still doesn't have access to Project 2 (which now requires a licensed user to manually add them to Project 2) and
2. Customer M does have access to Project 3 and ideally, shouldn't (at least not without taking some extra steps to discover it, since it is open to "Anyone"; if a licensed user were at least able to remove them from the customer list of Project 3, that would be a start, knowing full-well that they may find the Project 3 portal of their own accord)

[Reggie Hunter]

Using: Service Desk Cloud Version

I have successfully figured out how to fully isolate all of our customers from one another in the Help Center.  Here's how I did it.

• Go to your project's settings -> Customer Permissions
• In the "Who can access the portal and send requests to The [Customer Name]?" section, use the "Customers my team adds to the project" option

Doing this will now hide this project from the pool of projects in the Help Center.  Once I did this for all customers, this meant that there were no projects visible now for my test user.  

Next, on the Customers page, add an 'Organization' (pretty much a group of people) to the project (if you don't have one already).  Now, any users that you add in this organization will only be able to access to the portal of the project(s) that they are included in.  

I really hope this helps someone out there as this has been a customer service nightmare for almost a year now.

[Deleted user]

That's correct. Unfortunately, that may not be scalable in all instances (which was my original need - an unidentified pool of potential users).

[Jack Brickey]

@[deleted] , you certainly win the prize for research and detail here! :-)

i will attempt to assist.

• First, for sure if you choose “anyone” for a project under customer permissions then any customer from any client could become a customer of that specific project. However, that should have no impact on access to project that have “customers my team adds.
• do I understand correctly that you have a single JSD instance and you have chosen to implement a project per client? Or do you have multiple clients per project?
• are you using Organization feature? If so I assume you have grouped customer per client into orgs.
• have you inspected the listed customers under each project to ensure you are not seeing customer bleed between projects/clients. This includes not having unwanted orgs in a project.
• regarding your info above on JSD permission scheme I do not understand how/why Service Desk Customer are showing here at all. Permission Scheme is not for customers at all. Rather Customer permissions is to be used for all customer permission config.  For sure customer would not and should not have all the permissions shown above. Maybe I am misreading this?

[Deleted user]

Hi @Jack Brickey

RE: Your questions:

First, for sure if you choose “anyone” for a project under customer permissions then any customer from any client could become a customer of that specific project. However, that should have no impact on access to project that have “customers my team adds.

Correct. The issue is basically that I can't establish more then one or two projects to allow for granular control over who can access a customer portal in this manner. Our clients simply have too many potential users. I'd like to keep projects where my team is having to add users to an absolute minimum.

do I understand correctly that you have a single JSD instance and you have chosen to implement a project per client? Or do you have multiple clients per project?

We have one instance of all Atlassian products in use (Jira, Jira Service Desk and Confluence). Within our Jira Service Desk, there are multiple projects, one per client (and an "internal", test project). I don't feel that having multiple clients rolled into a single project (and then using organizations to control access) provides the necessary level of granularity we need for some clients (for some clients, we have ticket groups, and for others we don't). However, I fear that I may have to "hack" our test project to be the one project that does allow "Anyone" access, at least in order to generate a sign-up link (see original post RE: "dummy" portal).

are you using Organization feature? If so I assume you have grouped customer per client into orgs.

This is dependent. Given that we have so many potential users, we would have no clear way to identify their respective "organizations" within the client's structure (See above RE: single project). In some projects, if we know there are certain users who need to share requests (typically by the primary client contact verbalizing a request to do so), we do create an organization of those users (e.g. "Accounting" for Accounting Users). Given that in my desired experience, any user could potentially sign-up for an account, this would then require manual effort to assign users into organizations, which isn't necessarily a requirement (unless it becomes one based on JSD's functionality in order to achieve my desired experience; i.e. each project has at least one organization for the entirety of the client (e.g. Organization = Client); this may be used as a "safety net" to prevent the "bleed" you mention in your next question).

have you inspected the listed customers under each project to ensure you are not seeing customer bleed between projects/clients. This includes not having unwanted orgs in a project.

I'll need to do some more extensive testing now that I have all of my projects established. I was hoping to have an answer to this before opening up my projects to external users, as I don't really care for egg on my face. I've tested with a few accounts, but I'll need to setup some additional e-mail addresses to perform adequate testing. I only have one project that is currently exposed to external users, and that is for a small client that is able to be actively managed. However, in testing my additional projects, I was given pause based on my questions above prior to expanding the roll-out.

regarding your info above on JSD permission scheme I do not understand how/why Service Desk Customer are showing here at all. Permission Scheme is not for customers at all. Rather Customer permissions is to be used for all customer permission config. For sure customer would not and should not have all the permissions shown above. Maybe I am misreading this?

My understanding is that this was done upon initial creation of a JSD project (by default). As outlined in this article, I do believe these permissions to be correct. Presumably, just by nature of the user registering on a service desk, they would fall into the "Service Desk Customer - Portal Access" access category. If these permissions are not associated with this access category (or some other manner by which Service Desk customers would be granted such permissions - i.e. by role or group), then the Service Desk customer would not be able to perform any functions on the portal.

[Deleted user]

So, after additional testing this morning, I've reached the following conclusions:

1. In order to actually allow for Customers to create their own accounts, you have to get them to a sign-up page. In order for the sign-up pages to actually function, you have to have some combination of permission settings (i.e. "Anyone can send a request without logging in") that allow anyone to access. Otherwise, you receive an error message indicating:

This seems pretty contradictory.

2. Even if I were able to get a user signed-up magically, there does not appear to be a direct way to allow them to only sign-up into the respective project, so they would default be added to any/all projects allowing "Anyone" access. Then I would have to manually go and add them to a given project (and remove them from others; note: this does not work for projects allowing "Anyone"). Even if I provide an explicit sign-up URL specifying a certain portal, by nature of "Anyone" access in projects, they would be added to those projects, not necessarily the specific portal's sign-up URL project.

Surely this cannot be as intended. I'm very inclined to believe I'm missing something in my configuration, but given all of my trials thus far, I'm beginning to come around to the possibility that this functionality is not supported by JSD, which is frustrating because one would easily infer this functionality to exist by the nature of having multiple projects with dedicated configurations.