creating new contacts
Hi there,
We turned on the 'Enable Requestor Creation' switch on our email monitor rule in one of our ticket systems.
Yesterday we got an email from a person with email 'anjali.ukrani@uwdeca.com'. But this person was in our identity management system with 2 different emails. For some reason, TDX used another email and created them with email 'a2ukrani@uwaterloo.ca'. Now, when they send a reply email, TDX says that 'This message was proxied because the email address <anjali.ukrani@uwdeca.com> was not found on any active Customer or User in the system.'.
What happened here?
Thanks.
Answer (1)
Hi Joe,
I can assist you with this matter. When TeamDynamix creates customer records from an email address, this is because it has not matched that email on any of the 3 email fields on any existing User or Customer record in your tenant. This email came in with the FROM address set as a2ukrani@uwaterloo.ca. That email was not in the system, so it created an account for that email because you enabled the setting to allow creation. I cannot say as to why it came in from the @uwaterloo.ca address, perhaps the user sent it from the wrong alias/domain in their mail client/device? But regardless, whatever the FROM address is on the email we received (in the actual email message headers), that is what is going to get used for matching and customer creation. We have no way to know on our end that the email came from an alias.
Secondly, reply tokens are "scoped" to the actual email address that is notified from the ticket. If the user replies back from a different address than the token is for, that is why that message comes into play. The below KBs talk about how reply-by-email work in some detail, so refer to those for more details.
https://solutions.teamdynamix.com/TDClient/1965/Portal/KB/ArticleDet?ID=34633
https://solutions.teamdynamix.com/TDClient/1965/Portal/KB/ArticleDet?ID=4124
https://solutions.teamdynamix.com/TDClient/1965/Portal/KB/ArticleDet?ID=566
The short answer is that we recommend only using a single address when communicating back and forth with TeamDynamix. If you are switching between email aliases/address domains, that is going to throw off the reply token and you will get those proxy situations.
This is definitely something we have heard about before from other customers. Typically they are requesting that we offer a way to disable the validation that replies are from the same address as the system notified from the technician. Some solutions suggested include only validating that the reply address has a token and is on a user account in the system. If that is the case, allow it through and mark it as the record the email address is for. This would pose some potential phishing issues though if someone were attempting to spoof replies as someone else in the organization (think pretending to be a director or CXO and granting authority to do something). That is why currently we err on the side of breaking the reply chain and putting in a warning when this happens. If you would also like to see this behavior changed, I would recommend submitting an enhancement ticket here to +1 market evidence for a change:
https://solutions.teamdynamix.com/TDClient/1965/Portal/Requests/ServiceDet?ID=2148
If there is anything else I can do to assist, let me know.
That is likely the primary alias or domain for the user in Office 365. My guess would be that Office 365 is smart enough to know that and display differently. If you actually opened the raw message headers I’m sure it would show the other address. That is really all the further details I can give you. TeamDynamix does not change the email address read off of the mail message. It is just reading the FROM header value in the raw details. If I had to guess the user likely choose the wrong alias to send from on their device. - Matt Sayers Thu 11/7/19 4:27 PM
It is no problem at all. The only thing I can say is that the email service just reads off of the headers it sees on the email. If this was a bug (and it could possibly be) many clients would be impacted by it. We are not currently seeing any other reports of inaccurate requestors being created at this time if that helps. - Matt Sayers Fri 11/8/19 1:49 PM