Модель общего доступа Salesforce является важным элементом в способности организации предоставлять безопасный доступ к данным приложения. Поэтому важно правильно создать модель общего доступа, чтобы соответствовать текущим и будущим требованиям к доступу к данным. В этом документе мы рассмотрим компоненты доступности данных, сценарии использования модели общего доступа и реальные решения общего доступа клиентов, а также предоставим некоторые рекомендации по устранению неполадок.
Данный документ предназначен для продвинутых системных администраторов и архитекторов. Чтобы понять понятия, необходимо иметь работающие Knowledge о модели безопасности и общего доступа Salesforce. Ниже перечислены предварительные требования к данному руководству.
- Справка Salesforce: Параметры общего доступа
- Модуль Trailhead: Безопасность данных
- Проектирование доступа к записям для масштаба предприятия
- Salesforce с хорошей архитектурой - Безопасный
Это руководство посвящено основным функциям, используемым для управления доступом на уровне записи к стандартным и настраиваемым объектам. В настоящее руководство не включены следующие темы:
- Доступ к папкам
- Доступ к содержимому
- Доступ Chatter
- Доступ к базе Knowledge
- Доступ «Идеи», «Вопросы/Ответы»
- Доступность мобильных данных
Безопасность записи позволяет предоставлять пользователям доступ к одним записям объектов, но не к другим. Как и в большинстве приложений, доступ к данным начинается с пользователя. Прежде чем предоставить доступ, приложение должно знать, кто является пользователем. Для Salesforce существуют разные типы пользователей, и иногда уровень доступа отличается в зависимости от типа. Вместо проверки каждого атрибута каждого типа лицензии, мы сосредоточимся здесь на интересных атрибутах, влияющих на доступ к данным. Ответственность за запись и полный доступ являются синонимами и взаимозаменяемыми и предоставляют пользователю самый высокий уровень доступа к записи.
Массовые пользователи
Массовые пользователи (включая пользователей с типами лицензий Customer Community, High Volume Customer Portal и Authenticated Website) не используют модель общего доступа, поскольку их типы лицензий не поддерживают роли. Эти лицензии имеют собственную модель общего доступа, работающую по сопоставлению внешнего ключа между пользователем (владельцем лицензии) и данными в поисках организаций и контактов. Администраторы могут создавать наборы общего доступа или группы общего доступа для предоставления массовым пользователям доступа к записям.
Chatter Free и Chatter External Licenses
Лицензии Chatter Free и Chatter External не соответствуют стандартной модели общего доступа. Данные лицензии не имеют доступа к записям CRM (стандартным или настраиваемым объектам) и функциям содержимого, а также не поддерживают роли, поэтому общий доступ отсутствует.
Для остальной части документа мы предполагаем тип пользователя Salesforce, использующий полную модель общего доступа. Дополнительную информацию о каждом доступном типе лицензий см. в разделе «Лицензии пользователя».
Профили и наборы полномочий
Профили и наборы полномочий обеспечивают безопасность объекта, определяя типы данных, которые видят пользователи, и возможность редактирования, создания или удаления записей. Полномочия «Просмотреть все» и «Изменить все» для каждого объекта игнорируют правила и параметры общего доступа, позволяя администраторам быстро предоставлять доступ к записям, связанным с данным объектом в организации. Эти полномочия часто являются предпочтительными альтернативами административным полномочиям «Просмотр всех данных» и «Изменение всех данных», которые позволяют пользователям просматривать или изменять все приложения и данные.
Профили и наборы полномочий также управляют безопасностью поля, которая определяет поля в каждом доступном объекте. Например, объект может содержать 20 полей, но безопасность поля может быть настроена для предотвращения отображения пользователям пяти из 20 полей.
Настоятельно рекомендуем использовать наборы полномочий и группы наборов полномочий вместо профилей для управления полномочиями объектов пользователей. Поскольку можно повторно использовать меньшие структурные элементы набора полномочий, можно избежать создания десятков или даже сотен профилей для каждого пользователя и функции задания.
Ответственность за запись и очереди
Каждая запись должна принадлежать отдельному пользователю или очереди. Ответственный имеет доступ к записи на основе параметров объекта для профиля ответственного. Например, если профиль ответственного имеет полномочие «Создание» и «Чтение» для объекта, но не полномочие «Редактирование» или «Удаление», ответственный может создать запись для объекта и увидеть новую запись. Однако ответственный не сможет редактировать или удалять запись. Пользователи, расположенные выше в иерархии (роли или территории), наследуют доступ к данным, предоставленный их подчиненным для стандартных объектов. Если у подчиненного есть доступ только для чтения, вышестоящие пользователи будут в иерархии ролей. Этот доступ применяется к записям, за которые ответственны пользователи, а также к записям, доступным им.
Очереди помогают расставлять приоритеты, распространять и назначать записи группам, разделяющим загруженность. Участники очереди и вышестоящие пользователи в иерархии ролей могут открывать очереди в списковых представлениях и принимать ответственность за записи в очереди.
Если один пользователь владеет более 10 000 записей, рекомендуем выполнить следующие действия:
-
Запись пользователя ответственного не должна содержать роль в иерархии ролей.
-
Если запись пользователя ответственного должна содержать роль, разместите роль вверху иерархии в собственной ветви иерархии ролей.
Дополнительную информацию см. в разделе «Salesforce Well-Architected - Liver».
Единые стандартные параметры
Единые параметры общего доступа определяют стандартный уровень доступа пользователей к записям друг друга. Используйте единые параметры общего доступа для блокировки данных на самом ограничительном уровне. Используйте другие инструменты безопасности записи и общего доступа для выборочного предоставления доступа другим пользователям. Например, пользователи имеют полномочия объекта для чтения и редактирования возможностей, а единый параметр общего доступа установлен на «Только для чтения». По умолчанию, эти пользователи могут просматривать все записи возможностей, но могут редактировать их только при наличии ответственности за запись или других полномочий.
Единые стандартные параметры можно изменить с одного параметра на другой («Личный» на «Контролируется родительским объектом», потом обратно на «Личный»). Однако, эти изменения требуют пересчета общего доступа и, в зависимости от объема, могут привести к длительному времени обработки.
Только для настраиваемых объектов можно настроить параметр «Предоставить доступ посредством иерархий». Если флажок не установлен (по умолчанию установлен), пользователи, расположенные выше в иерархии ролей, не могут наследовать доступ. Этот параметр находится в единых стандартных параметрах.
Иерархия ролей
Иерархия ролей представляет уровень доступа к данным, необходимый пользователю или группе пользователей. Иерархия ролей обеспечивает менеджерам всегда доступ к тем же данным, что и их сотрудникам, вне зависимости от единых стандартных параметров. Иерархии ролей не обязательно должны полностью соответствовать диаграмме организации. Каждая роль в иерархии должна представлять уровень доступа к данным, необходимый пользователю или группе пользователей.
В организациях Salesforce, созданных в выпуске Spring ’21 или более поздних, можно создать до 5 000 ролей. В организациях, созданных до выпуска Spring ’21, можно создать до 500 ролей и обратиться в службу поддержки Salesforce для увеличения этого ограничения. Рекомендуем ограничить количество внутренних ролей до 25 000, а количество внешних ролей до 100 000.
Рекомендуем использовать иерархию ролей не более чем на 10 уровнях иерархии.
При изменении роли пользователя оцениваются все соответствующие правила общего доступа для исправления доступа. Коллеги в одной роли не гарантируют им доступ к данным друг друга.
Моделирование иерархии ролей начинается с понимания структуры организации. Обычно это создается на основе понимания сферы охвата менеджера, начиная с верхнего уровня. Генеральный директор контролирует всю компанию. Генеральный директор обычно имеет прямые подчиненные, которые потом можно сегментировать по бизнес-единице (продажи или поддержка) или географическому региону (EMEA, APAC). Это лицо потом получает прямые подчиненные, которые могут быть дополнительно сегментированы и так далее. Хотя это очень похоже на организационную диаграмму отдела кадров, при моделировании доступа к данным сосредоточьтесь на доступности данных с учетом отчетности по персоналу.
Наложения всегда являются сложной частью иерархии. Если они находятся в собственном филиале, им потребуются правила общего доступа, рабочие группы или управление территориями для получения необходимого доступа. Если они будут сведены в иерархию, это может иметь последствия для отчетности.
Важно уделить время настройке иерархии ролей, поскольку это один из основополагающих аспектов модели общего доступа.
| Сценарии использования иерархии ролей |
|---|
| Доступ к управлению — это возможность менеджерам видеть и делать все, что видят и делают их подчиненные. |
| Управляющая отчетность – возможность сводки отчетов в иерархии, чтобы любому вышестоящему пользователю отображалось больше данных, чем нижестоящим пользователям. |
| Разделение между филиалами организации — разным бизнес-единицам не нужно просматривать данные друг друга; наличие иерархии, в которой можно определить отдельные филиалы, позволяет разделить доступность в бизнес-единицах, но при этом развернуть доступность до руководящих уровней выше этих единиц. |
| Разделение в роли — во многих организациях/приложениях люди, играющие одну роль, не обязательно должны видеть данные друг друга. Наличие иерархических ролей позволяет определить узел «лист», в котором все данные являются, по сути, личными, но при этом свести эти данные к родительской роли, которая может видеть все. |
Общедоступные группы
Общедоступная группа — это совокупность отдельных пользователей, ролей, территорий и т. д., имеющих общие функции. Общедоступные группы могут состоять из:
- Пользователи
- Пользователи клиентского портала
- Пользователи-партнеры
- Роли
- Роли и внутренние подчиненные роли
- Роли, внутренние подчиненные роли и подчиненные роли портала
- Роли портала
- Роли и подчиненные роли портала
- Территории
- Территории и подчиненные территории
- Другие общедоступные группы (вложение)
Группы могут быть вложены (группа А вложена в группу Б), но не могут содержать более пяти уровней. Вложение влияет на обслуживание и производительность группы из-за расчета состава участников группы. Рекомендуем ограничить общее количество общедоступных групп для организации 100 000.
| Общедоступные сценарии использования группы |
|---|
| Чтобы предоставить доступ произвольной группе людей, рекомендуем создать общедоступную группу для их сбора, а затем использовать другие инструменты общего доступа. Участие в группе само по себе не предоставляет доступ к данным. |
| Группы также могут быть вложены друг в друга, что позволяет вложенной группе получить тот же доступ, что и группе, в которой она содержится. Это позволяет создавать небольшие специальные иерархии, которые не обязательно взаимодействуют с иерархиями ролей или территорий. Если группа А является участником группы Б, то участники группы А будут иметь доступ к данным, общедоступным группе Б на том же уровне доступа, что и участники группы Б. |
| Группы также могут защитить данные, общедоступные в группе, от предоставления доступа вышестоящим пользователям в иерархии ролей. Это (а также управление доступом ответственных за записи и их иерархии управления) позволяет создавать группы, в которых можно предоставлять общий доступ к очень конфиденциальной информации - данные будут доступны ТОЛЬКО участникам группы, а не кому-либо другому в организации. Это выполняется посредством параметра «Предоставить доступ с использованием иерархий». |
Правила общего доступа на основе ответственности
Правила общего доступа на основе ответственности допускают исключения из единых стандартных параметров и иерархии ролей, которые предоставляют дополнительным пользователям доступ к чужим записям. Правила общего доступа на основе ответственности определяются только ответственным за запись.
Правила общего доступа на основе ответственного за контакт не применяются к личным контактам или контактам, не связанным с организацией.
Ограничение общего количества правил общего доступа на объект составляет 300.
| Сценарии использования правил общего доступа на основе ответственности |
|---|
| Матричное управление на основе ролей или ситуации наложения: человек в службе должен иметь возможность видеть некоторые данные продаж, но он живет в разных ветвях иерархии, поэтому можно создать правило, которое предоставляет общий доступ к данным между ролями в разных ответвлениях. |
| Для предоставления доступа к данным коллегам, выполняющим ту же роль или территорию. |
| Для предоставления доступа к данным другим группировкам пользователей (общедоступные группы, роли портала, территории). Участники группировок, ответственные за записи, могут быть общедоступны участникам других группировок. |
Правила общего доступа на основе критериев
Правила общего доступа на основе критериев предоставляют доступ к записям на основе значений полей (критериев) записи. Если критерии соблюдены (одно или несколько значений полей), для правила создается запись общего доступа. Ответственность за запись не учитывается.
Ограничение правил общего доступа на основе критериев и пользователей-гостей для объекта составляет 50.
| Сценарий использования правил общего доступа на основе критериев |
|---|
| Для предоставления доступа к данным пользователям или группам на основе значения поля в записи. |
Правила общего доступа пользователей-гостей
Правило общего доступа пользователя-гостя - это специальный тип правила общего доступа на основе критериев, используемый для предоставления доступа к записям непроверенным пользователям-гостям. Ограничение правил общего доступа на основе критериев и пользователей-гостей для объекта составляет 50.
Предупреждение: Тип правила общего доступа пользователя-гостя предоставляет доступ пользователям-гостям без регистрационных данных входа. Создавая правило общего доступа пользователя-гостя, вы разрешаете немедленный и неограниченный доступ ко всем записям, соответствующим критериям правила общего доступа любому пользователю. Чтобы обезопасить данные Salesforce и предоставить пользователям-гостям доступ к нужным сведениям, рассмотрите все сценарии использования и последствия создания данного типа правил общего доступа. Внедрите средства контроля безопасности, которые, по вашему мнению, подходят для конфиденциальности данных. Salesforce не несет ответственности за предоставление доступа к данным непроверенным пользователям на основе этого изменения стандартных параметров.
| Сценарий использования правила общего доступа пользователя-гостя |
|---|
| Для предоставления доступа к данным непроверенным пользователям-гостям. |
Общий доступ, установленный вручную
Иногда невозможно определить последовательную группу пользователей, которым нужен доступ к определенному набору записей. Ответственные за записи или другие пользователи с соответствующими полномочиями, например, системные администраторы, могут использовать общий доступ вручную для предоставления полномочий чтения и редактирования пользователям, не имеющим доступа другим способом. Общий доступ, установленный вручную, не автоматизирован, как единые параметры общего доступа, иерархии ролей или правила общего доступа. Но он предоставляет ответственным за записи возможность предоставления общего доступа к записям пользователям, которые должны их видеть.
Общий доступ, установленный вручную, удаляется при изменении ответственного за запись или при отсутствии дополнительного доступа, превышающего стандартный уровень общего доступа для всего объекта. Это также относится к общим ресурсам, созданным программным способом.
Записи общего доступа, созданные вручную, определяются как записи общего доступа с причиной строки, установленной на общий доступ, установленный вручную.
Все записи общего доступа (стандартные и настраиваемые объекты), причина строки которых установлена на «Общий доступ», могут быть отредактированы и удалены кнопкой «Общий доступ» в макете страницы объекта, даже если запись общего доступа была создана программным способом.
| Сценарий использования общего доступа вручную |
|---|
| Чтобы предоставить пользователю возможность доступа (только для чтения или чтения/записи) к текущей записи другим пользователям, группам или ролям. |
Группы
Группа — это группа пользователей, работающих совместно над организацией, возможностью продажи или обращением. Ответственные за запись могут создать рабочую группу для каждой записи, за которую они ответственны. Ответственный за запись добавляет участников рабочей группы и определяет уровень доступа каждого участника рабочей группы к записи. Некоторые участники рабочей группы могут иметь доступ только для чтения, в то время как другие имеют доступ для чтения и записи.
Добавлять участников рабочей группы и предоставлять им больше доступа могут только ответственные, вышестоящие лица в иерархии и администраторы. Участник рабочей группы с доступом для чтения и записи может добавить еще одного участника, который уже имеет доступ к записи, связанной с рабочей группой. Участник рабочей группы не может предоставить ему дополнительный доступ.
Создание участника рабочей группы в приложении создает две записи: запись рабочей группы и связанную запись общего доступа. При программном создании участников рабочей группы необходимо управлять записью рабочей группы и связанной записью общего доступа. На запись (организация, возможность или обращение) приходится только одна рабочая группа. Если требуется несколько групп, в зависимости от ваших конкретных потребностей, рассмотрите управление территориями или программный общий доступ
| Сценарии использования рабочей группы |
|---|
| Предоставить пользователю возможность предоставления доступа (только для чтения или чтения/записи) отдельной группе пользователей (группе). |
| Если рабочие группы управляются внешне, например, посредством внешней комиссии или системы управления территориями, интеграция может использоваться для управления рабочей группой, работающей с организациями. Существуют случаи, когда управление территориями во внешней системе может соответствовать решению рабочей группы в Salesforce. |
| Группа, работающая с организациями, может управлять несколькими ответственными за организацию. |
| Отдельной группе пользователей (группе) нужен доступ только для чтения или чтения/записи к записи возможности. (Группа, работающая с возможностями) |
Иерархия территорий
При использовании управления территориями предприятия вы настраиваете иерархию территорий, которая отображает структуру территории модели и служит ее основным местом взаимодействия. Если управление территориями предприятия включено, необходимо управлять иерархией ролей и иерархией территорий. Дополнительную информацию см. в разделе «Управление территориями предприятия» справки Salesforce.
Управляемый общий доступ Apex
Управляемый общий доступ Apex (также известный как программный общий доступ) позволяет использовать код для создания сложных и динамических параметров общего доступа, когда требование доступа к данным не может быть выполнено другими способами.
Если запись общего доступа создается программным способом и используется готовая причина строки (общий доступ), эту запись общего доступа можно сохранить кнопкой «Общий доступ» в приложении. Запись общего доступа подчиняется всем правилам с причиной строки общего доступа вручную, например, удаление при передаче ответственного.
Можно также создать собственные причины общего доступа к Apex для настраиваемых объектов, чтобы отслеживать, почему запись с пользователем или группой пользователей, и упростить кодирование, необходимое для внесения обновлений и удалений записей общего доступа.
Дополнительные сведения см. в разделе «Общий доступ к записи посредством Apex», прежде чем использовать программный общий доступ.
| Сценарии использования управляемого общего доступа Apex |
|---|
| Ни один другой метод общего доступа (декларативный) не соответствует потребностям доступа к данным. |
| Существует существующая внешняя система истины для назначений доступа пользователей, которая будет продолжать стимулировать доступ и будет интегрирована с Salesforce. |
| Плохая производительность посредством нативных компонентов общего доступа. (Обычно применяется к очень большим объемам данных) |
| Функции рабочей группы для настраиваемых объектов. |
Правила ограничения
В конфигурации доступа к данным можно запретить пользователям просмотр записей, которые могут содержать конфиденциальные данные или просто не являются важными для их работы. Правила ограничения позволяют пользователям просматривать только записи, соответствующие заданным критериям. Если правило ограничения применяется к пользователю, записи, доступные пользователю посредством единых стандартных параметров, правил общего доступа и других механизмов общего доступа, фильтруются по указанным критериям. Правила ограничения работают в обратном порядке, как и компоненты общего доступа, обсуждаемые в этой теме; вместо открытия доступа пользователям они еще больше ограничивают его.
Правила ограничения доступны для настраиваемых объектов, внешних объектов, контрактов, событий, задач, табелей учета и записей табелей учета. Разрешается создавать не более двух активных правил ограничения на объект в выпусках Enterprise и Developer и не более пяти активных правил ограничения на объект в выпусках Performance и Unlimited. Правила ограничения применяются к следующим функциям Salesforce:
- Списковые представления
- Поиски
- Связанные списки
- Отчеты
- Поиск
- SOQL
- SOSL
| Сценарии использования правила ограничения |
|---|
| Вы хотите, чтобы определенные пользователи видели только определенный набор записей. |
| Для упрощения управления доступом к записям с конфиденциальной или конфиденциальной информацией. |
| Чтобы сделать доступ к контрактам, задачам и событиям по-настоящему личным, поскольку это может быть трудно сделать с помощью единых стандартных параметров. |
Неявный общий доступ
Скрытый общий доступ предоставляется автоматически. Его нельзя ни выключить, ни включить, он является родным для приложения. Другими словами, скрытый общий доступ не является настраиваемым параметром, однако, важно понимать его любому архитектору. Родительский скрытый общий доступ — это предоставление доступа к родительским записям (только организациям), если у пользователя есть доступ к дочерним возможностям, обращениям или контактам для этой организации. Salesforce использует политику доступа к данным, которая определяет, может ли пользователь видеть контакт (или возможность, обращение или заказ), а затем скрыто связанную организацию. Дочерний скрытый общий доступ — это предоставление ответственному за организацию доступа к дочерним записям организации. Данный доступ определяется ролью ответственного в иерархии ролей. Дочерний скрытый общий доступ применяется только к объектам контакта, возможности и обращения (дочерние организации). Доступные уровни: просмотр, редактирование и отсутствие доступа для каждого дочернего объекта при создании роли. Установив значение «Просмотр», ответственный за организацию может скрыто просматривать связанные записи объекта (контакт, возможность или обращение). Установив значение «Правка», ответственный за организацию может скрыто изменить связанный объект (контакт, возможность или обращение).
Скрытый общий доступ не применяется к настраиваемым объектам.
Нет модели общего доступа, подходящей для всех организаций Salesforce. Каждая организация имеет разные требования и задачи при создании лучшей модели общего доступа. Важно использовать наиболее подходящие компоненты доступа к данным в соответствии с требованиями общего доступа организации. Ниже перечислены распространенные проблемы при создании модели общего доступа.
| Требования или проблемы | Решение |
|---|---|
| Два в поле: менеджер по продажам одной географической зоны покрытия также хочет получить доступ к другой географической зоне покрытия для оказания помощи. | Правило общего доступа на основе ответственности: Правило общего доступа на основе ответственности работает здесь, поскольку это краевые случаи, а не норма. Также допустимо, если правило общего доступа на основе ответственности предоставляет больше доступа, чем действительно необходимо, поскольку это менеджер – надежное лицо. |
| Пользователям страновых операций нужен доступ ко всем данным о продажах в странах. | Правило общего доступа на основе ответственности: Правило общего доступа используется очень часто, когда другой отдел (кроме отдела продаж) нуждается в доступе к данным продаж. |
| Как минимум в 80% случаев в организации есть рабочая группа «core 4» (руководитель организации, торговый представитель, продавец-консультант, технический торговый представитель). Система записи для назначения группы, работающей с организациями, является внешней. В организации всегда есть только одна команда. | Группы: Поскольку на организацию всегда приходится только одна рабочая группа, даже при наличии большого количества разных участников с разными ролями, функции группы, работающей с организациями, соответствуют этому требованию. |
| Менеджеры рабочей группы должны иметь такой же доступ, как и их подчиненные. | Иерархия ролей: Иерархия ролей решает это требование, предоставляя менеджерам доступ к данным своих подчиненных. |
| Назначенная группа, работающая с организациями, не должна быть изменена. | Группы: Это требование фактически не выполняется с функциями группы, работающей с организациями. Однако, это также не должно препятствовать использованию групп, работающих с организациями. Однако существует несколько способов блокировки групп. В данном случае используется удаление макета страницы группы, работающей с организациями. |
| Должна быть функция «приятель», чтобы при болезни или отпуске к кому-то, у кого нет стандартного доступа к организации или возможности, можно было получить доступ и покрытие в свободное время. | Группы: «Приятелем» может быть роль в рабочей группе, выполняющей данное требование. Однако, проблема связана с предыдущим требованием, когда рабочие группы не должны быть изменены. Единственное решение - наличие заданной группы людей, которые могут изменить рабочие группы для создания роли приятеля при необходимости. |
| Если сделка требует настраиваемого решения, дополнительные люди (которые не обязательно входят в организацию продаж) должны иметь доступ к сделке. | Группы: Довольно стандартное использование группы, работающей с возможностями, выполнено путем добавления вручную нового участника в группу, работающую с возможностями (посредством связанного списка). Можно также выполнить посредством триггера, если вы всегда знаете, кого следует добавить. В данном случае это возможность по возможности. |
| Требования или проблемы | Решение |
|---|---|
| Две разные группы, работающие с возможностями, из двух разных бизнес-единиц (розничные продажи и ремаркетинг) нуждаются в доступе к одной записи организации. Они должны предоставлять общий доступ к контактам и быть в курсе всех действий в организации. Эти две бизнес-единицы имеют собственную иерархию и сводки. | Управление территориями: Лучший способ представить это требование - наличие двух ветвей иерархии, которые могут иметь разную структуру. Управление территориями оправдывается наличием двух уровней этих двух разных ответвлений (оба уровня с участниками = группа, работающая с возможностями для данной бизнес-единицы), которым нужен доступ к организации. Хотя вы могли бы выполнить это требование с помощью концепции «Группировка», это было слишком детализировано. Сегментация продаж проходила не на уровне организации, а в иерархии. |
| Существует отдельная группа бизнес-разработчиков, которым назначены и которым нужен доступ к определенным организациям для определенной группы, работающей с возможностями (территория). Бизнес-разработчики являются общими ресурсами для групп, работающих с возможностями, то есть каждый бизнес-разработчик может быть назначен одной или нескольким организациям для одной или нескольких групп, работающих с возможностями. | Управление территориями: Поскольку это группа пользователей (или рабочая группа), и каждая рабочая группа по развитию бизнеса может отличаться по организации, а также поскольку управление территориями было необходимо по другой причине, вероятный лучший подход - создать подтерритории или отдельные филиалы, представляющие эти рабочие группы по развитию бизнеса. |
| Существуют роли поддержки продаж без комиссии, которым нужен разовый доступ к организациям. | Группы: Ключевой частью требования является «разовая основа». Это значит, что это выполняется на основе организации за организацией, поэтому группы, работающие с организациями, предоставляют это нативно. |
| Кредитному отделу нужен доступ ко всем организациям для данной бизнес-единицы. | Правило общего доступа на основе ответственности: Это ситуация, когда группа пользователей должна просматривать все по всем направлениям для данной бизнес-единицы. Это требование может быть выполнено посредством правила общего доступа для роли, к которой принадлежит группа, ответвления иерархии ролей, к которой принадлежит группа (роль и подчиненные) или даже общедоступной группы.Управление территориями: Вы также можете выполнить это требование, смоделировав кредитный отдел как территорию с одинаковой логикой для данной бизнес-единицы. |
| Менеджеры должны иметь такой же доступ, как и их подчиненные. | Иерархия ролей: Иерархия ролей решает это требование, предоставляя менеджерам доступ к данным своих подчиненных. |
-
Что происходит с иерархией ролей?
-
Если вы также используете иерархию территорий, с иерархией ролей ничего не происходит. Однако, если вы используете прогнозирование на основе территории и ролевое прогнозирование вместе, необходимо управлять двумя иерархиями. В этом случае рекомендуем использовать иерархию ролей для моделирования структуры кадровой отчетности, а потом использовать иерархию территорий для моделирования фактической иерархии продаж. Иерархия территорий лучше подходит для моделирования структуры матричной отчетности, где кто-то может отчитываться перед несколькими менеджерами.
Если вы не используете прогнозирование на основе территории и ролевое прогнозирование вместе, можно использовать только иерархию территорий в качестве иерархии продаж. При таком раскладе лучше упростить или максимально выровнять иерархию.
Не рекомендуем делать иерархию ролей и иерархию территорий идентичными, поскольку это приводит к ненужным действиям общего доступа.
-
-
Можно ли использовать рабочие группы?
- Да. Однако, если вы можете соответствовать требованиям к доступу в иерархии территорий (например, наложения), лучше делать это там, чем использовать рабочие группы. У вас уже есть несколько иерархий (роли и территории), поэтому, стараясь упростить процесс, внедряйте рабочие группы, только если ни один из существующих компонентов общего доступа не будет соответствовать требованиям.
-
Перестройка и переназначение
- Происходят два типа изменений – участие в ролях, группах или территориях и структура иерархии. Изменение состава участников обычно происходит ежедневно, даже ежечасно. Структурные изменения иерархии (перестройки) обычно происходят реже (ежеквартально, раз в полгода или ежегодно) и могут быть дорогостоящими. Необходимо учитывать объем изменений и количество каскадных изменений, к которым приведет каждое изменение. Как правило, структурные изменения происходят не чаще одного раза в квартал, а все изменения большого объема (пакетные или массовые изменения) должны быть хорошо спланированы, протестированы и скоординированы.
-
Большие объемы данных
-
Вне зависимости от того, моделированы ли вы для первичного развертывания или планируете изменение перестройки, необходимо серьезно учитывать объем данных. Существуют пороги, где производительность может стать фактором, поэтому тестирование изменений в безопасной среде настоятельно рекомендуется перед производством. Это тестирование также даст вам базовый показатель продолжительности изменения.
При наличии более двух миллионов организаций и внедренных рабочих групп или функции управления территориями предприятия необходимо обращать особое внимание на производительность. Это сложные компоненты модели общего доступа, которые могут создавать огромный объем записей общего доступа и, следовательно, длительные транзакции.
-
-
Отсрочка расчетов общего доступа
- При наличии объекта, использующего общий доступ и содержащего большой объем записей (например, более двух миллионов организаций), и необходимости пакетного изменения (например, ежеквартальная перестройка, требующая изменения иерархии), существует функция, позволяющая службе поддержки Salesforce откладывать автоматические расчеты общего доступа. Нативно, каждое отдельное изменение иерархии ролей, иерархии территорий, групп, правил общего доступа, ролей пользователей, состава рабочей группы или ответственности за записи может инициировать автоматические расчеты общего доступа. При пакетном изменении запускается ряд автоматических пересчетов общего доступа. Временно приостановив эти пересчеты, вы сможете внести изменение, а потом выполнить все расчеты общего доступа одновременно. Этот метод обычно более эффективен и лучше работает для пакетных изменений.
-
Перекосы данных и ответственности
-
Перекосы данных определяются как несколько родительских записей с большим количеством дочерних записей. Эти перекосы могут навредить вам, если в нескольких организациях много контактов, возможностей или обращений. Соотношение, при котором начинается снижение производительности, составляет 1:10000. Рекомендуем поддерживать соотношение как можно ближе к этому показателю (предпочтительно более низкое).
Перекосы ответственности аналогичны перекосам данных, за исключением отдельного пользователя, роли или группы, ответственных за много записей для объекта. Как и в случае с искажениями данных, они также могут привести к длительным транзакциям, что приведет к ухудшению производительности при изменении. Рекомендуемое соотношение ответственного к количеству записей также составляет 1:10000.
Если один пользователь владеет более 10 000 записей, рекомендуем выполнить следующие действия:
-
Запись пользователя ответственного не должна содержать роль в иерархии ролей.
-
Если запись пользователя ответственного должна содержать роль, разместите роль вверху иерархии в собственной ветви иерархии ролей.
-
-
-
Влияние иерархий организаций на доступ к данным
- Многие люди делают плохие предположения при внедрении иерархии организаций. Они предполагают, что пользователи, имеющие доступ к родительской организации, также могут получить доступ к дочерним организациям. Простой факт наличия взаимосвязи «родительский-дочерний» между двумя записями не влияет на доступ. Хотя иерархия ролей и иерархия территорий работают таким образом, иерархия организаций не работает.
После завершения создания архитектуры модели общего доступа у вас, скорее всего, возникнут проблемы с тем, почему пользователь может или не может видеть запись. Как правило, вы не услышите, когда пользователи могут видеть то, что не должны видеть, но при необходимости, есть способ увидеть каждого пользователя, имеющего доступ к записи, и почему.
Более сложная задача и, вероятно, более распространенная - почему пользователь не видит запись. Архитектурированные уровни безопасности определяют место начала. Если вы хорошо знаете модель общего доступа, вы, вероятно, будете знать, какой компонент должен был предоставить доступ и можно начать с него. Но если вы меньше знакомы с моделью общего доступа, начните с иерархии ролей и отклейте каждый слой, чтобы определить, какой из них должен предоставить доступ. Ниже указан поток устранения неполадок.
- Проверьте наличие у пользователя полномочий на доступ к объекту.
- Определите роль пользователя, который не видит запись, и запишите ее.
- Определите ответственного за роль записи и запишите ее.
- Просмотрите иерархию ролей и убедитесь, что эти две роли находятся в двух разных ответвлениях (они должны быть).
- Теперь необходимо просмотреть правила общего доступа для объекта и убедиться в отсутствии правила, предоставляющего пользователю доступ. При необходимости просмотрите также общедоступные группы. Возможно, пользователь не попал в группу, где есть правило общего доступа, или имеет смысл создать новое правило общего доступа, чтобы предоставить пользователю доступ? Этот выбор зависит от используемой архитектуры и применяется как к правилам общего доступа на основе ответственности, так и к правилам общего доступа на основе критериев.
- Если вы используете рабочие группы, должен ли этот пользователь быть в рабочей группе для этой записи? Как обслуживаются рабочие группы и как произошел промах?
- Если общий доступ используется вручную, пользователь может потерять доступ из-за смены ответственного за запись. Общий доступ, установленный вручную, пропускается при изменении ответственности. Кроме того, общий доступ, установленный вручную, может быть удален посредством кнопки «Общий доступ».
- При использовании функции управления территориями предприятия пользователь отсутствует на одной из территорий? Где сохраняется принадлежность территорий и как произошел промах? Или, возможно, запись не была назначена территории, участником которой является пользователь.
- Если вы создаете программный общий доступ и существуют критерии создания общего доступа в коде, просмотрите код, чтобы понять, почему этот пользователь был пропущен.