Service Email Usage – Manage Conversations
In this blog article, we will see how we can manage the email conversations within Pega.
This article is created using Pega 7.4 version. There may some changes with the configuration in the latest versions. Please use this article only to understand the concepts
Recap on the use cases. I recommend you to visit the articles in the following order to be on the same line.
https://myknowtech.com/tag/email-processing
1. Create a case with the data from the incoming email
2. Use approval actions in the assignment notification, to update case automatically from the email service. This use case will use Subject data to identify the corresponding case ID
3. Manage email conversations with the case. This use case will showcase how to use Message ID header to identify the corresponding case ID
4. Handle delivery status notification messages. This use case will showcase, how we can use Thread-Topic field to identify the corresponding Case ID
This will be the third use case.
To maintain the email conversations within the case. We know that if we have the case ID, then we can always link the incoming emails with the corresponding case. What if we don’t have the case ID?
For the second use case, we provided the auditor with the email template and once the auditor clicks on the approve/reject link, we automatically set the email subject with the case and encoded assignment details. So there was no problem. But what if the normal chats or conversations related to the case.
Say, the customer service representative initiated a mail from the case. Now the customer replies to the monitored email address, and the service email should attach the email to the initiated case.
- If case ID is available in subject
- If case ID is not available in the subject
Case ID is available in the subject
Step 1: You can use the same service activity – pyCreateAndManagerWorkfromEmail
Step 2: The default request and response configurations are high enough.
Step 3: I added a single step – Send email to send out an email
Subject contains pyID.
Step 4: Run and create a new case.
Step 5: I received a new mail from my personal ID. Assume I am the customer.
Step 6: Trace open the service rule and the customer send out a reply mail to the monitored address.
Step 7: One email listener processed the incoming email, click and open the case. You will see a new attachment for the reply mail. You can open and verify.
Let ’s quickly look into the important activity steps.
Activity name – pyCreateAndManagerWorkfromEmail
1. Step 13 will return us Local.IsApprovalMail = false
2. Thus we enter only in the 18th step to create a new post / add it as an attachment to the case and exit.
Note: In new versions, this functionality has been improved a lot where work parties can collaborate through pulse via email processing
This is really simple, now the hard part.
If Case ID is not available in the subject
Applications can create an unique message ID for every email. Pega creates a unique message ID.
Important rules for outbound email
SendSimpleEmail (Final rule) —-Calls -à CorrSend (Final) —-Queues to Agent – SendCorr.
SendCorr(Agent) — Send (data-Corr-Email) — Invokes a function SendEmailMessage.
Technically this is the flow behind the outbound email.
As I said, we have a unique key called message-ID for every email we sent. First, let’s test that.
Step 1: Send out an outbound email
Step 2: Open the email and click on show original. Please check on google, how to find message id for other service providers.
Step 3: It will open up a new window.
You can see the original message.
The interesting part is scrolling a bit down to check the email headers.
You can see, Message-ID as header value. As I said, every message will contain a unique message ID.
Ok now, If I reply to this mail id( the monitored address), then it will be a new mail and so a new message ID right?
Note the message ID starts with – 2012562……….. also please note the Thread-Topic which will be useful in the next use case of DSN.
Step 4: now the customer replies to that email.
Step 5: Now login to the monitored mail address and again check on show original on the new mail
As expected you see different Message-ID
But hold on, the header field In-Reply-To contains the previous message ID that starts with – 2012562. With this, we can identify this is the reply mail to the original mail send from the portal. Coool
Now the question is how can we relate the email message ID with the pega case ID?!
We know there is a link between case and email in the name of attachments. All the email are saved as instances of class Data-Corr-Email and linked to the case ID. Now you can guess the design. The data-Corr-email instances should contain the Message ID.
Now the first bug comes into light 😉 Pega is not saving the message ID (.pyMessageID) with the Data-Corr-Email intances
Note, I am still in Pega 7.4 version and I see different code in Pega 7.3. If you don’t face this problem, then it’s all good.
In older versions of SendEmailNotification activity ,we clearly return the message ID back to save with data-corr-email instances.
This is not the same in Pega 7.4. When email gets send through agent activity, it uses function SendEmailMessage (this is not final) to send out email.
Note: Only after sending out the email we will get a unique messageID.
I expect we retrieve the message ID back and save it with data-corr-email instances. This is not happening.
As a workaround, I saved as the function and added a step to return the message ID on the primary page (data-corr-email)
Only after doing this change, I see the pyMessageId value is saved with the data-corr-email entry.
Now go to app explorer, to view the data-corr-email instances.
Now click and open the latest instance to verify if message ID is saved with the corr instances.
Yes, now its good.
Okay, outbound part is completed. We register the MessageID in pega database and send out an email.
Now let’s come to the email processing part.
Step 1: Change the service activity to ProcessInboundEmail
It is strongly recommended customize this activity. Lot of unwanted stuffs!!
Step 2: Remember, we found that an email header In-Reply-To contains the original / origin email message ID value (This is what we saved in DB)
Add the field In-Reply-To in request header mapping.
Important note: Please map it to .pyInboundMapping.pyMessageID field.
Once done, save the rule form.
Note: Please restart the listener if the changes didn’t reflect during processing
Step 3: Now follow the same steps
- Create an outbound email from user portal to the customer email address. ( Do not use Case ID in the subject)
- Once customer received the email, he replies back with this input (before replying trace open the service rule)
Exceptions!!
ProcessInboundEmail was developed in such a way that we should use workparty and it expects .pyFromParty in data-corr-email instance.
Please add a party before starting the case.
Step 4: Configure workparty display on creation. I added only for interested.
Now you can add workparty on New screen.
Note: You can add workparty in multiple ways.
Step 5: Follow step 3 again.
I created S-256.
Tracer ran successfully. Now refresh the case.
You should see both the attachments are in the right case.
How the activity ProcessInboundEmail helps?
1. First, a declare index is used to save the message ID separately in table pr_index_email
2. Actvity step 5, browse and find the corr key corresponding to the parsed messaged id .
3. Step 8, browse and get the case ID, in our case 256 from the data-corr-email mapped table.
4. Rest some unwanted stuff follows!!!
Note: I also did one more fix to commit at the end of the activity!
Lot of learnings, hope you feel the same.
