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