Troubles with Request Participants and Duplicate Accounts in Jira Service Management

Question

Hi everyone,

We're using Jira Service Management for internal ticket handling, and I've run into a couple of issues related to Request Participants and user accounts.

1. Request Participants not working when using email

When a customer adds someone as a request participant using their email address (e.g., jdoe@company.com), that person cannot see the issue in the Jira portal. However, if they add them by selecting the user by name (e.g., "John Doe" from the dropdown), it works fine, and the participant can access the issue.

The email address is the same in both cases, so I’m wondering:

* Why does it fail when using the email directly?
* Is there something I’m missing in how Jira identifies or links users?

I suspect there might be duplicate or unlinked accounts, but since these are portal customers, I can't see or manage their user profiles from the admin panel.

2. Users logging in with the wrong account

Additionally, when I invite a user (with a Jira license), they sometimes log in and are shown as a grey avatar with no permissions. They have to log out and log back in, after which their profile shows correctly (with initials and a colored background), and they can access the backend.

This makes me think that two accounts are being created with the same email address, possibly because they were previously portal customers?

Has anyone experienced something similar? Any tips on how to manage or merge these accounts, or how to prevent this from happening?

Thanks in advance!

Izan Romera Almansa · Answer

Hi Aaron,

Thanks a lot for your reply!

Regarding the Request Participants issue: all the users involved are portal-only customers. They register themselves using their email addresses from our company domain, but they are not licensed Jira users (at least not to my knowledge). When they try to add a participant by typing the email address directly, it seems Jira doesn't properly link it to the existing customer account, even though the email is correct. However, if they select the user from the dropdown (name + email), it works fine.

So yes, I suspect there might be duplicate or unlinked customer accounts, but since they’re portal users, I can’t see or manage their profiles from the admin panel. Is there a way to view or manage these customer accounts more directly?

As for the gray avatar issue when assigning a license: I believe you're right. These users probably had a portal account first, and when I later invited them as licensed users, Jira may have created a second account instead of upgrading the existing one. That would explain the avatar and permission issues until they log out and back in.

Do you know if there’s a way to merge or clean up these duplicate accounts, or at least prevent this from happening when upgrading a portal user to a licensed one?

Thanks again for your help!

Best regards,
Izan

Aaron Williams · Answer

Hey @Izan Romera Almansa

Could you tell me a little more about the customers in your instance?

Do you allow customers to create their own accounts? Do you use managed accounts for customers?

One of the issues you mentioned about an avatar changing colour is usually indicative of the account being different.

Picking a user by email address, if there is a duplicate may cause the issue, as it may default to one every time. (And in your case it seems the wrong one) whereas if you select the user directly you have more chance of the correct user being selected as it will use the user ID.

I would take a few problem users and check their profiles that are licensed. And check these accounts against the access / customer lists in the project directly. I suspect you are correct, duplicates causing havoc.

I would remove the customers accounts that aren't licensed if you find them. The best way to stop this is to not allow users to create their own portal accounts, but you would need to account for this and allow users to request access in some way.

Let me know what you find, and I'll try and be of more help.

Thanks,

Aaron.