Question

Pega's design view behind Email Channel & Interface and Interaction case & OOTB Email Triage case.

Our Application is running on Pega platform version 7.3.1 & Customer Service framework version 7.3.1

An Email Channel Interface is implemented using Channels and Interfaces. When an email is received in the configured email account then the listener reads it and creates an OOTB ET- case for it and as the application is on CS framework, the ET- case creates an I- case in CS stack.

As we understand the ET- case is expected to stay in background and I- case is to be worked upon by user. Email content is maintained in the ET- case and the email content in the ET- case to be fetched & displayed with in I- case as an embedded component enabling user to view & reply. The reply also to be saved in ET- case but should be fetched and displayed in I- case. When the I- case is wrapped up then the ET- case also to be resolved in the background.

What is Pega's design view behind these 2 cases to carry out an interaction life cycle? Is our understanding in-line with Pega's design view?

Appreciate your thoughts & comments..

Comments

Keep up to date on this post and subscribe to comments

January 30, 2019 - 4:16am

Link to any PDN article on email channel & interface implementation would help.

February 13, 2019 - 12:09pm

Any assistance is appreciated...Thank you.

February 22, 2019 - 4:46am

Hi Nipun, I suggest you start with these documents and then drill-down into email channel documents - 

https://community.pega.com/knowledgebase/articles/conversational-channels-8-1

https://community.pega.com/sites/default/files/help_v81/procomhelpmain.htm#mcp/tasks/mcp-configure-email-channel-tsk.htm

(You can find similar documents for 7.3.1)

Whatever you said about Email Triage case w.r.t. Correspondence case (Inbound) is true. If CS is being used, it is highly recommended that ET be used in conjunction with Inbound Corr case. Platform provides Email triage case if an application needs separate (outside of CS) handling of customer emails and you can leverage Email manager portal for that. The design thinking behind using 2 cases to handle incoming mails is that CS leverages platform features wherever possible and we have a single offering/implementation of Intelligent email processing across products and platform. 

April 1, 2019 - 9:35am

Thank you! Vikas, for the response and the links are really useful. Just an update on my sum up in the post that the ET- case does not get resolved when the I- case is wrapped up.