Does anyone have any insight into monitoring emails sent via APR?
We have a large number of service contracts and currently use APM to process groups of over 1000 AR invoices once a month. Unfortunately, we have found there are times that not all of the invoices get delivered. Factors like bad email addresses, flood control, and a variety of other issues result in invoices not always reaching our customers as we intend.
To address this, we have established a number of procedures and logic to ensure the invoices emails are delivered. One of the steps in this process is logging into APM doc-link administrator to review the status of Scheduled Tasks. From there, we can easily identify any failed documents and take necessary steps (like resend or fix customer’s email address and reprocess). I don’t see any straight forward way in Epicor to do this for APR.
A. left your server
B. reached the end server
C. actually reached a mailbox
D. were actually read
The bare minimum I do is that any automated email created in E10 is BCC’d to email account setup just to receive these. That way I at least know that the email generated properly (but no assurance that the TO or CC fields weren’t malformed).
This raises an interesting point. A return path header should be configurable for email from Epicor so that anything that bounces can be handled, as they occur vs seeking them out. Any thoughts @SAD? Is it already possible if anything from the code widget and hand coded?
My end goal is to provide the most reliable system so we can expect customers to pay their bills on time. Realistically, I think A-C are not asking much of Epicor.
If it didn’t leave the server, I need to know this and be able to resend it.
If it does leave the server, I need to know that it was delivered and any NDRs / replies need to go to our accounting group.
Not sure that there is. A large variety of things could be at play here though depending on how you send mail. Do you use a sending service like SendGrid, do you hit an on prem server and route mail directly, do you use mail connector with O365, do you email through O365 directly, do you have an on prem relay, do you email through a preprocessor that could add headers for you. There are a ton of ways to send and manage email, and realistically if your server doesn’t throw an exception trying to send an email, then your server logging on the email side should have all the answers you need at which point you could use something like zabbix to alert from logging when something goes wrong, but again depending on how you have your sending setup. 30 ways to skin this cat, and even if you could add return path that only handles a portion of the total chain.
I’d guess that “email receipts” were designed into mail systems, for this very thing. But once spammers and hackers started abusing them, they became obsolete…
“This is why we can’t have nice things”
Also, we use an external spam filter company. I’m not sure what it does when it receives suspicious mail, and holds off on forwarding it to our mail servers. If I never never approve or reject it, does the sender think it went through?
Anyway, I’m assuming if they don’t approve spam filtration, that is beyond my control. I can look at our email server log in O365 and see the date / time it was delivered if it comes to that
Are you using a local relay and using a mail connector with your O365 (if not I highly recommend it). If you are you can monitor the relay’s SMTP logs directly.
Just run it on your APM server. You must have a windows server that runs additional services outside Epicor. Again it’s only one piece of the puzzle anyways but would allow you to monitor and alert on the SMTP log from something like zabbix
To be fair I don’t think in the last 4 years of having O365 we have once had an issue with O365 and sending unless something global was occuring. So if it’s pretty regular that things are not making it through your email the relay may help with that. You can adjust flow rate and things that I believe can make O365 behave better as a whole when doing a mass send and will perform retries where Epicor and APM will not. @EarlGrei can confirm or deny that but I believe those are the sorts of benefits we utilize.
For the sake of argument, one could potentially look at the resulting SysTask record which typically includes the number of emails sent. It’s cumbersome and not a great approach, but might be useful in a pinch.
I already am breaking the invoice group down into one invoice per SysTask so that might prove useful. What field indicates the number of emails sent? Do you happen to know what causes the value to increase?
