Whenever we add a new property to the data model of a class, it is getting exposed to the database by default. This is resulting in a large number of unnecessary exposed columns, especially for properties that are only used as transient flags, UI conditions, or if/else processing logic and are not intended to be persisted.
Is there a setting, or configuration in Pega that can prevent new properties from being automatically exposed? We would like to expose only those properties that require reporting.
If the properties are being added through the Case Type data model, what you’re seeing may be expected behavior, particularly when using App Studio. I’m not aware of an OOTB setting that prevents automatic column creation for all newly added case properties. For transient flags, UI conditions, or processing-only values, consider using page structures (Data object).
As above - this is the direction of travel for our architecture. Simplifying things so that Pega is easier to implement.
In these kinds of scenarios you can still use Dev Studio to do it in a traditional way. However, you do risk some some of some of the modern features for this. For example, those fields are exposed for Explore Data / Insights, so you wouldn’t be able to report on these.
While a Page type is a valid approach & helps, it also requires creating an additional class, which adds development and maintenance overhead for what may be a relatively straightforward requirement.
Also, we understand that the current behavior is aligned with the architectural direction and supports capabilities such as Explore Data and Insights. However, in practice this has become a recurring maintenance activity for many teams, as every property added through the Data Model Designer gets exposed automatically.
Removing/Deleting a property from the data model does not remove the corresponding database column and for Pega Cloud customers, the challenge is amplified as there is no DB access and often required RDB or CC requests to drop unused columns. Over time, this leads to unnecessary schema growth and periodic cleanup exercises.
Instead of making exposure the only default behavior, it would be beneficial to introduce a setting that allows customers to choose whether properties created via the Data Model Designer should be exposed by default or not.
The concept of an unused column addresses a different problem. An unused column can be removed only after the property mapping has been deleted and any report references have been cleaned up. That requires a separate cleanup exercise.
The ask here is different: the property should continue to exist and be available for application logic, but it should not necessarily result in a database column being exposed by default. The goal is to give teams the flexibility to decide whether a property needs database exposure or not.
