One person, two JSM customer accounts: what actually clears the duplicate after an email change
Gabriela Perdum
Author
11 min readAugust 15, 2026
Key takeaways
JSM has no in-place email change for a customer. Atlassian's own admin page lets you edit the full name and nothing else, which is why editing the customer record never touches the address.
Removing the customer from the service project cannot fix it. I measured two duplicate accounts that belonged to zero service desks and still filled the user picker.
An empty result from the find-their-tickets JQL is not evidence. The endpoint that used to error is gone (HTTP 410), and the one that replaced it returns a silent empty list for an account that does not exist.
Reassigning the reporter can fail with a 400 that blames the screen. I measured the field present on the edit screen, which rules that explanation out and leaves the Modify Reporter permission as the documented cause.
There is still no way to merge two Atlassian accounts. ID-240 is Future Consideration with 2,839 votes, open since 2015.
One of our customers got a new email address, the domain changed (aaa.com to bbb.com). We updated the customer record within the respective space. Now, when we create a new issue and search for the user in the reporter field, it appears twice, with both old and new email domain. How can this be fixed. We don't want the old address to appear obviously.
Every clause there is a step in the same trap. The customer record was updated, and updating it did nothing to the email. The picker shows two rows because there really are two accounts. And the thing most admins reach for next — taking the old one out of the project — is the one action that provably cannot help.
I answered that thread in July. What follows is the part I could not fit into a forum reply: the mechanism, and the measurements I ran on my own test site afterwards to check the advice everyone gives for this — including my own. Most of it held up. Two steps on the fix path have a trap in them that nothing warns you about, and one route that solves the problem outright never came up on the thread at all.
Why the record edit did nothing
Jira Service Management has no in-place email change for a customer. That is not a gap in the UI you can route around with an API call — it is the shape of the product.
Atlassian's admin documentation for portal-only customers is unusually clear on this if you read what it does not offer. The page covering what an admin may change is titled "Edit name for portal-only customers", and full name is the only field it exposes. There is no email field anywhere in that flow. So an admin who opens the customer record, corrects what they can see, and saves has genuinely done everything the interface allows — and the address is untouched.
Meanwhile the person on the other end has a new mailbox. When they next arrive at the portal on bbb.com, that address does not match any existing account, so it becomes one. Now there are two customer records for one human being, and the reporter field is doing exactly what it is supposed to do by showing you both.
I want to be exact about what I proved and what I am repeating. I did not reproduce the sign-up half — I created both accounts directly, which lands you in the same end state without waiting for a real person to log in twice. The causal half, that a new address produces a new account, is the documented behaviour of customer account creation and is what the Community Champion on that thread described from their own experience. Treat the mechanism as well-attested; treat the end state as measured, because that part I ran.
Telling the two apart in one call
Before fixing anything, you need to know which of the two rows is which. The picker shows the same display name twice and distinguishes them only by the email suffix, which is fine until you are holding two account IDs in a script and cannot remember which is the survivor.
The discriminator is accountType, and it is on every user record:
A portal-only customer comes back as "accountType": "customer". A full Atlassian account comes back as "atlassian". That distinction matters more than it looks, because it decides which of the fixes below is even available to you.
There is also an eyeball tell. Every portal-only account I created carried an account ID in the form qm:<site-uuid>:<user-uuid>, while ordinary Atlassian accounts on the same site are the familiar <digits>:<uuid>. Atlassian does not document that format, so I would not build a script on it — but when you are staring at two IDs in a terminal, the qm: prefix tells you instantly which one is the portal-only record.
The trap: removing them from the project
This is the step that costs people an afternoon, and it is worth being blunt about why.
Removing a customer from a service project unlinks them from that project, which is all Atlassian's own page for that action claims it does. The account itself lives at site level, and the user picker reads from site level, so the row you just removed keeps appearing.
I measured the strongest version of this. On my test site I created two customer accounts with the same display name on different domains, and I never added either of them to a service desk — they belonged to zero service projects. Then I queried the picker:
Two rows, from accounts with no project membership at all. If zero service desks is not enough to keep an account out of the picker, then removing it from one service desk was never going to be either. Project membership and identity are different layers, and the picker reads the lower one.
Warning
This is also why "I removed them and it still shows" is not a bug report. The removal worked. It simply was not the operation that governs what the picker returns.
That measurement was on the REST endpoint behind the reporter field rather than on the rendered agent view, so treat it as a statement about the API. It matched what the original thread reported from the UI.
The route the thread never mentioned
Neither answer on that thread named the option Atlassian actually documents for this situation, and it is the cheapest fix available — provided you catch it in time.
Atlassian's KB "Changing a Customer's Email Address in JSM Cloud" (Cloud only, last updated 25 September 2025, read 15 August 2026) gives two methods. The second is Migrate to Atlassian account, from Atlassian Administration under Products, your site, Jira Service Management, Portal customers, then the three-dot menu on the customer. Once the customer holds a real Atlassian account, they manage their own email at id.atlassian.com and the whole problem stops being yours.
The migration page is worth reading before you click, because it carries three facts that decide whether you want this:
Fact
Consequence
It deactivates the portal-only profile and migrates their requests to the new account
The history follows them, which is the point
Processing takes up to 10 minutes
Not instant, so do not queue a second action behind it
The old profile stays visible as Inactive and you cannot un-migrate it
One-way door
4 rows × 2 columnsHeader row enabled
It also requires an organisation admin in the centralised experience, and it is not available in the Atlassian Government environment.
Here is the honest limitation, and it is the one that decides whether this route helps you: none of those pages state what happens if an Atlassian account already exists on the target address. That is a documentation silence, not a documented failure — I am not going to tell you it breaks, because I could not test it without a second organisation. What I can say is that the collision is exactly the situation the thread was in. The customer had already signed in on bbb.com, so that address was already taken by the second account. Migration is the fix for the window before the duplicate exists. Once you have two, you are in the cleanup below.
Cleanup, and the two traps inside it
The standard cleanup is the KB's Method 1: move the old account's tickets onto the new account, then get rid of the old account. Both halves have a trap.
Trap one: an empty JQL result is not evidence
The KB tells you to find the old account's tickets with a reporter query. That advice is correct — I tested both forms and both work, including for a portal-only customer:
Both returned the ticket I had planted. So far so good. The problem is what happens when the query does not match.
Atlassian removed the old search endpoint. GET /rest/api/3/search now answers with HTTP 410 and a pointer to CHANGE-2046 — the same pattern as Bitbucket answering a dead credential with a 410 rather than a useful error, where the status code is the whole message and the tooling around it has not caught up. The replacement, /rest/api/3/search/jql, does not validate the user at all:
No error. No warning. I also ran that query through POST /rest/api/3/jql/parse?validation=strict, which is the endpoint whose entire job is to tell you a query is wrong, and it came back with an empty error list and an empty warning list.
So a clean empty list means one of two things and gives you no way to tell them apart: the account has no tickets, or the string you pasted resolves to nothing. Approximate counts show that real accounts genuinely do resolve — the one with tickets moves the number — and they also show exactly where the signal runs out:
Query
Approximate count
reporter is not EMPTY
8,495
reporter != a real account with tickets
8,459
reporter != a real account with no tickets
8,495
reporter != an account that does not exist
8,495
5 rows × 2 columnsHeader row enabled
The last two rows are the whole problem. They are identical, and one of them is a typo.
The fix costs one call: prove the account resolves before you trust the ticket list. Fetching a well-formed but nonexistent account ID gives a 404 and "Specified user does not exist or you do not have required permissions", while a real one gives 200 — I checked both. Note that the 404 text covers two cases at once, so on a project you cannot browse, treat it as "not proven" rather than "not there". An empty result you have not earned is how an old account gets deleted with live tickets still pointing at it.
Trap two: the 400 that blames the wrong thing
Once you have the ticket list, you reassign the reporter. On my test site that failed, and the error sent me in the wrong direction for a while:
json
1{"errors":{"reporter":"Field 'reporter' cannot be set. It is not on the appropriate screen, or unknown."}}
That message names the screen. So I checked the screen — and the field was on it.
Atlassian's KB on a user not being able to change the reporter lists exactly two causes, which makes this a closed set you can eliminate against. Cause one is the field: "If the Reporter field is not added to both the Edit and View screens for a project, Jira users can't change the reporter." Cause two is the Modify Reporter project permission, which is separate from Edit Issues.
I ruled out cause one by reading the configuration rather than trusting the error. The project's screen scheme maps a single default screen, which is the one Jira uses for create, edit and view alike, and listing that screen's fields showed reporter present. So the field is on the edit screen and the view screen, and the sentence in the error is simply false for this project.
That leaves cause two, and it is what the permission endpoint reported:
EDIT_ISSUES true, MODIFY_REPORTERfalse — on the same project whose edit screen carries the field.
I want to be straight about the strength of that. This is elimination against Atlassian's own two-item list, not a direct manipulation: I tried to prove it the better way, by granting only Modify Reporter and re-running the identical write, and my test site refused with "Changing permission schemes is not allowed on the Jira free plan." So the screen explanation is measured false here, and Modify Reporter is the remaining documented cause rather than one I isolated by flipping it.
The pre-flight check that actually answers the question is editmeta, because it reports what you may write on this issue rather than what exists in the configuration:
If reporter is absent from the fields object, the bulk change will not work either, and you should go and look at Modify Reporter before you go anywhere near screen configuration. This bites hardest where the customer's tickets are spread across projects on different permission schemes, because the reassign then succeeds on one project and refuses on the next. Check the project type while you are there: the permission is called Modify reporter in a company-managed project and Edit reporters in a team-managed one, and that company-managed versus team-managed split changes the administrative surface far more often than people expect — it is the same divide that makes clearing a Done column a completely different job depending on project type.
While you are bulk-editing, the KB suggests deselecting "Send mail for this update", which is worth doing — nobody needs a notification per ticket for an administrative reshuffle. If you drive the reassign over REST instead, that switch is the notifyUsers=false query parameter, and it is a different mechanism from the one that catches people out when automation adds a comment and the notification goes out anyway.
Getting rid of the old account
With the tickets moved, the old account goes. This is an organisation admin job in the centralised experience (organisation or site admin in the original one), and there is no public REST route for it — Atlassian Administration, Apps, your site, Jira Service Management, Portal-only customers, then the three-dot menu.
You get two options, and the documentation is direct about preferring the reversible one: "If you think you'll need this customer at another point in the future, we suggest you revoke access" instead. Deletion is permanent.
After a delete, the doc states the customer "won't be searchable and selectable in user-picker fields", any picker field already holding them renders as Former user (Deactivated), and "no reference is kept on the account's email address". That last clause is the one to read twice if you were hoping to free up the old address for reuse.
I could not measure this half. Deleting a portal-only customer needs organisation admin in the admin console, my test credentials hold site-level Jira admin and no organisation API key, and I am not going to describe an outcome I did not observe. Everything in this section is Atlassian's documentation, read on 15 August 2026, and labelled as such.
The zombie record
There is a coda on that thread that I think is the most interesting thing in it. After deleting the obsolete account, the admin came back with:
However, even after removing the obsolete customer account it still appears in the drop-down when creating a new ticket. Why? Edit: zombie record disappeared after 12 hrs.
I cannot verify twelve hours — that is their observation, on their site, and I have no way to reproduce the delete side. But I can confirm the mechanism it implies, because the user directory index is measurably not live. I created a customer and polled both search endpoints until it appeared:
Somewhere between 23 and 27 seconds for a brand-new account to become findable, on an otherwise idle site, with the account ID usable in a REST call the whole time. The issue index behaved completely differently — a ticket I created was returned by its reporter query on my first attempt, seconds later.
So the user directory is eventually consistent and the issue index is effectively immediate. That is enough to say the picker can lag the account store in both directions, which makes a delayed disappearance unsurprising in kind. Whether the delay stretches to twelve hours, and what governs it, I do not know, and I would rather say so than dress up a 27-second measurement as an explanation for something forty times longer.
Practically: after a delete, do not immediately conclude it failed. Give it time before you start investigating.
What is still not possible
The question underneath all of this is usually "can I just merge the two accounts?" No. ID-240, "Ability to merge Atlassian accounts to a single account with secondary emails", was created in June 2015 and is still open — status Future Consideration, unresolved, 2,839 votes when I checked it on 15 August 2026. Atlassian's own description of that status is that it is a candidate for the longer-term roadmap that they are not working on now.
Eleven years and nearly three thousand votes is a clear enough signal about how long to wait. Unifying two accounts is an Atlassian Support conversation, not a self-service action, and for a single customer who changed jobs the reassign-and-remove path is finished long before a ticket gets picked up.
The short version
If the customer has not yet signed in with the new address, migrate them to an Atlassian account and let them change their own email. That window closes the moment the second account exists.
If it already exists, verify which account is which by accountType, prove the old account resolves before you trust its ticket list, check editmeta for reporter before you plan a bulk change, reassign, then revoke rather than delete unless you are certain. And do not spend the afternoon removing them from the project — I have the picker output from two accounts in zero service desks that says it cannot work.
Measurements in this article were run on 15 August 2026 against a Jira Service Management Cloud test site, using the accounts and projects described. Documentation claims are labelled with the page they came from and the date I read it. The twelve-hour figure is the original poster's observation and is not mine.
Clearing the Done column in Jira Cloud: company-managed vs team-managed
The manual Clear Done work items button is gone from team-managed boards, and company-managed boards never had it. They have something better, and I measured it: a released version empties the Done column for everyone in under 15 seconds.
