The primary impact of entity ownership is related to the security model. With organization-ownership, access is binary - either the user can view (or edit, create etc.) ALL or NONE. With user-ownership, access is much more nuanced allowing for much finer control over the SCOPE of which records can be viewed (or edited etc.).
The issue is that it can be difficult to anticipate what to expect in the distant future. Meaning that all good analysis and critical thinking aside, a requirement might surface in phase 6 of the project that was heretofore unforeseen. And suddenly we're left ruing a decision made some years back - a decision which made perfect sense at the time it was being made.
When we think of user vs. organization ownership, we tend to think of it in terms of whether anyone "cares" if a record could be or should be owned by a particular individual in the organization. If the answer is negative then we tend to think of it as organization-owned. And not only do I think there's nothing wrong with that thinking, I think that if the designer of the system takes a moment to ponder this then that is in fact highly commendable.
However, as I've discovered over the course of many projects, the issue with record ownership is that the business logic of the concept may not always mirror the technical requirement. It may well be the case that no-one "cares" who owns a record. It might even be the case that seeing an "owner" on the record might be unnecessary or even confusing (i.e. the owner field can or should be hidden on the form). However there could still be a requirement to limit access to the record that still needs to leverage the user-ownership security model.
The "sharing" feature is a classic example of this scenario. For example:
- There might be a user or team ("team A") that you only want to grant access to a limited subset of records ("entity B").
- That subset might have nothing to do with ownership e.g. we want to grant "team A" access to "entity B" records which have been flagged as "Vendor"
- The above effectively means that we wish to grant "team A" access to a subset of "entity B" records based on a non-ownership type attribute
- If "entity B" is organization-owned, there is no way to configure the above security restriction. Organization-owned entities are binary - either you can see all "entity B" or you cannot see "entity B" at all.
- In order to accomplish this requirement, "entity B" will need to be recreated as a user-owned entity.
Hopefully the above scenario illustrates how it's possible - best practice design considerations aside - to land up in situation where an entity needs to be converted to user-owned. And I'm sure I'm not the only one who has come up against this issue.
Based on this, we can come up with a rule of thumb for record ownership. And that is - if there is not a clear requirement for a record to be user-owned or organization-owned at design time, and even if it might seem to make sense from a logical business perspective that the entity should be organization-owned (using the "no-one cares" formula mentioned above), it probably still make sense to create the record as user-owned. After all, it's very easy to hide ownership fields on the form and one can still set up security so it behaves in a binary fashion as organization-owned entities.
In short, if you got it wrong and set up an entity as user-owned, the price to pay is relatively small. On the other hand, if you got it wrong and set up an entity as organization-owned, you could be looking at open heart surgery.
The theory might all be well and good, but let's say you're presently in the predicament described above i.e. you're in production and have come across a requirement that means that you'll need to convert an entity from organization-owned to user-owned - what are the steps to achieve this? In the next post I'll attempt to address this with a step by step walk through.
