What is the best way to set up a customer when they are associated with three different projects?

Question

Hi,

I have a customer who is associated with three different projects. I have them grouped together all in one group but two different organizations. What do you think is the best way to set them up? Should I make 1 group consisting of all of the same customer accounts and then three different organizations, one for each of the three projects and name them accordingly? Is there any tool or a better way to set this up? Just trying to get someone's opinion on the matter.

Thanks,
Fahad

Lucas Modzelewski _Lumo_ · Answer

I was digging and it looks like turning customers into users is possible, without increasing license size

Customers need to be migrated into Atlassian accounts, as explained in this thread: https://community.atlassian.com/t5/Jira-Service-Management/Customer-group/qaq-p/1701572

So, with that in mid, I would probably go with matching groups & organizations for each customer.

(It probably could be even 'simplified' to only groups, but then it could trigger additional changes in JSM eg. default shares with organization, so in my opinion it wouldn't be worth it.)

Fahad Akhtar · Answer

Hi Lukasz,

My company uses JSM more like an IT tool to resolve customer tickets and issues. I invite these customers to Jira, but do not give them a license as we have a limited number. We only give licenses to internal folk. I add these customers to groups because if these customers are associated with other projects and something changes I can make the changes easily and it is a nice way to organize everything. I don't understand what you mean groups are only for licensed users. I have created groups and added customers to those groups, but the group only has customers, no internal folks. Please explain further.

Thanks,
Fahad

Lucas Modzelewski _Lumo_ · Answer

Groups are cross project - for licensed users (customers with portal only access cannot be added to groups)

Organisations are created within JSM project.

I would stick to organisations, but if they need to be involved with some software projects, then maybe I would think about adding some project role instead of using groups. It would be managed on project lvl similar to organisation, without admin needing to change group access if something changes.