triage-email class does not get an own application layer
When creating a new Customer Service application with the New Application wizard, Pega generates a new application case layer for out-of-the-box cases such as certain service cases and the Interaction case.
If you run two independent Customer Service applications on the same server, you will end up with two separate application layers for Interaction and Service cases. However, the Email Triage case will remain the same for both applications:
→ Work-Channel-Triage-Email
Same for the class PegaSocial-Message which holds the puls and e-mail messages.
My question is:
Why does those classes not get its own application layer while generating a customer service application?
Technically, this does not cause any issues, but from an architecture perspective it does not feel ideal to share the same table across multiple applications. Imagine you need to migrate one application to another system in the future.
HCA Healthcare
US
USU GmbH
DE
@Sairohith Thanks for your thoughts on this.
That’s correct, of course, you can use filter conditions for migration or reporting.
Nevertheless, from my point of view, it is not a clean design to write directly to the same table across different applications.
What I can do manually, by creating my own class for Triage Email and defining a dedicated database table, could also have been provided by the wizard in my point of view.
I would also not expect any new logic, nor do I see which logic would need to be duplicated in the new app layer. It’s simply a class layer that is generated for your application layer, which points to an application-specific class group with its own database table. Yes, there are some parts the class is hardcoded an ou might need to care about DCR, but this needs just to be considererd in the product development.
Another Topic.
Imagine you are designing a multi-tenant application in which you have a base application and separate tenant-specific logic into additional built-on applications.
From a data-security perspective, it would be critical to avoid storing emails from all tenants in the same table.
But anyway — it was more of a hint to the Pega product team and I was curious what was the design decision for that.
Let’s leave it at that.
We will create those tables ourselves and see how it works out.
HCA Healthcare
US
@WilhelmM Thanks a lot for sharing your detailed thoughts and the multi-tenant angle – that really helps clarify your concern. I was mainly looking at it from the current product design, where triage and social message handling are treated as shared, channel-level features, so the wizard keeps them on common classes/tables. I completely see your point that, especially for multi-tenant or future migration scenarios, having separate app-specific triage classes and tables would be cleaner and safer from a data-segregation perspective. Your approach of creating your own implementation class and dedicated table per application makes sense in that context, as long as DCR / hard-coded references are adjusted carefully. Let’s definitely consider this as good feedback for the CS product team – having an option in the wizard for tenant/app-isolated triage classes would be very useful. Thanks again for closing the loop and for explaining your design choice; please do share your experience once you’ve run with the custom tables for a while.
@WilhelmM
This is expected behavior in Customer Service. Work-Channel-Triage-Email and PegaSocial-Message are designed as shared, channel-level classes, because email triage and pulse/messages are cross-application capabilities, not specific to one CS implementation. If the wizard created a separate triage class and table per application, you would duplicate a lot of generic logic, make upgrades harder, and increase maintenance effort. Isolation between your two apps is handled by case types, access groups, work queues, and routing rules, not by separate triage classes. From a data perspective, you can still distinguish which records belong to which application using org/unit, channel configuration, or custom properties on the triage case or message. For migration scenarios, you would export only the records that match your application-specific identifiers instead of moving the full shared table. If you really need physical separation, you can create your own implementation triage class that inherits from Work-Channel-Triage-Email and point it to a different table, but that is a customization, not what the CS wizard generates by default.