Implementation of Specialized Data Pages per entity
I have a design clarification question : I work in an application which cuts across more than one country/entity (let us call the countries X and Y). Now, there is a strict regulatory requirement to have a segregation of data between the entities : users of Country X would NOT be able to view the data of country Y.
Now, we have certain Data Types which are to be used for both X and Y , but with different data. For example, there is a Referential Data object which pulls the list of options for all drop down in the application. Some dropdown values might be the same for both X and Y entities (for example, a list of Countries) , but the data is mostly different.
Now, from the 7.4 CLSA course, it seems that PEGA usually recommends creating Data Types in the Organization or, at most, in the Framework Layer. But here the only approach seems to be to specialize the Data Type into the Implementation Layer (Org-X-Data-DataType and Org-Y-Data-DataType).
Can this be considered a good design, considering the requirements ? Is there any other approach we can try ?
I had also considered the approach to create a Data Type in Framework layer called Org-FW-Data-DataType and then have an entity column to indicate the relevance of the data. But this means that, the data is filtered only for relevant entity users, the data is not being "strictly" seggregated between entities. Hence this approach was not considered.
Your scenario sounds like a good use case of Pega`s access control policy and Access control policy condition. This is part of Pega`s security feature.
By using this , you can specialize which user (having an access group or work group or division) can access which records of a database table. For e.g. lets say Org-FW-Data-DataType is having records with a column named division. Apply the access control policy and Access control policy condition so if an user belongs to a division, then only the user can access those records of Org-FW-Data-DataType having the matching division.
This is indeed a good solution, but the problem which I have already mentioned still remains : I am essentially separating the data based on access control/ filters, but I am not "physically" separating the data itself.
This might cause concerns on the legal side. Let me check and clarify. Thanks !