We all know about the owner teams, security roles, access teams, field security profiles, etc. But there is yet another not-so-obvious security feature which controls access to CDS records through the “reparent” behavior on the “parental”/”configurable cascading” 1:N relationship. Why does it matter?
See, on the diagram below, even though the security role is configured to give access to the user-owned records only, my User A can still access records on the far right side of the parental entity hierarchy:
How come? Well, carry on reading…
I’ve been trying to figure out how to set up CDS security for the very specific requirements, and it has proven to be a little more complicated than I originally envisioned (even though I had never thought it would be simple).
To start with, there are, essentially, only two security mechanisms in CDS:
- Security roles
- Record sharing
Yes, there are, also, teams. However, teams are still relying on the security roles/record sharing – they are just adding an extra layer of ownership/sharing.
There is hierarchy security, too. But it’s only applicable when there is a hierarchy relationship between at least some users in the system, and it’s not the case in my scenario.
And there is Field Security, of course, but I am not at that level of granularity yet.
There is one additional aspect of CDS security which might be helpful, and that’s the ability of CDS to propagate some of the security-related operations through the relationships:
However, if you try using that, you’ll quickly find out that there can be only one cascading/parental relationships per entity:
“The related entity has already been configured with a cascading or parental relationship”
Which makes sense – if an entity had two or more “parent” entities (which would have cascading/parental relationships with this entity), the system would not, really, know, which parent record to use when cascading “share”/”assign” operations through such relationships. The first parent record could be assign to one user, and the second one could be assigned to the another user. There would be no way for the system to decide which user to assign the child record to.
Hence, there is that limitation above. Besides, “cascading” only happens when an operation occurs on the parent record. So, for instance, if a new child record is added, it won’t be automatically shared/assigned through such a relationship.
On the other hand, there is “Reparent” behavior which happens when a child record’s parent is set. In which case the owner of the parent record gets access to the child record.
With all that in mind, the scenario I have been trying to model (from the security standpoint) is this:
- There is a single CDS environment
- There are functional business teams – each team corresponds to a model-driven app in the environment
- Within each application, there is a hierarchy of records (at the top, there is a case. Then there are direct and indirect child entities)
- There are some shared entities
- Functional team members are supposed to have full access to all corresponding application features/entities
- The same user can be a member of more than one functional team
This “business security” model does not map well to the business units, since a user in CDS can be a member of only one business unit, and, as mentioned above, in my case I need the ability to have the same user added to multiple “functional teams”.
One way to do it would be to micromanage record access by sharing every record with the teams/users as required. That can become messy, though. I would need a plugin to automate sharing, I would need to define, somehow, which teams/users to share each record with, etc. Besides, “sharing” is supposed to be an exception rather than a norm because of the potential performance issues.
Either way, since I can’t user multiple business units, let’s assume there is a single BU. This means there are only two access levels I can work with in the security roles:
- User
- Business Unit
“Parent-Child” and “Organization” would not make any difference when there is only one business unit.
I can’t set up the security role with the “Business Unit” access, since every user in that BU will have access to all data. Which is not how it should be.
But, if I configure that security role to allow access to the “user-owned” records, then there is a problem: once a record is assigned to a user, other users won’t be able to see that record.
It’s almost like there is no solution to this model, but, with one additional assumption, it may still work
- Let’s create an owner team per “functional team”
- Let’s create a security role which gives access to the “user-owned” records and grant that role to each team
- Let’s keep cases (which are at the top of the entity hierarchy) assigned to the teams
- And let’s add users to the teams (the same user might be added to more than one team)
Would it work? Yes, but only if there is a relationship path from the case entity to every other entity through the relationships with cascaded “Reparent” behavior.
That’s how “regarding” relationship is set up for notes and activities out of the box (those are all parental relationships), so I just need to ensure the same kind of relationship exists for everything else:
All users which are members of those teams above will get access to the cases which are assigned to the teams. And, as such, they will also have access to the “child” records of those cases.
If a new child record is created under the case (or under an existing case’s child record), that record will still be accessible to the team members because of “reparent” behavior.
So, as long as cases are correctly routed to the right teams… this model should work, it seems?
What’s unusual about it is that not a single security role will have “business-unit” (or deeper) access level, there will be no access teams, and, yet, CDS data will still be secured.
And, finally, what if I wanted to assign cases to the individual users? That would break this whole “reparent” part (since team member won’t have access to the case anymore). However, what if there were a special entity which would be a case’s parent, and what if, for each case, the system would create a parent record and assign it to the team? Then, out of a sudden, “reparent” would kick in, and all team members would get access to the cases AND to the child records of those cases. Even if those cases were assigned to the the individual users. Of course this would mean I’d have to reconfigure existing parental relationship (which is between cases and “Customers”). But, in this scenario, it seems to be fine.
PS. As for the “reparent”, you will find some additional details below. However, even though that page is talking about “read access” rights, it’s more than that (write access is also inherited, for example):
