Most scalable way to have many external clients in JIRA

[Ben Weisman]

Hello,

   What's the most scalable solution to having 20-30 external clients have access to one JIRA system? They can't be allowed to see other clients' tickets and the # of clients in the system will grow over time. But they need access to the system to be able to collaborate on their tickets with us in a holistic fashion,

Thanks.

[Dirk Ronsmans · Accepted solution]

Hey @Ben Weisman

You posted this in the JSM section so I'm guessing your clients will be external users that work thru the portal? Or do you require them to have access to specific Incidents/Requests/Changes?

If it's the portal then they won't see each other tickets by default. You can group the client's users in organisations so they can share their tickets amongst themselves but not outside their own organisation.

what they will be able to do on those tickets will be very limited tho, a couple of state transitions and comments.

If they need the full blown experience they will all need an agent license and you can limit their view using "issue level security" which can be set dynamically based on a field value.

Could you maybe elaborate a bit on your use  case on what type of project they would be working in, what type of tickets and what kind of work your clients would do in your system?

[Ben Weisman]

@Dirk Ronsmans Thanks for your reply. I think they will need more access than just a external portal. So let's assume they're more like "internal" users. What would be my best option?

[Ben Weisman]

Hey @Dirk Ronsmans just following up!

[Dirk Ronsmans]

@Ben Weisman ,

Well you got a few options here.

1. If they really need full JSM type of access (being assignee, seeing SLA's, being able to transition issue,..) I fear you'll have to provide them with an Agent license.
2. You could duplicate their tickets to a Jira Work Management or Jira Software project, they'd still need a license but it's a cheaper one :) and have them work on that with some Automations to sync data back and forth?

Like I said it all depends on what access they need. I'd start with really categorizing what they need to be able to do. As a client on a JSM project the portal should be enough to do some simple transitions/provide feedback and possibly with the help of some addons provide more insight in to their tickets (I'm thinking something to show SLA's on the portal and/or some reporting app)

If they really need to work on the tickets I'm afraid you are pretty much stuck on getting them a JSM license but that would explode your subscription bill fairly quickly as well as adding the risk of exposing your internal/other customer data to clients.

So before jumping in to anything my advice would to:

1. Find out what they really need to be able to do (and if it is more than the portal if there is another way to do it)
2. Start of with a small feature set, it's always easier/better to give them more over time than to take things away.

[Ben Weisman]

Thank you @Dirk Ronsmans 

Can you give me a bit more info on the best way to set up issue level security assuming they do need a full JSM license? We'd want them to only be able to see work related to their specific project.

[Dirk Ronsmans]

Sure,

If you have multiple projects you gotta take in to account to block their access on the other projects first (so make sure you don't put them in any groups that have default access to a project and make sure you don't just have the "application access" role as a default permission)

Within a single project you can set up issue level security:

https://support.atlassian.com/jira-cloud-administration/docs/configure-issue-security-schemes/

There it depends on how you want to do it. I would use either the assignee or a group picker field to set up what they can see.

Depending on the rest of your project setup you could do a single issue security level (which you set as default) and then use the group picker/assignee/user picker field to set "who" can see these issues (and also a specific group that can see all issues (which would be your internal users)

I suggest reading that documentation and giving it a go :)

[Ben Weisman]

Thanks again @Dirk Ronsmans this is super helpful. One question about doing this as a single project. How would I be able to easily group tasks by client? Typically I'd think about using components or a custom field but this would potentially allow for other clients to see the options within that field and therefor see the entire client list? That is why I was thinking multiple projects might be best.  Any workaround?

[Dirk Ronsmans]

Thru the portal you can group them in to organisations and that will be taken over on the ticket. 

If they don’t use the portal but with a JSM license, you might be able to leverage Insight (if you are on premium) and do some in place filtering. 
Also a free text field which you populate thru automation might be a possibility.  

if they really aren’t allowed to see the values all I can think of is Insight where you could use a specific object type (like a customer or contract) and only have them select the values where they are known on..

[Ivan Garcia _Appfire_]

Hi @Ben Weisman 

I also consider that the portal should be a good option for simple transitions and providing feedback. Combining it with our addon Dashboard Hub for Jira could satisfy your needs, allowing you to share dashboards with each customer directly on the Customer Portal. This way, you can effectively and easily reports on SLAs.

You can see an example of a shared dashboard or learn more about this feature here.

Other features include +70 gadgets, pre-defined templates, external share, custom charts, different chart types, and more.

Hope it helps :)

Iván García, Product Marketing Manager

[Ben Weisman]

Thank you @Dirk Ronsmans ! Last question I promise. I can't seem to find where i can dynamically set the security level based on field value?

[Dirk Ronsmans]

Setting the level is either by setting it as the default level, manually or thru automation. 

It is within that level that you say ‘who can see issues with this level’ and that who can be a group picker field (which can be different for each ticket with the same level)

Hope that makes sense :)