Best Practice for Informing User of Bounced Email?
Apologies if this has been answered elsewhere but I have yet to find an answer. My team recently added an email component to our application where the user can choose to send an email to users concerning the work item they are working on. The question we are facing is if the email is bounced for some reason (invalid email address, inbox is too full, etc) what is Pega best practice for informing the user that delivery of the email was not completed? Should this be done in the application itself, should an email be sent to the user sending the email? Does it all depend upon what the business end of application wants? Thanks in advance for any and all help!
Pegasystems Inc.
GB
I don't have any best-practice knowledge I'm afraid...but I'll chip in with some thoughts to get the conversation going.
I think you are going to have to essentially *read* the email (the non-delivery report email) back from an Email Listener; and then sift through the bits to get out the original intended recipient.
Now: the issue here (I think....I could be wrong on that) is that when the PRPC Operator (say 'Joe Bloggs') sent the email; he didn't really send it himself - he basically asked PRPC to send it out on his behalf. (By creating a QUEUE item in the PRPC system....)
So how to work out that it was 'Joe Bloggs' that sent the email here ? Not sure.....you might have to include extra logic to 'join' the outgoing QUEUE item with the newly derived information from the non-delivery report......
Maybe you could add an email header in (via some sort of customization) - a UUID ? on the outgoing email; that will still be present (hopefully) in the bounced copy of the email; then use that as a way of 'joining' ? And thereby being able to track down "Joe Bloggs" as the originator.....