Best way to use/configure JSM projects for both external user & internal only users on same instance

[Jay Keck]

• We are running Jira Cloud with both Jira software and Jira Management licenses
• Currently we have several internal use only service management projects, which have  browse permissions of Service Project Customer – Portal Access
• All internal users have full Jira software licenses, not just customer licenses
• Only ‘my team’ can create customer accounts, customers can’t create their own
• We want to create a few service management projects for external users where they can see the few customer facing Service Management projects, but none of our internal projects. We would like our existing internal customers to keep the access they have now on the internal service management projects, but by default have no access to the customer facing projects
• We also would like the external customer to be able to create their own customer accounts to minimize IT’s management time. But, we don’t want to have any admin intervention required to grant or restrict rights to JSM projects since there could be hundreds/thousands of customers over time.

What’s the best way to accomplish this and keep an easily maintainable level of security/privacy, create a whole new Jira Cloud instance for the external users to access  their JSMs? It seems like the requirement for the external customer facing JSM’s to allow users to create their own customer accounts kind of rules out having these being on the same instance as internal projects since we don’t want to pollute our customer list with non-company users, it just increases the chance that an incorrect permissions setting on an internal project could expose data to external customers.

Any thoughts on how others have approached this would be much appreciated!

Regards,

Jay

[Jonas Ekström]

Hi,

We've done this with ~70 service desk projects in our instance (too many, but that's a different story based on a legacy decision..)

The permission "Service Project Customer – Portal Access" uses the project role "Service Desk Customer". You can choose who becomes a customer, it's on a per project basis.
For your internal JSM, choose a group that all your internal users belongs to for that role.

Next step is to set the Customer permissions under project settings
There are two options "Customers added by agents and admins" and "Anyone on the web"

For your internal JSM projects, use "Customers added by agents and admins"
For the external "Anyone on the web" which enables them to auto invite themselves either via signup in the portal or sending emails.

[Jay Keck]

Hello Jonas,

On the cloud our choices around customer permissions is a little different these are my 2 options

And our global settings are

We did this to not allow potential unwanted outsider from setting up a customer account on our system. If i switch my global setting to Yes, allow anyone to create an account will the 'anyone on the web' option appear?

We had done a test a while ago where we had the 'global setting to allow anyone to create an account and used a yahoo.com account to create a customer account and that account had access to the service desk portals and was able to create tickets, which is why we switched our setting. I will go back and confirm, but my take on that was if you were logged in with a customer account you automatically fell under the Service Project Customer – Portal Access category since we did not add the yahoo account to any project roles.

Regards,

Jay

[Jonas Ekström]

If i switch my global setting to Yes, allow anyone to create an account will the 'anyone on the web' option appear?
Yes, just verified that on my cloud test instance and it works.

And if you have your internal projects set to "Customers added by agents and admins" the external users won't see them at all.

If you have multiple "open" projects, then once a customer signs up for one, they seem to get access to all the open ones.

[Jay Keck]

Thanks Jonas, it sounds like I need to do some testing to make sure the behavior is what I need. I think I will have a hard time from our security folks allowing non-company accounts in our jira instance, even if they are just customer accounts, so I'm probably going to end up with a 2nd  dedicated instance with a few agents and  many external customer accounts