Encapsulation: Should a separate Data type be used for the Case type data model? [LSA Data Excellence]

Should case type data be a separate data type that the case type is composed of?

If there are business needs to report on parts of case data outside of the context of the case it materialized from, or if that data needs to be stored external to the case, then a distinct data type may be of value.

Properties of the case type that drive case lifecycle which have no benefit outside of the case (for example, values captured or calculated that only exist to influence the path taken by a decision shape) yield no benefit by being defined in their own data type.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.

We sometime, expose some additional properties in work table. In scenarios where we need to open a case based on some exposed properties, should we create a separate datatype. Is exposing additional properties in work table not recommended .

Hi @DebDeveloper - thanks for your question.

Exposing properties on a case type class (which creates columns in the work database table) is fine when there is a need to retrieve work items by criteria other than the Case ID.

The focus of this FAQ is to consider how much of the data captured in the Case Type needs to be accessible (or stored) outside of how you use it in the case. In these situations, a distinct Data Type that defines those properties - which is then included in your Case Type data model as a Page property (perhaps auto-populated) - may be more useful. That Data Type could be composed into other Case Types (maybe as a Page List), become a superclass of an inheritance design, and encapsulate Data Pages that solve for how to read/write instances from/to another System of Record.

Indeed. A solid business data model is the foundation on which case types are designed/defined. Even if there are no immediate reporting requirements, any entity captured in the business data model is worth being defined as a Data Class (without storage definition) at least. The single value properties defined under a case type are better to be restricted for the purpose of “driving the process”. Properties capture business data should refer to the appropriate data class.