pxCreateOperator is defined in @baseclass so is inherited by every other class.
An ABAC rule can be used to prevent display of information within a data class regardless whether the data class is abstract or concrete. The PropertyRead access policy type would be used.
If this were not the case there would be an easy way to see the information even if the data class was concrete. All you would need to do is embedded a field group having that class.
Perhaps you are referring to the Discover access with regard to concrete data, which includes cases?
You point about abstract vs concrete is well made.
It would make perfect sense to persist each Candidate in its own table, not in a case BLOB which then requires the various properties in the Candidate class to be exposed in the work pool table.
Instead TGB-HRApps-Data-Candidate should extend PegaData-Contact and be persisted in the CustomerData schema.
The case would possess both a CandidateID property and a CandidateRef page, the latter using the former to retrieve the Candidate by way of a Data Page Lookup.
If the Candidate is not already persisted, there are ways to persist the record to the CustomerData schema.
Persisting the Candidates in their own table also supports auto-complete searching against a List Data Page.