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 ''. 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 ''. Now, when they send a reply email, TDX says that 'This message was proxied because the email address <> was not found on any active Customer or User in the system.'.

What happened here?





Tags user-creation email-monitor
Asked by Joe Allen on Thu 11/7/19 3:16 PM
Sign In to leave feedback or contribute an answer

Answer (1)

This answer has been marked as the accepted answer
Matt Sayers Thu 11/7/19 3:55 PM

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 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 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. 

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:

If there is anything else I can do to assist, let me know.

No feedback
Hi Mark, I'm confused a bit. Screenshot # 6 that I attached to this question shows the original email. In there it shows the email coming from not - Joe Allen Thu 11/7/19 4:00 PM
Hi Joe,

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
Thanks Matt. I'm going to take a closer look at the emails to verify this. It looks to me that all emails came from the same email address. However, I need someone to send me these so I'm waiting for that. Thanks and sorry for calling you Mark on my last email. - Joe Allen Fri 11/8/19 11:49 AM
Hi Joe,

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
Thanks Matt. I understand. Overall though, these email replies are getting to be a challenge for me to explain to others here. At first I thought there was an explanation but there are more examples of emails working and some not working. IThere are one or two each day and I can't keep investigating every one. I'm not sure what the long term solution is but in the meantime, we are losing emails and someone in our helpdesk has to investigate it when it happens. - Joe Allen Fri 11/8/19 2:01 PM