Salesforce customers who manage large data volume in their orgs must architect record ownership carefully to ensure peak performance.  When you have a large number of records owned by a single user in Salesforce, we call that an “ownership skew”.  There are many cases which lend themselves well to this type of architecture.  While any object can have an “ownership skew”, the most common cases involve Contacts without the concept of an owner, Accounts that are worked by a team without the concept of an owner, and unassigned Cases or Leads.  Since every record is required to have an owner, it seems like the natural solution is to skew those records onto a “generic” owner.  Unfortunately, this can cause performance issues due to sharing calculations required to manage visibility of those records.  When the skewed owner exists in the role hierarchy, operations such as deletes or owner updates must remove sharing from the old owner and all parent users within the role hierarchy, and also from all users given access by sharing rules.  For this reason, ownership changes tend to be one of the most costly transactional changes in the system.  In many cases these actions are automated, which can cause heavy sharing calculations resulting in performance related issues.  Furthermore, this type of architecture can make administrative configuration extremely difficult when the skewed user or the user’s role needs to move within the role hierarchy.  If the skew is severe enough, an administrator may need to unload the records to successfully move the user or role.

When architecting for a situation which requires a skew in ownership the best solution is to avoid the skew in the first place.  For assignments, make sure the rules and data quality are sufficient to ensure all records get assigned to the correct rep.  Ensure contact data is clean enough to associate with the correct account and assign account ownership to the user who creates the account.  Many customers spend countless hours and funds manually assigning unassigned or incorrectly assigned records resulting from dirty data or a flawed rule structure.  Investing in data quality and assignment tools can save companies significant time and money and ensure solutions properly scale to meet business needs.  In some cases an “ownership skew” simply cannot be avoided.  In these instances, it is best to ensure the skewed owner does not have a role.  By configuring the skewed owner this way, you take that user and their records away from the role hierarchy and its associated sharing rules.  If visibility to these records must be granted in a private sharing model, then it is best to grant access to a subset of users at the profile level.  If profile level access grants too much visibility then the skewed owner must have a role, group or a Criteria Based Sharing Rule may be used.  When architected carefully, each of the three solutions will provide similar performance.  If the role hierarchy is used, the skewed owner must be placed in their own role at the top of the hierarchy without child nodes.  Make sure any sharing rules used to grant visibility to skewed records are as restrictive as possible by granting access specifically to users who need it.  Heavy sharing rules that grant access to the majority of an organization should not be used.  Once the skewed owner is placed into their own role, the user and their role should never be moved since the skew would make such a move a long and difficult operation.  If Criteria Based Sharing Rules are used to grant the necessary access, build the rules on fields which will not change frequently such as the owner.  Doing so will prevent excessive rule calculation upon record updates.