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?
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.