We had ticket come through that generated (7) Soap errors, one for each image in the person’s signature. These are little social media icons, or the icons for the email/phone.
Here’s the link to the history - https://console.mspintegrations.com/#/email2at/advanced/history/17537257899100r
From the error, it makes it look like the contact doesn’t have the rights to add attachments to their own ticket.
In this particular case, the contact who sent in the message also happens to have an AutoTask technician login (not that it should matter, but wanted to point it out). We’ve definitely been able to have people from our own company open tickets, we just have a rule that ignores our own domain when adding new contacts to prevent our email addresses from being added to every other organization (standard exception that you had us put in).
Although this is a new signature with those images (as of about a week ago), another test email sent from my own email address (who is also a tech and also has an existing contact) worked fine just now. https://console.mspintegrations.com/#/email2at/advanced/history/17537294457310g
Let us know if you get a chance to review and what you find.
I am noticing that the console seems to be a little sluggish this morning… I’m opening up hosted mailboxes and then no rules will appear… or I’ll open a rule and no steps will appear. if I go back and try again and refresh it it usually works the next time, once it took 3 times. So maybe some performance issues which could have impacted the processing of that message at 2:05pm EST.
Thanks for reporting this! Autotask restricts impersonating resources and contacts when attaching entities to certain database entities. The system takes those restrictions into account, but we apparently missed at least one restriction.
We will review the logs you provided (thank you!) and modify the logic we use when creating attachments to mitigate this error.
Actually, after looking at the logs more closely, I’m not sure why Autotask rejected this. I see that one attachment was successful, and several others were not. I also see that MSPintegrations attempted to create the attachment impersonating a contact on the account (despite the error claiming otherwise).
I do see that the account was changed on the ticket after MSPintegrations created the ticket. I wonder if the ticket was edited to move it to the correct account around the time that MSPintegrations was adding the attachments. Are you able to review the ticket history to see what time the account was changed?
For his workflow, the user decided to email in to create the ticket (rather than just creating it in AT directly). Then, after it was created, assign it manually. So you may be on to something there.
And that’s what looks like happened. Since he was literally waiting for the ticket, the moment he saw it, he started working with it, but MSP integrations was still handling the attachments… Wow, he was fast.
The errors in the AT System log are all dated 14:05, including the attachment of the eml itself (which didn’t error)
Thanks for tracking that down… looks like a simple solution to tell the tech not to be so eager on changing the company or contact – OR next time, just create it in AT directly and save us all the hassle.
