Situation:
Jira is sending an email address: replica.assignee = issue.assignee?.email
And then DevOps is supposed to be resolving that email address to an iHubUser using a nodeNelper function: workItem.assignee = nodeHelper.getUserByEmail(replica.assignee?.email) //?: defaultUser
However, this fails when there are duplicates (as noted).
Is there another way to assignee the work item to the email, and not do a potentially conflicted lookup?
This is a known limitation with the nodeHelper.getUserByEmail function in Exalate: if there are multiple users with the same email (or, in your case, duplicate display names but unique emails), getUserByEmail will only return the first user created with that email. This is documented here:
So, if Azure DevOps has two users with the same display name but different emails, getUserByEmail should technically work—unless there are actual duplicate emails, in which case only the first user is returned. If your lookup is failing, it may be due to permissions, the user not being part of the project, or a true email collision.
Unfortunately, Exalate does not provide a way to assign by email without this lookup, as Azure DevOps requires a user object for assignment. The only alternative is to use the user’s unique key (if you have it) and assign via nodeHelper.getUser(userKey), but this requires you to have a mapping of emails to user keys outside of Exalate.
Key points:
getUserByEmail returns only the first user with a given email.
If there are truly unique emails, the lookup should work—check for typos or invisible characters.
If you have duplicate emails, you’ll need to resolve this in Azure DevOps, as Exalate cannot distinguish between them.
There is no built-in way to assign by email string alone; Azure DevOps expects a user object.
If you need to handle edge cases, consider maintaining a custom mapping of emails to user keys and using nodeHelper.getUser(userKey) for assignment. Otherwise, you’ll need to ensure email uniqueness in Azure DevOps for reliable automation.
We believe that this is BUG within the product, we have escalated to our Eng to investigate and find a solution.
In the meantime I have created a work around that you can apply to your incoming sync that will take of the issue and assign the ticket to the correct email even it they are duplicated.