Service Email Usage – Case Creation

In the other articles, we saw, how to create a file listener, email account, service email using email wizard.

The processing of all listeners in Pega is basic. The listener listens at a location for a message/file or email and invokes a service rule to process.

Similarly, in email processing, the listener listens for an email at the particular folder and when an email comes in, listener invokes the service email rule to process the email.

So I would say, service email is the heart of the email processing.

Using email service you can perform any type of processing because you use service activity and activity can perform any actions.

But in real-time, most of the use case will be at case level. To specific, you will be doing either creating a new case or updating a case.

1. Create case – It is pretty simple, with the incoming mail you may need to create a particular case

2. Update a case / manage conversations – This is the most common email use case in Pega. To update any case, first, you need to know the case ID or any unique ID. It means the email sender should indicate the incoming email corresponds to a certain case. We can rename it as ‘supporting email conversations’

I am going to split the service email posts into 4 use cases

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

By end of the coming 4 articles, I guarantee you will learn new things and play around with the email servicing 🙂

First, let’s see the configurations for the first use case.

How to create a new service email rule?

1. Create through email wizard
2. Manual creation

Records -> Integration services -> service email -> New

In this, I am not going to explain the service email rule field by field. We already covered a lot of service rule and most of them have similar configurations

I am opening the service email rule which was created in my previous article.

As usual 3 main tabs.

1. Service tab – You can specify the primary page and service activity name
2. Request tab
3. Response tab

Request tab

Request tab is responsible to parse and map the email content into pega properties.

The main advantage of the email wizard is it prefills the basic fields into 3 blocks.

a) Message header – In this block the email headers are mapped to pega properties: To field, CC, Subject, From etc. Here in our scenario, we have 5 mapping fields.

Always remember, Pega engine has some control over the email service request mapping.

You may get a question, what are the other fields, you can map in the header?

Just add a new row and focus on the field and click down arrow.

Note: This dropdown is not limited, you can always add your other message headers that are supported by email providers

b) Delivery status notification data – This we will see in the fourth use case. For now keep it empty

c) Message data – Maps the email body to pega property – .pyBody.

Note: You don’t have any add row option in the message data. It means the entire body can only be mapped once.

Important note: Pega already defined the data model/properties for the mapping. All the mapping follows the below structure .pyInboundEmail.<>

Response tab

Service email response will be always like sending out the response email to the email sender.

You can specify different templates of response message based on different conditions.

For example – For successful processing, you can send them an acknowledgement template or for error processing, you can send a template accordingly

Expand the message contents.

You see you have different options to map and create a response message template. Correspondence can be an ideal option.

Note: The wizard, prefills this tab. You can always override 🙂

Actually, for the first use case, I didn’t do any external configuration!!!

I have already set up email listener and email account in my previous post.

It’s good to test the first use case

Step 1: Save the service email rule with the default configurations.

Step 2: Trace open the service email rule.

Step 3: Since I configured my email listener on personal email ID  I am sending a mail to that ID from my personal ID. assume I am the customer

Step 4: From the tracer, I can see the processing ran successfully.

Click on the service page to check the request mapping to clipboard properties. Subject and body are mapped rightly.

Step 5: You can see a new case is created.

Hope you noted that the email body is mapped to case short description.

Whether it should be always the same mapping? Can we customize it?

Yes. We can.

To me, the email subject, body and the from address are the interesting part in the incoming email. I may have to use the data inside the case.

Let’s explore the important activities in the first use case

1. pyCreateAndManageWorkFromEmail

This is a 51 step looong activity. I will explain this part by part in my coming use cases.

In this use case, I am interested in the very last step.

2. CreateWorkFromEmail

You can see the value pyLabel and pyDescription is mapped from subject and body.

Note: The value we set in the primary page will be eventually merged into the case pyWorkpage.

Both the rules are available and you can always customize and create a wrapper over 🙂

Here in this use case, you see the email conversation is started from the external party.

As soon as someone sends out an email to the monitored email address, we use the email content to create a case ( or any processing).

What about the conversations initiated from pega?! Check out the coming use case articles 🙂