Владение и жизненный цикл

Также доступно на 28 языках

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

The cut end of a large log in a forest, every year's growth ring visible from the center to the bark. — Изображение создано с помощью ИИ

Модуль 8 из 10 главы Архитектура данных Salesforce, глава 3 курса Data Architect. Каждый модуль самостоятелен. Назад: У связей есть последствия · Далее: Как сохранять данные согласованными

Вопрос, на который отвечает этот модуль: кто владеет записью и что с ней происходит на протяжении всей ее жизни?

Когда я смотрю на модель данных, я хочу знать не только, какие в ней объекты и как они связаны. Я хочу знать, что происходит с записями со временем. Кто их создает? Кто ими владеет? Кто может их переназначить? Что происходит, когда бизнес-отношения меняются, когда записи больше не активны? Должны ли они когда-нибудь удаляться и как долго мы их храним? Ничего из этого не видно на ERD, диаграмме «сущность — связь»: прямоугольниках и линиях модели данных из главы 2. И все это — архитектура данных. А в Salesforce владение — это место, где модель данных и модель безопасности сталкиваются друг с другом.

Владение — это больше, чем имя в поле

Администраторы видят на записи Owner и читают это как метку: Bart владеет этой организацией, Lisa — тем обращением. Это может означать и это. Но в Salesforce владение — еще и механизм платформы. На объектах, у которых есть владелец, владелец определяет, кто может видеть запись, через иерархию ролей, правила общего доступа, очереди и переназначение. Поэтому, когда я спрашиваю «кто владеет этой записью?», я не спрашиваю, чье имя будет на странице. Я спрашиваю, какое поведение безопасности и жизненного цикла мы к ней привязываем. Владельцем может быть пользователь или, для некоторых объектов, в том числе пользовательских объектов, обращений и интересов, очередь, и в любом случае владелец получает полный доступ к записи (Understanding Sharing (opens in a new tab)).

Поэтому я разделяю бизнес-ответственность и владение записью. Иногда это один и тот же человек. Иногда нет. Если бизнес говорит, что за доставку отвечает диспетчер, это не делает диспетчера автоматически владельцем. Ответственность может жить в отдельном поле, а владение — настраиваться так, чтобы поддерживать безопасность и масштаб. Не позволяйте этим двум вещам путаться только потому, что обе называются «владелец».

Таблица общего доступа: где владение становится доступом

Некоторые люди даже не знают, что такое таблица общего доступа (share table). Каждый архитектор данных должен знать.

Большая часть общего доступа к записи хранится в связанном объекте общего доступа (share object) — версии списка управления доступом (ACL) от Salesforce (Understanding Sharing (opens in a new tab)). У Account есть AccountShare, у Contact — ContactShare, а пользовательский объект получает свой: у Truck__c есть Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Каждая строка в нем говорит четыре вещи:

Какая запись: ID родительской записи.
Кто: пользователь или группа (публичная группа, группа роли, территория).
Сколько: Read, Edit или All (полный доступ).
Почему: причина строки (row cause). Owner для владельца, Rule для правила общего доступа, Manual для ручного общего доступа, Team, неявные причины, которые Salesforce добавляет между организацией и ее дочерними записями, и причины, которые разработчик определяет для общего доступа через Apex.

На занятиях я открываю Workbench и делаю запрос к таблице общего доступа, пока открываю доступ к записи, и вы видите, как строки появляются и исчезают. Когда кто-то спрашивает «почему этот человек видит то?», ответ часто лежит в строке, вместе со своей причиной.

Но там есть не все. Доступ по умолчанию для всей организации (organization-wide default) — не строка. Иерархия ролей тоже там не хранится: доступ для людей выше владельца вычисляется, когда он нужен. А View All, Modify All, View All Data и Modify All Data полностью обходят таблицу общего доступа (Sharing a Record Using Apex (opens in a new tab)). Как я говорю на занятиях: отметили View All — и вы обошли таблицу общего доступа.

Salesforce также открывает доступ к некоторым записям за вас, из-за того, как они связаны. Это неявный общий доступ (implicit sharing), и он работает между организацией и ее дочерними записями. Если вы видите контакт, обращение или возможность, вы можете читать и организацию, к которой они относятся. А владелец организации получает доступ к ее контактам, обращениям и возможностям на уровне, заданном ролью владельца (Implicit Sharing (opens in a new tab)). В последних релизах Salesforce вычисляет часть этого доступа к дочерним записям, когда он нужен, вместо того чтобы хранить его строками, так что не удивляйтесь, если запрос к таблице общего доступа его не покажет. Здесь я даю только подсказку; подробности — в главе Связи и встроенный общий доступ.

Еще одно исключение — для случаев, когда у вас много внешних пользователей. Пользователи сообществ с большим объемом (high-volume community users), лицензии Customer Community, созданные для тысяч и миллионов клиентов, не имеют роли, не могут состоять в публичных группах и не могут получать записи через правила общего доступа или ручной общий доступ (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). Для них таблица общего доступа — не ответ: они получают доступ к записям через наборы общего доступа (sharing sets), которые сопоставляют организацию или контакт записи с собственными организацией или контактом пользователя. Это одна из причин, по которым эти лицензии масштабируются. Курс Sharing and Visibility разбирает это в главе Общий доступ для внешних пользователей.

И помните модуль 7: у подчиненного объекта вообще нет объекта общего доступа. Его доступ идет от объекта общего доступа главного объекта и от Sharing Setting в поле master-detail.

Почему это важно архитектору данных? Потому что владение записывается в эту таблицу. Каждая смена владельца, каждое новое правило общего доступа, каждый переход пользователя между ролями или группами означает, что Salesforce добавляет и удаляет строки. При нескольких тысячах записей никто не замечает. При десяти миллионах, когда большинством из них владеет один пользователь, это тот самый пересчет, с которым мы сейчас встретимся.

Знать к экзамену. Объект общего доступа пользовательского объекта называется Object__Share, например Truck__Share. У подчиненного объекта нет объекта общего доступа: его доступ идет от главного. А когда владелец записи меняется, ее ручной общий доступ удаляется, тогда как общий доступ через Apex с собственной причиной разработчика остается.

Здесь модель данных передает эстафету модели безопасности, а остальное я преподаю в курсе Sharing and Visibility Architect: 22 способа Steve поделиться записью, Org-Wide Defaults, владение, очереди и иерархия ролей, Связи и встроенный общий доступ — о неявном общем доступе — и Программный общий доступ и безопасный код — о причинах общего доступа через Apex. В этом курсе глава 12 сводит все вместе для людей, приложений и агентов.

Иногда владение наследуется

В прошлом модуле мы видели, что у дочерней записи master-detail нет собственного владельца; она следует за родителем. Часто это ровно то, что нужно. Нужен ли бизнесу отдельный владелец для каждой позиции доставки? Нет. Жизненным циклом владеет доставка, а позиция ей принадлежит. Вот почему проектирование связей и проектирование владения идут вместе: выбрав master-detail, вы уже приняли часть решения о владении.

Кто владеет записями, которые создают системы?

Вот тут становится интересно. Человек создает организацию, и, возможно, становится ее владельцем. Но ERP за ночь присылает 100 000 транзакций. Кто ими владеет? Интеграционный пользователь? Очередь? Региональный владелец, вычисленный по данным? Системная учетная запись, о которой никто не вспоминал пять лет? А теперь записи создают и агенты.

Моя позиция: зависит от того, важно ли владение для общего доступа. Интеграционный пользователь или пользователь агента — полноценный пользователь, и он может владеть записями. Если в этом объекте владение определяет доступ (через иерархию ролей или правила общего доступа), назначьте записи правильному владельцу: реальному пользователю, очереди или выделенному пользователю-владельцу. Если нет, оставить владельцем системного пользователя может быть лучшим выбором, потому что тогда журнал аудита ведет прямо к тому, что создало запись.

В любом случае решайте это осознанно. Интеграционная учетная запись, которая владеет всем, незаметно стала частью вашей архитектуры безопасности, и кто-то должен знать, что будет, если ее когда-нибудь деактивируют.

Владение может стать проблемой масштаба

Распределение тоже важно. Десять миллионов записей, распределенных между тысячами владельцев, — это одна форма. Десять миллионов записей, которыми владеет один пользователь, — совсем другая. Salesforce называет это перекосом владения (ownership data skew), когда один пользователь владеет больше чем 10 000 записями объекта (Ownership Data Skew (opens in a new tab)). Обычно это случается, когда кто-то паркует все на одном пользователе или в одной очереди: все неназначенные интересы — на пользователе-заглушке, каждую запись интеграции — на интеграционном пользователе. Это безвредно, пока этот пользователь не переместится в иерархии ролей или не войдет в группу, от которой зависит правило общего доступа, или не выйдет из нее. Тогда Salesforce приходится перестраивать огромное число записей общего доступа, и вы получаете долгие пересчеты.

Рекомендации практичные. Распределяйте владение между большим числом пользователей, где можете. Если один пользователь должен владеть многим, держите его вне иерархии ролей; если ему нужна роль, дайте ему собственную роль на самом верху и не перемещайте его, и держите его вне публичных групп, которые используют правила общего доступа (Ownership Data Skew (opens in a new tab)). То же мышление применимо к родителю со слишком большим числом дочерних записей из прошлого модуля — перекосу «родитель — потомок» (parent-child skew).

Так что распределение — часть физической модели. Не спрашивайте только, сколько записей; спрашивайте, как они распределены. Это еще одна версия «числа нулей»: не только сколько нулей, но и где эти нули сосредоточены. Часть 2 глубоко разбирает перекос; здесь я хочу, чтобы вы увидели его приближение. Курс Sharing and Visibility возвращается к нему в главе Общий доступ в масштабе.

«Владелец по умолчанию» становится архитектурой

Вот паттерн, который я вижу постоянно. Никто не знает, кто должен чем-то владеть, и кто-то говорит: «Просто назначьте все интеграционному пользователю» или «создайте общего пользователя с именем System». Может, это и правильно. Но не делайте этого случайно. Временное значение по умолчанию имеет привычку становиться постоянным: через два года каждая запись принадлежит integration@company.com, никто не помнит почему, и изменить это — целый проект. Это тест на обратимость из главы 1: прежде чем отдать миллион записей одному владельцу, спросите, чего будет стоить изменить это потом.

Переназначение — событие жизненного цикла

Владельцы меняются. Менеджеры уходят, территории сдвигаются, команды реорганизуются, регионы перебалансируются. Что зависит от владельца: общий доступ, автоматизация, отчеты, очереди, эскалации, интеграции? Если смена владельца меняет то, кто видит запись, переназначение — не административная уборка. Это событие безопасности, а при миллионе записей — еще и операционное. Следите за таблицей общего доступа, когда это происходит: ручной общий доступ удаляется при смене владельца, а общий доступ через Apex с собственной причиной разработчика эту смену переживает (Understanding Sharing (opens in a new tab)). На занятиях я открываю кому-то доступ к записи, меняю владельца — и человек теряет доступ. Аудитория каждый раз удивляется.

И помните, что владение — не то же самое, что доступ. Владелец — не единственный, кому нужно видеть запись, и в Salesforce много способов дать доступ: иерархия ролей, правила общего доступа, команды, территории, ручной и программный общий доступ. Курс Sharing and Visibility подробно их разбирает, начиная с главы 22 способа Steve поделиться записью. Мысль архитектора проще: не используйте владение, чтобы решать каждую проблему доступа. Если вы перебрасываете владельцев только для того, чтобы кто-то увидел запись, вы, скорее всего, решаете не ту проблему.

Создание — только начало

Многое в моделировании данных заканчивается на создании: поля, объект, связь — готово. Но запись может прожить десять лет. Ее обновляют, у нее меняются владельцы, статус и связи, она становится неактивной, превращается в историю, может потребовать архивации, а когда-нибудь, возможно, и удаления. Архитектура — это не только то, как запись рождается. Это то, что происходит от рождения до смерти.

Click to enlarge

Не удаляйте только потому, что что-то старое

Розничный партнер перестает присылать работу. Удалить организацию? Не автоматически: ее доставки, претензии и история биллинга по-прежнему важны. Грузовик списан. Удалить его вместе с историей доставок и претензиями по повреждениям? Сама вещь может быть уже неактивной, но ее данные — активны. Поэтому я разделяю неактивное и исчезнувшее. Списанный грузовик может остаться в модели; бывший сотрудник может по-прежнему фигурировать в истории аудита. Архитектура должна сохранять важные факты после того, как операционные отношения закончились.

Срок хранения — это бизнес-требование

Обратная сторона: хранить все вечно — тоже не архитектура. Хранилище растет, отчеты замедляются, поиск становится шумнее, а законы о приватности могут требовать, чтобы часть данных ушла. Поэтому я хочу явного ответа на вопрос «как долго мы это храним?» «Salesforce хранит» — это не политика хранения.

И в основном это вопрос о транзакционных данных. Справочные данные — продукты, типы услуг, распределительные центры — не разрастаются, и на них указывают другие записи, поэтому обычно они остаются. Клиентские данные — посередине: может настать день, когда вы завершаете жизненный цикл клиента, особенно когда храните персональные данные и основание для их хранения истекает. Но объем — в транзакциях: доставках, заказах, обращениях, записях на прием, которые создаются каждый день, всегда. Именно это вырастает до сотен миллионов строк, и именно здесь срок хранения должен быть явным: может быть, два года операционных данных в org, семь лет финансовых записей где-то еще, девяносто дней для некоторых фотографий. Это бизнес-правила, и если никто не спросил, должен спросить архитектор.

Я говорю это на занятиях годами: если вы не архивируете сегодня, вы вообще когда-нибудь начнете? «Разберемся потом» имеет свойство превращаться в аварийный проект на трехстах миллионах записей. В Части 2 есть целый модуль об архивации и очистке, построенный на том же вопросе.

Steve Trucking: кто владеет доставкой?

Доставку создает интеграция из манифеста розничного партнера, примерно 3 300 раз в день. Кто ею владеет? Не розничный партнер; это бизнес-отношения. Не получатель. Выполняет ее бригада, но должна ли запись менять владельца каждый раз, когда бригады меняются грузовиками? Диспетчер? Распределительный центр? Очередь? Интеграционный пользователь, который ее создал?

Теперь примените этот модуль, начиная с вопроса, который все решает: определяет ли владение чей-то доступ к доставкам? В Steve Trucking — нет. Диспетчеры видят доставки своего распределительного центра, бригады — доставки на своих маршрутах, а каждая розничная сеть видит свои на партнерском портале. Ничто из этого не зависит от того, кто владеет записью; доступ идет от распределительного центра, маршрута и партнера.

Поэтому мой ответ: доставками владеет интеграционный пользователь. Это хороший пример системного пользователя, который владеет записями осознанно:

Журнал аудита честен. Владелец каждой доставки говорит, откуда она пришла: из интеграции манифестов.
Доступ идет от общего доступа, а не от владения. Правила общего доступа на основе критериев по распределительному центру дают команде каждого DC ее доставки; партнеры получают свои через портал.
Перекос исключен проектом. При 3 300 в день интеграционный пользователь переходит порог 10 000 доставок за три дня, так что перекос владения есть с первого дня, и это нормально, если мы к нему готовы. У интеграционного пользователя нет роли, поэтому выше него в иерархии нечего пересчитывать, и он не входит в публичные группы, которые используют наши правила общего доступа.
Никто не переназначает доставки. Бригады меняются грузовиками, диспетчеры меняют смены, а владелец никогда не меняется, поэтому нет бури переназначений и нечего терять из ручного общего доступа.

И запишите, что будет, если этого пользователя когда-нибудь деактивируют или заменят, потому что теперь он владеет миллионами записей. Именно это решение понадобится найти следующей команде.

За пределами экзамена: что меняет ИИ. Агенты создают и меняют записи с машинной скоростью. Если агент создаст 100 000 записей под своим пользователем, «владельца поправим потом» превращается в перекос, пересчет общего доступа и проект по уборке. Решите правило владения для агента до того, как он запустится, с тем же вопросом: важно ли здесь владение для общего доступа?

Что здесь решает архитектор

Представляет ли владение бизнес-ответственность, механизм безопасности или и то и другое, и где живет ответственность, если не в Owner.
Нужен ли записям собственный владелец или они должны наследовать его от родителя.
Кто владеет записями, которые создают интеграции и агенты, в зависимости от того, определяет ли владение общий доступ.
Как распределено владение и как избежать перекоса владения, когда один пользователь должен владеть многим.
Когда записи становятся неактивными, когда они уходят в архив, как долго хранятся и когда удаление правильно.

Глядя на физическую модель, не спрашивайте только, где хранятся данные. Спрашивайте, кто владеет ими сегодня, кто может владеть ими завтра и что происходит, когда они нам больше не нужны. Далее: даже с правильным объектом, полями, связями и владельцем данные все равно должны оставаться достоверными.

Дополнительно

Apex Developer Guide, Understanding Sharing (opens in a new tab), на английском, проверено 2026-10-13: владельцы (пользователь или очередь — для пользовательских объектов, обращений и интересов) получают полный доступ; большая часть общего доступа хранится в связанном объекте общего доступа; иерархия ролей вычисляется во время выполнения; ручной общий доступ удаляется при смене владельца, управляемый общий доступ через Apex сохраняется; значения причин строк.
Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab), на английском, проверено 2026-10-13: AccountShare, MyCustomObject__Share; у подчиненных объектов нет объекта общего доступа; что объект общего доступа не отслеживает (OWD, иерархия ролей, View All и Modify All).
Salesforce Help, Implicit Sharing (opens in a new tab), на английском, проверено 2026-10-13: доступ между организацией и ее контактами, обращениями и возможностями.
Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) и Sharing Rule Considerations (opens in a new tab), на английском, проверено 2026-10-13: нет ролей, нет правил общего доступа и ручного общего доступа; вместо них — наборы общего доступа.
Курс Sharing and Visibility Architect: 22 способа Steve поделиться записью, Org-Wide Defaults, владение, очереди и иерархия ролей, Связи и встроенный общий доступ, Программный общий доступ и безопасный код, Общий доступ для внешних пользователей, Общий доступ в масштабе.
Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) и Parent-Child Data Skew (opens in a new tab), на английском, проверено 2026-10-02.