Tracing emails sent from BPM's

Yahoo Archive
1
My two cents is the biggest issue with undelivered emails is that (1) the
email address was incorrect, and (2) the other party got the email, but
claimed they didn't.

I found the biggest benefit in having emails CC'ed to a shared mailbox (or
blind CC'ed), is the ability for internal users to forward the original
email back to the customer when they said they didn't get it. That showed
that the email originally went out, and leaves the customer with the
perception that the problem was on their end, not our end.

Kevin Simon

-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Waffqle
Sent: Wednesday, March 09, 2011 8:55 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: Tracing emails sent from BPM's

CC will give you record that you sent them, but no info as to whether they
were delivered.

On Wed, Mar 9, 2011 at 8:49 AM, bw2868bond <bwalker@...> wrote:

>
>
> CC an in house address to collect the emails.
>
>
> --- In vantage@yahoogroups.com, "CarlH" <carl.heeder@...> wrote:
> >
> > In 8.33, does anybody have a solution to how can emails, generated by
> BPM's, be traced or confirmed that they have been sent and delivered?
> >
> > We send a confirming email to our customers and sales reps for each
sales
> order and need some sort of audit trail that the email actually was sent.
> >
>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
2
In 8.33, does anybody have a solution to how can emails, generated by BPM's, be traced or confirmed that they have been sent and delivered?

We send a confirming email to our customers and sales reps for each sales order and need some sort of audit trail that the email actually was sent.
3
You can check the logs on your email server, to make sure they aren't
rejected. Unfortunately there isn't really any way to make Epicor aware of
that.
You could use a real address as the 'from' address on the BPM email and
watch it for kick-backs.


On Wed, Mar 9, 2011 at 8:42 AM, CarlH <carl.heeder@...> wrote:

>
>
> In 8.33, does anybody have a solution to how can emails, generated by
> BPM's, be traced or confirmed that they have been sent and delivered?
>
> We send a confirming email to our customers and sales reps for each sales
> order and need some sort of audit trail that the email actually was sent.
>
>
>


[Non-text portions of this message have been removed]
4
Do you use exchange? If so log into the management console on your Exchange
Box and look at the outgoing queue.

*Jose C Gomez*
*Software Engineer*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>

*Quis custodiet ipsos custodes?*



On Wed, Mar 9, 2011 at 8:42 AM, CarlH <carl.heeder@...> wrote:

>
>
> In 8.33, does anybody have a solution to how can emails, generated by
> BPM's, be traced or confirmed that they have been sent and delivered?
>
> We send a confirming email to our customers and sales reps for each sales
> order and need some sort of audit trail that the email actually was sent.
>
>
>


[Non-text portions of this message have been removed]
5
CC an in house address to collect the emails.

--- In vantage@yahoogroups.com, "CarlH" <carl.heeder@...> wrote:
>
> In 8.33, does anybody have a solution to how can emails, generated by BPM's, be traced or confirmed that they have been sent and delivered?
>
> We send a confirming email to our customers and sales reps for each sales order and need some sort of audit trail that the email actually was sent.
>
6
CC will give you record that you sent them, but no info as to whether they
were delivered.

On Wed, Mar 9, 2011 at 8:49 AM, bw2868bond <bwalker@...> wrote:

>
>
> CC an in house address to collect the emails.
>
>
> --- In vantage@yahoogroups.com, "CarlH" <carl.heeder@...> wrote:
> >
> > In 8.33, does anybody have a solution to how can emails, generated by
> BPM's, be traced or confirmed that they have been sent and delivered?
> >
> > We send a confirming email to our customers and sales reps for each sales
> order and need some sort of audit trail that the email actually was sent.
> >
>
>
>


[Non-text portions of this message have been removed]
7
Hi Carl,

> In 8.33, does anybody have a solution to how can emails, generated by BPM's, be traced or confirmed that they have been sent and delivered?
>
> We send a confirming email to our customers and sales reps for each sales order and need some sort of audit trail that the email actually was sent.
>

While email is very convenient and efficient, it is not always the
best tool for the job. This was an issue for an intranet application
for us. We would create reports and send them to the employees but we
never knew who saw the report. It's an Exchange shop but even with
Delivery Receipts and Read Receipts turned on (and assuming the
employees didn't inactivate that capability) we still didn't know if
they read the report. Our solution was to publish the reports on the
intranet and email the link to the report. There were several
benefits:

- We knew who retrieved the report and when they retrieved from a log
that the page created (easier to work with than the http log)
- We didn't clog up Exchange logs and mailboxes with huge attachments
- We could recover from a "bad report" because we could quietly upload
a newer version for those who didn't retrieve the first version and
notify those who did retrieve the bad version to get a newer one
- You don't have to send an email. Some people would just actively
check their report page on a particular day

A couple of downsides:

- We still didn't know if they read it. There was talk of adding a
code to the report and having them enter it or the totals in the
report on a form to prove they read it but that was getting a little
to nanny-ish.

- To do this for customers outside your network, you'd have to set up
some security.

Food for thought...

Mark W.
8
Emails are sent via SMTP, so there's typically tracing at that level that can be enabled.
I think that undeliverable emails are also kept in a folder set up by SMTP as well.

My recollection is that an email generates a text file in the SMTP directory. SMTP picks that up and delivers it, or leaves it if it is unable to and retries later.

________________________________

From: vantage@yahoogroups.com on behalf of Mark Wonsil
Sent: Wed 3/9/2011 11:40 AM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] Tracing emails sent from BPM's




Hi Carl,

> In 8.33, does anybody have a solution to how can emails, generated by BPM's, be traced or confirmed that they have been sent and delivered?
>
> We send a confirming email to our customers and sales reps for each sales order and need some sort of audit trail that the email actually was sent.
>

While email is very convenient and efficient, it is not always the
best tool for the job. This was an issue for an intranet application
for us. We would create reports and send them to the employees but we
never knew who saw the report. It's an Exchange shop but even with
Delivery Receipts and Read Receipts turned on (and assuming the
employees didn't inactivate that capability) we still didn't know if
they read the report. Our solution was to publish the reports on the
intranet and email the link to the report. There were several
benefits:

- We knew who retrieved the report and when they retrieved from a log
that the page created (easier to work with than the http log)
- We didn't clog up Exchange logs and mailboxes with huge attachments
- We could recover from a "bad report" because we could quietly upload
a newer version for those who didn't retrieve the first version and
notify those who did retrieve the bad version to get a newer one
- You don't have to send an email. Some people would just actively
check their report page on a particular day

A couple of downsides:

- We still didn't know if they read it. There was talk of adding a
code to the report and having them enter it or the totals in the
report on a form to prove they read it but that was getting a little
to nanny-ish.

- To do this for customers outside your network, you'd have to set up
some security.

Food for thought...

Mark W.





[Non-text portions of this message have been removed]