Service Email Usage – Manage Conversations

In this blog article, we will explore our third use case: Managing Email Conversations within Pega using Service Email

---

Note: This article was created using Pega 7.4. While configurations may differ in more recent versions, the core concepts remain the same.

---

Series Recap

To get the most out of this series, I recommend visiting these articles in order:

1. Case Creation: Generate a case from an incoming email.
2. Email Approvals: Automate case updates using Subject line data to identify the Case ID. (Current Post)
3. Conversation Management: Use Message-ID headers to link replies to cases.
4. DSN Handling: Manage delivery failures using the Thread-Topic field.

The Challenge: Linking Replies to Cases.

This is our third use case. To maintain a conversation thread within a case, we typically rely on the Case ID. If we have the ID, linking incoming emails is simple. But what happens if the Case ID is missing from the communication?

In our previous use case (Approvals), we provided a template that automatically encoded the Case ID and assignment details into the subject line. However, for “natural” conversations—such as a customer replying to a mail initiated by a service representative—the Service Email rule must be smart enough to attach that reply to the correct case even without an explicit ID in the subject.

We will look at two scenarios:

1. Case ID is available in the subject.
2. Case ID is NOT available in the subject.

---

Scenario 1: Case ID is Available in the Subject

Step 1: Use the standard service activity: pyCreateAndManageWorkFromEmail.

Step 2: The default Request and Response configurations are usually sufficient for this.

Step 3: Add a “Send Email” step to your workflow. Ensure the Subject line includes the .pyID property.

Step 4: Run the process and create a new case.

Step 5: The outbound mail is sent. Assume the customer receives this and hits reply.

Step 6: Open the Tracer on your service rule and send the reply from the customer’s address to your monitored Pega address.

Step 7: Once the listener processes the mail, open the case. You will see the reply added as a new attachment.

How the activity works: In pyCreateAndManageWorkFromEmail, Step 13 identifies that this is not an approval mail (IsApprovalMail = false). It then moves to Step 18 to attach the email to the case and exits.

Note: In newer Pega versions, this functionality is significantly enhanced, allowing work parties to collaborate via Pulse through email processing.

Scenario 2: Case ID is NOT Available in the Subject

Every email sent by an application can include a unique Message-ID. Pega generates these IDs for every outbound mail.

The Outbound Flow:

1. SendSimpleEmail (Final) calls CorrSend (Final).
2. The request is queued to the SendCorr Agent.
3. The Agent calls the Send method (Data-Corr-Email), which invokes the function SendEmailMessage.

Every message contains a unique Message-ID header. To see this, open an email in your inbox and select “Show Original.”

Scroll down to the headers to find the Message-ID.

When a customer replies, their reply will have a new Message-ID, but it will also include an In-Reply-To header that matches the original Pega Message-ID. This is the “hook” we use to link the reply back to the case.

Linking Message-ID to a Pega Case

Email records are saved as instances of Data-Corr-Email. For this link to work, these instances must store the Message-ID.

Note: In Pega 7.4, there is a known issue where .pyMessageID is not automatically saved to the Data-Corr-Email instance. You may need to customize the SendEmailMessage function to return and save this ID.

Once fixed, you can verify the ID is saved by checking the instances in the App Explorer.

Processing the Inbound Reply

Step 1: Change your Service Activity to ProcessInboundEmail. (Note: This OOTB activity is complex; customization is often recommended).

Step 2: In the Request Tab, map the email header In-Reply-To to the Pega property .pyInboundMapping.pyMessageID.

Step 3: The ProcessInboundEmail activity requires a Work Party. Ensure your case has a party (like “Interested”) configured.

Step 4: Test the flow again. Create a case (e.g., S-256) and send an email without the Case ID in the subject.

When the customer replies, the Tracer will show a successful run, and both the original and reply emails will appear in the correct case.

How ProcessInboundEmail Works:

1. It uses a Declare Index to save Message-IDs in the pr_index_email table.
2. Step 5: It searches the index for the parsed Message-ID.
3. Step 8: It retrieves the linked Case ID from the correspondence table.

A lot of learnings, hope you feel the same.