Корова, которая не даёт молока, называется жадина-говядина, а пользователь, который владеет большим (более 10000) записей называется skewed owner. И дело вовсе не в анатомических аномалиях, а в том, что владение данными в организации построено не самым удачным образом, что привело к возникновению Ownership skew.
Ownership skew - ещё одна разновидность неравномерного распределения данных в Salesforce (хотя, я бы даже сказал, что дело не столько в неравномерности, сколько в количестве), когда один пользователь (User) является владельцем большого количества (более 10000) записей. Когда такой пользователь включён в иерархию ролей, это может привести к серьёзным проблемам с производительностью системы. Ведь любое переприсваивание записи другому пользователю будет требовать удаления sharing записи не только для бывшего владельца, но и для всех пользователей, стоящих выше в иерархии ролей.
Таким образом, смена владельца записи может стать необоснованно дорогостоящей операцией. То же самое относится к перестановке роли пользователя на другую позицию в иерархии ролей, которая потребует массовых пересчётов доступов сразу для большого количества записей.
Такого рода расчёты выполняются автоматически “под капотом”, но всё так же используют ресурсы, поэтому проблемы с производительностью могут затронуть всю организацию в целом.
Внимание! Костыль!
Если в организации уже присутствует Ownership skew и он достаточно большой (скажем, миллионы записей), можно выгрузить записи из системы, только чтобы переместить пользователя в иерархии и затем загрузить данные обратно.
Звучит страшно, но Bulk API вполне под силу 
Тем не менее, в некоторых случаях нельзя избежать оwnership skew. Может пользователей в системе немного, может записей много, а может всё вместе… В такой ситуации, чтобы минимизировать его влияние на систему, рекомендуется следовать следующим правилам:
- Не присваивать пользователю, который владеет большим количеством записей, роль.
- Если данному пользователю обязательно нужна роль, она должна быть расположена на вершине иерархии и в отдельной ветке.
- Не включать данного пользователя в Public Groups, на основании которых строятся Sharing Rules.
- Если нет возможности не использовать Sharing Rules, ограничиться Criteria Based Sharing Rule , используя в условии поля, которые не будут часто изменяться.