We have a situation where sometimes an email comes into the wrong hosted mailbox. Normally the message goes into a custom mailbox that is setup to be “org specific”, i.e. the default org is dedicated to them. Sometimes they email the wrong email address and the wrong rules start processing.
Is there a way to stop a message from processing on one mailbox and “resubmit” it to the other one?
I want to check for the incoming domain of the sender, and if it equals “example.com” then stop processing, and put it into processing for the hosted mailbox [email protected] instead.
Just didn’t know if there was any functionality to start it down a different path, or to make it’s next step be somewhere else.
We currently don’t offer a way to move a message from one mailbox to another or to resubmit it into a new process. Can you tell me more about how the message ends up in the wrong mailbox? Is the user sending it to the incorrect address, or are there overlapping addresses in MSPintegrations causing the wrong mailbox to pick it up?
They are supposed to send in requests to a dedicated mailbox: [email protected]
This is because they have 3 different domain names for their email. Sending it into the dedicated mailbox ensures that the users are created on the correct account. The organization only allows for 1 domain to be associated with it.
However, sometimes they send the email (or cc someone) to our: [email protected]
If the email contains the domain which matches the org e.g @userdomain.com, then its fine, but if its @userdomain2.com or @userdomain3.com, then the user gets created in the default organization.
I was hoping to identify those 2 extra domains and kick the back to the beginning of the funnel.
Since I can’t do that, the next step was to identify them and have some dedicated rules that mirror the normal flow except I’d have to use the create object to create the tickets directly in the proper org, and then set a flag which tells the rest of the rules to ignore them.
That’s what I was planning on having to do.
What I just wound up doing instead was to setup AD sync within AT for them. That way all of the users are preexisting and they will match correctly no matter what mailbox that they are sent into.
That may not always be an option, so if I need to, I’ll fall back to the other method.
This might be a very simple fix. The Autotask Create Ticket action in MSPintegrations has logic to check for a matching domain in the web address field on the account as well as on the Email2AT Domains user-defined field on the account. If you modify the account so that the Email2AT Domains user-defined field contains @userdomain2.com @userdomain3.com, the workflow should accurately associate new contacts with that account no matter which domain they send from.
That’s good news… I see the UDF which must have been created at one point, but it was hidden on the standard client form and didn’t know that existed… Missed that in the docs (is it there?)
Now that I’ve enabled it, I can see it and add the extra domains.
Where does that Email2AT Domains matching magic happen? Does that just happen automatically behind the scenes?
I search the community and see where another user mentions that UDF search by looking at the history, so that would imply it happens by default all the time. Maybe there is just a better way to expose that feature? You might have covered it during onboarding but I don’t see anything now (maybe I’m just blind).
That’s great feedback - please keep bringing things up if we’re lacking in areas.
That “magic” only happens within one specific Action: Autotask Create New Ticket. That particular action has a lot of business logic bundled up to facilitate creating a ticket and associating it to an email address. The docs here include information on that UDF, but I agree that it’s a bit buried.
