From user being incorrect assigned as additional contact and not primary contact

[DBachen]

We’ve had several situations recently where the sending email address is not being recorded as the contact of a ticket. Instead, they are being added as an “additional contacts” and the contact remains empty.

Here’s a message flow where that happened:
17423242137890a

Looking at the original .eml, I don’t see anything strange like the sender included themself on the to or cc line, so they shouldn’t have even been seen when those values were iterated over.

Any thoughts on what might cause this to happen out of order?

[travis]

Thanks for posting this and thank you especially for including the history ID.

I reviewed the logs and I see that the following steps were taken:

1. MSPintegrations created a ticket and associated contact id=30683083 to the ticket as the primary contact, and contact id=30686453 as an additional contact.
2. MSPintegrations iterated over all contacts to ensure they were added as contacts. It attempted to add contact id=30686453 as an additional contact, but the Autotask API rejected that call (correctly) because the contact was already present as an additional contact.

As far as I can see in the logs, MSPintegrations never removed the primary contact from the ticket.

I then used the Autotask API to look at the ticket and the additional contacts on the ticket. I see that the ticket has no primary contact, and I see that the initial primary contact is now an additional contact on the ticket.

Is there an email in your history that was processed after this email in which MSPintegrations updated the ticket? I wonder if MSPintegrations moved the primary contact to an additional contact when a different email arrived for that same ticket.

[DBachen]

Let me see what I can offer. That scenario aligns with what I see in the Ticket History. It looks like the cc’d user replied to the ticket.

Now depending on how the received the first “we created your ticket” notification, she could have either been replying to that OR since she was cc’d directly in the beginning, she may have been replying to the initial sent message, not the thread.

We can see in the history that after her reply the contact was replaced to the null value by the API, so we just need to align the “how”.

Looking at the eml (since we attach that), should give us the clue as we’ll see the message before processing.

It does look like she replied to our notification email.

Note: Even though they were primary/secondary, the outgoing AT message put them all on the “to” field and doesn’t put them on to/cc the way a human would.

This should hit the “update ticket” portion of the rule, then the add additional contacts portion.

You can see the rule setup yourself, so I don’t need to put all the details here. Based on the fact that the contacts are now all on the “to” line, it would be Step 2/Sub-Step 3 which is putting the “additional” to’s as “additional contacts”… probably meant to deal with that INITIAL email which has no cc’s (e.g. to: [email protected], [email protected], [email protected] )

In this case, this is a reply which has them all on the “to” line.

If you were doing this manually and you tried to add the same contact to the contact which was already additional, AT removes it from additional. The inverse would be, AT sees it being added to additional so it’s removing it from primary.

So your solution would be how to fix the rules so that the shared add additional contacts flow understands not just the contact is found BUT whether the contact was already ON the ticket. We can short circuit adding any contact which both a) exists and b) exists on this ticket. Users sometimes swap to/cc on their end (or their email programs does it), so there are likely other scenarios which could cause it fall into this trap.

Unless our notifications are something special, or our rules are missing that check that you might have added to others, I would think that others would have the same problem (didn’t notice?)

[travis]

Can you locate the second email in your MSPintegrations history? That would show where MSPintegrations “moved” the contact, and I can provide a specific solution to stop that from happening.

[DBachen]

@DBachen

17423242137890a

Here’s the whole flow:

1. 17423242137890a – original ticket opening
2. 17423247520470w - reply from the “additional contact” ← this is where we believe the swap happened
3. 17423932175740e - 2nd reply from additional contact
4. 174256493232002 - 3rd reply from additional contact

3 and 4 probably have no impact because the swap already happened and once the update ticket is fixed, it should fix it for all of them…

[travis]

Hi @DBachen ,

Step two is indeed where the primary contact of the ticket was removed and added as an additional contact.

The fix for this is straightforward and simple.

In the step when you iterate over the contacts, add an expression so that the found contact is only added as an additional ticket contact if the found contact ID is not equal to the ticket’s contact ID.

In your rule, this would be in two places: step 2.3 and 3.3. Change the expression and add this stanza:

By making this change, MSPintegrations will not try to add as an additional contact the ticket’s existing primary contact.

Let us know how this works.

[DBachen]

That looks like a reasonable change. Problem is that when I try to do the not equal to, its defaulting to a string match and not and int match, so it doesn’t show the fields properly. Was something not stored properly in an earlier rule entry or did I miss a step?

Screenshot shows as I am entering it, not when completed, but you can see how it’s beginning to create it.

[travis]

You will need to click the padlock to the very right of the field.

That will change it to a pull-down for you to select it, and it will remove the quotes from the rendered query so the query is not a string but a variable.

[DBachen]

Thanks… I need the expression line to be unlocked elsewhere, because we were doing a pattern match on the domain, and hadn’t thought to then lock it back again.

So let me ask this… Wouldn’t this have been a problem since the beginning and for all AT users, not just me, if AT always combines everyone on the “To” line? or is it just interaction with that user/org/email client somehow?

Just wondering how large of an issue it is and maybe we just hadn’t noticed it earlier.