Vendor Emails into MSP

Help & Questions
1

Hi,

We receive quite a few vendor emails where we have had to raise tickets on our customers behalf, instead of them going into the 0 account, ideally I would like them to go into the ticket that we have on our system.

I though that if we had a UDF called something like “Vendor Ticket Ref” and the engineer put the reference of the third part ticket into it, MSP could search the UDF to see if there is a match.

I could obviously do a query for each vendor specifically but we deal with so many it would be huge.

Perhaps a query that would extract any number in the subject greater than 5 digits and search the UDF for that number?

Any ideas appreciated.

2

Did you ever make any progress on this? Extracting a portion of the incoming message and then looking it up against the UDF is a good way to do it. You can also look at the incoming message’s email address to identify vendors and combine that with the UDF reference. That’s helpful if you have more than one vendor with similar ticket IDs.

Going to give an example of the workflow that you might use based on how we do it.

For example, if your “UDF: Vendor Ticket Ref” didn’t just store the ticket number, but something like “ABC-{TicketNumber}”.

Then, on the incoming processing, create a rule to process the incoming message.

  1. Check if the incoming email address = “[email protected]” and store the value as custom.IsVendorA
  2. Repeat step 2 for each of your vendors, but store each result as custom.IsVendorB, etc. This gives you a proxy for a true/false boolean, allowing you to make one long rule with multiple checks in it
  3. Parse the ticket subject/body for the ticket reference and store it as custom.ticketref (e.g. 00123.2025.04.30). Set the condition to be custom.IsVendorA != null
  4. Render as text and store it as custom.vendorref (e.g. “ABC”). Set the condition to be custom.IsVendorA != null
  5. Repeat step 3 and 4 for each vendor, just changing the condition it is checking… You do this for each vendor, because they will each have a different location in the subject/body for the ticket number and you will need different regex to find it… You always store the result in the same custom.ticketref, so that it will have a single value at the end that can be used for your lookup. You also store whatever you want to use for the vendor prefix.
  6. Render the text {{custom.vendorref}}-{{custom.ticketref}} and store the new value as custom.vendorlookup

For a sanity check, you would probably check if custom.vendorref or custom.ticketref is empty before you tried to combine them in 6 - effectively meaning that your previous parsing/matching steps failed for some reason. I like to do this as the last step and set render as text ‘True’ and store as global.Unmatched (given you a fake “boolean” you can check as empty)

Now you have a variable called custom.vendorlookup that would like like ‘ABC-00123.2025.04.30’ that you could use to find the ticket whose “UDF: Vendor Ticket Ref” equaled that.
If you can check if the globalUnmatched was empty as your condition, so you only go looking for a ticket if there is a match… if it isn’t empty (meaning it was unmatched), do something like create a ticket manually and specify its “unmatched” somewhere in the title or body - which is a clue for the tech to go and fix it later.