8. 공유 모델은 세일즈포스 Org에서 데이터 접근/제한을 제공하는 데 필수적인 요소입니다.
따라서 현재 및 미래의 데이터 액세스 요구 사항을 충족하도록 공유 모델을 올바르게 설계하는 것이
중요합니다.
제외 항목
이 문서에서 다루지 않은 주제 :
• 폴더 액세스
• 컨텐츠(파일) 액세스
• 채터 액세스
• Knowledge Base 액세스
• Ideas, Questions/Answers 액세스
• Salesforce2Salesforce
• 모바일 데이터 접근성
공유 아키텍처 소개
9. License
• Full Sharing Model Usage Users/Licenses
• High Volume Customer Portal License
• Chatter Free License
데이터 접근 유형
구성요소
• Profiles and Permission Sets
• Record Ownership and Queues
• Organization-Wide Defaults
• Role Hierarchy
• Public Groups
• Ownership-based Sharing Rules
• Criteria-based Sharing Rules
• Manual Sharing
• Teams
• Territory Hierarchy
• Account Territory Sharing Rules
• Programmatic Sharing
• Implicit Sharing
10. Full Sharing Model Usage Users/Licenses
일반적인 세일즈포스 License에 해당합니다. 예를 들면 Salescloud, ServiceCloud, Lightning Platform License가
이에 해당합니다. License 별로 접근 할 수 있는 스탠다드 오브젝트의 제한이나 커스텀 오브젝트의 수가 다르지만
공유 아키텍처는 동일하게 적용 됩니다. 유저는 License가 상향될 경우 제한된 접근 권한이 활성화 됩니다.
License는 상향만 가능하며 제한된 License로 변경 할 수 없습니다.
High Volume Customer Portal License
HVPU (High Volume Customer Portal) License 사용자 (커뮤니티 및 Service Cloud License 사용자 포함)는 위 공유
모델을 사용하지 않습니다. HVPU License에는 포털 사용자와 계정 및 연락처와 Lookup관계의 데이터와 외래 키로
작동하는 자체 공유 모델이 있습니다. HVPU License는 Partner 포털이 아닌 Customer 포털에만 사용됩니다.
Chatter Free License
Chatter Free License는 표준 공유 모델을 따르지 않습니다. Chatter Free는 Chatter, Profile, People, Groups, Files,
Chatter Desktop 및 제한된 Salesforce 앱 액세스 기능이 있는 채터 전용 License입니다. License는 CRM 레코드 (표준
또는 사용자 정의 오브젝트) 및 콘텐츠 기능에 액세스 할 수 없으므로 공유가 없습니다.
License
11. Profiles and Permission Sets
Profiles and Permission Sets은 사용자가 특정 오브젝트의 읽기, 쓰기, 생성, 삭제 여부를 결정하여 오브젝트 레벨의
보안을 제공합니다. 각 오브젝트에 대해 ‘모두보기’ 및 ‘모두 수정’ 권한은 공유 규칙 및 설정을 무시하므로 관리자가 조직
전체에서 지정된 오브젝트와 관련된 레코드에 대한 액세스 권한을 신속하게 부여 할 수 있습니다. 또한 시스템 권한 중
‘모든 데이터 보기’, ‘모든 데이터 수정’ 권한을 통해 모든 공유 규칙을 무시하는 데이터 접근성을 제공 할 수 있습니다.
Profiles and Permission Sets은 사용자의 필드 레벨의 보안을 제공합니다. 예를 들어 오브젝트에 20개에 필드가
존재하지만 특정 Profiles의 사용자에게는 5개의 필드만 수정 권한을 부여 할 수 있습니다.
Permission Sets은 프로필에서 정의한 데이터 접근권한보다 더 강력한 권한을 특정 유저에게 제공할 때 사용 할 수
있습니다.
Components
12. Record Ownership and Queues
Master-Detail 관계 중 Detail인 오브젝트를 제외한 모든 오브젝트의 모든 레코드는 사용자 또는 큐가 소유자로
설정됩니다. 소유자인 유저는 자신의 프로필의 오브젝트 접근 권한 설정에 따라 레코드에 액세스 할 수 있습니다.
예를 들어 유저의 프로필에 ‘생성’, ‘읽기’ 권한만 존재하는 오브젝트의 레코드를 생성하면 소유자는 레코드의 상세 내역을
볼 수 있지만 수정하거나 삭제 할 수 없습니다. 상위 계층(Role, Territory)의 사용자는 하위 사용자의 스탠다드
오브젝트에 액세스 권한을 동일하게 부여 받습니다. 하위 사용자가 읽기 권한만 있을 경우 상위 계층 사용자 역시
읽기 권한만 부여됩니다. 하위사용자 소유 레코드 및 공유 받은 레코드에 적용됩니다.
Queue를 사용하면 레코드의 소유권을 Queue에 속한 멤버에게 할당하고 소유권을 멤버 중에서 선택 할 수 있습니다.
Queue에 할당되어 소유권이 유저로 변경되지 않은 레코드는 Queue의 멤버 그리고 그 상위 계층 사용자가 오너가 될 수
있습니다. Queue는 별도의 List view를 통해 레코드 목록을 볼 수 있습니다.
Ownership Skew
만약 유저가 10,000개 이상의 레코드를 소유하면 소유권 일괄 변경, 사용자의 Role 변경, 공유 규칙 적용 등 공유 모델
재계산의 성능저하가 발생합니다. 이를 Ownership Skew라 칭합니다. 유저가 10,000개 이상의 레코드를 소유 하지
않도록 관리해야 하고 만약 불가피 할 경우 해당 유저는 Role의 최고 레벨에 두어 공유 규칙 재계산 시
영향 받는 유저가 없도록 하여 피할 수 있습니다.
Components
13. Organization-Wide Defaults
Organization-Wide Defaults(OWD)는 사용자가 각 레코드에 대한 기본 액세스 수준을 지정합니다.
OWD를 사용하여 각 오브젝트의 접근 권한 수준을 조직 전체의 가장 제한적은 수준으로 적용한 후 다른 공유 기능을
이용하여 다른 사용자에게 조건에 따른 접근 권한을 부여 할 수 있습니다.
예를 들어 기회의 OWD는 읽기 전용(Read only)이고 각 사용자는 프로필, 권한 집합에 의해 기회에 읽기 권한이 있는
경우 사용자는 모든 기회를 조회 할 수 있습니다. 하지만 추가로 수정권한을 부여 받지 않으면 수정 할 수 없습니다.
OWD는 레코드 접근 권한을 제한 할 수 있는 유일한 방법입니다. 다른 공유 기능을 추가 권한만 부여 할 수 있습니다.
OWD를 수정하여 개인소유(Private)에서 공용읽기(쓰기)로 변경할 수 있습니다. 이러한 변경은 공유 규칙 재계산이
필요하고 레코드 수에 따라 처리 시간이 매우 길어 질 수 있습니다.
그리고 커스텀 오브젝트는 계층(Hierarchies) 권한 부여 사용여부를 선택 할 수 있습니다. 스탠다드 오브젝트는 선택 할
수 없습니다. 기본값은 계층 권한 부여이며 만약 상위 계층의 사용자가 하위 계층의 사용자의 레코드에 접근하면 안되는
경우 이 옵션을 사용하여 제한 할 수 있습니다.
Components
14. Role Hierarchy (1/2)
역할 계층(Role Hierarchy)은 사용자 또는 사용자 그룹에 필요한 데이터 액세스 수준을 나타냅니다.
역할 계층을 통해 상위 계층 사용자는 OWD에 관계없이 항상 하위 직원과 동일한 데이터에 액세스 할 수 있습니다.
역할 계층은 회사의 조직도와 일치 할 필요는 없습니다. 다만 각 역할은 데이터 접근 권한의 레벨로써 하위 사용자의
데이터에 접근하는 수준을 정합니다.
역할 계층은 500개까지 설정 할 수 있습니다. 그러나 세일즈포스의 지원을 통해 수를 늘릴 수 있습니다.
그러나 Internal User의 역할 수는 25,000으로, 포털(커뮤니티) 역할 수는 100,000으로 유지하십시오.
또한 최적의 성능을 위해 역할의 계층은 10단계 이하로 유지하여야 합니다. 역할의 계층이 많은 수록 사용자의 역할
변경에 따른 공유 규칙 재계산의 시간이 증가하여 성능저하가 발생 할 수 있습니다.
그리고 같은 역할의 속한 사용자 간의 데이터 접근은 보장되지 않습니다. 같은 역할의 사용자의 데이터에 접근하기
위해서는 추가적인 공유설정이 필요합니다.
Components
15. Role Hierarchy (2/2)
역할 계층 모델링은 조직의 구성을 이해하는 것으로 시작합니다. 일반적으로 최상위에서 시작하여 하위 사용자의
접근 범위를 구체화 하여 구성합니다. 예를 들어 대표이사는 조직 전체 데이터를 볼 수 있습니다. 각 사업부장은 자신의
사업부 데이터만 볼 수 있습니다. 팀장은 자신의 팀원의 데이터만 볼 수 있습니다. 이러한 구성은 인사조직도와
유사하지만 일치하지 않을 수 있습니다. 예를 들어 경영기획실은 회사의 조직도상 영업조직 상위에 있고 모든 영업
정보를 보고받는 역할입니다. 하지만 경영기획실의 사용자가 영업조직의 기회 이외의 데이터(일정, 할 일, 연락처 등)을
볼 권한은 없다고 할 경우 경영 기획실은 역할 계층에서 영업의 상위에 위치 하면 안됩니다. 경영기획실은 영업조직과
병렬로 구성하고 다른 공유 기능을 통해 기회 정보를 공유 받는 방법으로 해결 할 수 있습니다.
겸직 또는 사업부, 제품별 보고체계에 따른 역할 계층을 까다로운 부분입니다. 이 경우 필요한 접근 권한을 부여 하려면
공유 규칙, 팀, 또는 영역 관리(Territory Management)를 고려해야 합니다. 복잡한 역할 계층은 보고서 데이터 범위 등에
예상치 않은 영향을 줄 수 있습니다.
역할 계층은 전체 공유 모델의 기반이기 때문에 구체적인 데이터 접근/제한 사례를 조사하여 설정하는데 시간을
사용해야 합니다.
Components
16. Components
Role Hierarchy Use Cases
상급자 접근부여 – 상위 역할 사용자가 부하 직원의 모든 레코드에 대한 접근 권한 동일하게 부여 받음
보고 관리 – 계층 구조의 상위에 있는 사용자가 그 아래에 있는 사용자보다 더 많은 데이터를 볼 수 있도록 계층적 방식으로
보고서에서 데이터 취합
조직(부서/지사 등) 간 분리 – 다른 조직의 데이터를 서로 볼 필요가 없는 경우 역할 계층을 병렬 구성하여 조직 간 데이터
가시성을 분리하지만 경영진(최고 역할 사용자)은 조직 통합 데이터를 볼 수 있음
역할 내 분리 – 같은 역할의 사용자간 데이터를 공유할 필요는 없음. 같은 역할 계층에 있는 사용자의 데이터 가시성을
분리하여 비공개로 데이터를 소유하지만 상위 역할의 사용자는 모든 데이터를 볼 수 있음
17. Public Groups
공개 그룹(not Chatter Group)은 공통적인 특징, 기능을 가진 개별 사용자, 역할, 영역 등의 모음입니다.
공개 그룹은 다음으로 구성 될 수 있습니다.
• Users, Customer Portal Users, Partner Users
• Roles, Internal Subordinates, Internal and Portal Subordinates, Portal Roles, Portal Roles and Subordinates
• Territories, Territories and Subordinates
• Other public groups (중첩)
그룹은 중첩 될 수 있지만 (그룹 A는 그룹 B에 중첩) 5 단계 이상 중첩해서는 안됩니다. 중첩은 그룹 내 멤버십에 따른 공유
재계산으로 인해 그룹 유지 관리 및 성능에 영향을 줍니다. 조직의 총 공개 그룹 수를 100,000으로 유지하는 것이 권장 합니다.
개인 그룹(Personal Group) : 각 사용자는 개인 용도로 그룹을 만들 수 있습니다. 예를 들어, 사용자는 특정 레코드를 자신이 지정한
사용자 그룹에 공유 할 수 있습니다.
Components
18. Components
Public Groups Use Cases
임의의 사용자 그룹에 대한 액세스 권한을 제공해야하는 경우 공개 그룹을 생성, 멤버를 할당 한 후 다른 공유 도구를
사용하여 그룹에 필요한 액세스 권한을 부여하십시오. 그룹구성 자체는 추가 접근 권한을 부여하지 않습니다.
그룹은 서로 중첩 될 수도 있으므로 중첩 된 그룹이 포함 된 그룹과 동일한 액세스 권한을 얻을 수 있습니다. 이를 통해 역할
또는 영역 계층 구조와는 별개의 소규모 임시 계층을 만들 수 있습니다. 예를 들어 그룹 A가 그룹 B의 구성원 인 경우 그룹 A의
구성원은 그룹 B의 구성원과 동일한 접근 권한에서 그룹 B와 공유 된 데이터에 액세스 할 수 있습니다.
상위 그룹이 하위 그룹에 포함되야 계층과 같은 효과를 얻을 수 있습니다.
매우 기밀을 요하는 정보를 커스텀 오브젝트에 기록하고 제한된 그룹에게만 공유하여 데이터를 보호 할 수 있습니다.
계층 공유가 비활성화된 커스텀 오브젝트에 계층공유가 비활성인 공개그룹에 공유하여 레코트 소유자 및 해당 공개 그룹에만
접근 권한을 부여합니다.
그 외 조직 내 다른 누구도 액세스 할 수 없습니다.
19. Ownership-based Sharing Rules
소유권 기반 공유 규칙을 사용하면 OWD 및 상위 계층 공유, 소유권이 없는 레코드에 접근권한을 부여 할 수 있습니다.
소유권 기반 공유 규칙은 레코드 소유자만을 기준으로 부여합니다.
연락처 소유권 기반 공유 규칙은 개인 연락처 (계정이 없는)에는 적용되지 않습니다.
오브젝트 당 소유권 기반 공유 규칙 수를 1,000이하로 유지하십시오.
Ownership-based Sharing Rule Use Cases
역할 기반 매트릭스 관리 또는 오버레이 상황 : 서비스 담당자는 담당하는 영업영역의 기회 레코드에 접근해야 하지만
병렬된 역할 계층에 속해 볼 수 없습니다. 이경우 소유자 기반 공유 규칙을 사용하여 기회 레코드를 서비스 담당자에게 공유 할
수 있습니다.
같은 역할 / 영역을 가진 동료에게 데이터 액세스를 제공 :
레코드 소유자와 같은 역할 / 영역에 속한 사용자에게 데이터 접근 권한을 부여합니다.
부서내 기회를 공유하는 경우 이 기능을 사용하여 해결 할 수 있습니다.
Components
20. Criteria-based Sharing Rules
기준 기반 공유 규칙을 통해 레코드의 필드 값 (기준)을 기반으로 레코드에 액세스 권한을 부여 할 수 있습니다.
기준이 충족되면 (하나 이상의 필드 값) 규칙에 대한 공유 레코드가 작성됩니다. 레코드 소유권은 고려되지 않습니다.
오브젝트 당 기준 공유 규칙 수를 50으로 유지하십시오. 그러나 Salesforce 요청하여 증가 할 수 있습니다.
레코드 수가 많고 (High Volume Data) 값 변경이 자주 발생하고 특정 값에 해당하는 레코드가 많을 경우 성능 저하가 발생 할 수
있습니다. 이 경우 다른 공유 기능을 고려하십시요.
Components
21. Manual Sharing
레코드 공유 규칙을 적용 할 수 없는 비 일상적인 공유가 필요한 경우가 있습니다. 이 경우 레코드 소유자는
매뉴얼 공유를 통해 레코드 접근 권한을 다른 사용자에게 부여 할 수 있습니다. 매뉴얼 공유는 자동화 할 수 없지만 레코드에
접근이 필요한 경유 공유 할 수 있도록 유연성을 제공합니다. 이 기능은 프로그램 방식의 공유에서도 사용 할 수 있습니다.
소유자에 의한 공유로써 소유자가 변경되면 기존 매뉴얼 공유는 제거됩니다. 매뉴얼 공유는 공유 오브젝트에 기록됩니다.
스탠다드 오브젝트는 AccountShare와 같은 방식으로 오브젝트 명 뒤에 Share로 구분된 공유 오브젝트를 가지며 커스텀
오브젝트는 sObject__Share와 같은 방식으로 오브젝트 명 뒤에 __Share로 공유 오브젝트가 존재합니다.
매뉴얼 공유는 레코드 상세 화면 내 공유(Sharing) 버튼을 클릭하여 사용자에 의해 권한 수준 수정 및 제거가 가능합니다.
Lightning Experience에서 Manual Sharing은 5월 Idea Exchange에 우선순위에 선정되어 있습니다.
우선순위 투표 결과에 따라 Spring '21 이후 릴리스 계획의 일부로 우선 순위 탭에서 확인할 수 있습니다.
2020 년 8 월 후반에 릴리스 계획이 완료되면 개발 우선 순위가 가장 높은 아이디어가 발표됩니다.
Components
22. Teams
팀은 계정, 영업 기회 또는 사례에 대해 함께 작업하는 사용자 그룹입니다. 레코드 소유자는 자신이 소유 한
각 레코드마다 팀을 구성 할 수 있습니다. 레코드 소유자는 팀 구성원을 추가하고 각 팀 구성원이 레코드에 가지고있는 접근
권한을 설정합니다. 일부 팀 구성원은 읽기 전용 액세스 권한을 갖고 다른 팀 구성원은 읽기 / 쓰기 권한을 가질 수 있습니다.
소유자, 상위 계층 사용자 및 시스템 관리자 만 팀 구성원을 추가하고 구성원에게 더 많은 액세스 권한을 제공 할 수 있습니다.
읽기 / 쓰기 권한이 있는 팀 구성원은 팀과 연관된 레코드에 이미 액세스 권한이 있는 다른 구성원을 추가 할 수 있습니다. 팀원은
추가 액세스 권한을 제공 할 수 없습니다.
앱에서 팀 구성원을 만들면 팀 레코드와 관련 공유 레코드라는 두 가지 레코드가 생성됩니다. 프로그래밍 방식으로 팀 구성원을
만드는 경우 팀 레코드와 관련 공유 레코드를 모두 직접 관리 해야 합니다. 레코드 당 하나의 팀 (계정, 기회 또는 사례) 만
있습니다. 여러 팀이 필요한 경우 특정 요구에 따라 영역 관리 또는 프로그래밍 방식 공유를 고려하십시오.
팀 오브젝트는 관리 가능한 오브젝트가 아닙니다. 팀에 대한 사용자 정의 필드, 유효성 검사 규칙 또는 트리거를 만들 수
없습니다. 이러한 기능이 필요할 경우 커스텀 오브젝트와 프로그램 방식 공유를 사용하여 이 기능을 대체 할 수 있습니다.
Components
23. Territory Hierarchy
영역 계층(Territory Hierarchy)은 단일 차원의 추가 계층으로, 비즈니스 단위 또는 계층 구조에서 모든 종류의 추가 계층을 구성
할 수 있습니다. 영역 관리(Territory Management)가 활성화되면 역할 계층과 영역 계층을 모두 관리 해야 합니다.
영역은 계정, 기회 및 계정 및 기회의 마스터 / 세부 하위에만 존재합니다.
영역 계층 구조를 설정 할 시 계층이 10단계 이하의 분기로 유지 하는 것이 바람직합니다.
지역에 대한 할당 규칙이 변경되면 해당 지역을 조건으로 사용하는 공유 규칙이 다시 계산됩니다.
마찬가지로 지역의 구성원이 변경되면 해당 지역을 조건으로 사용하는 소유권 기반 공유 규칙이 다시 계산됩니다.
Components
24. Territory Management Use Cases
여러 그룹의 사람들 (여러 팀)이 계정에 대한 읽기 전용 또는 읽기 / 쓰기 액세스 권한이 필요한 경우(복수 관리 주체)
역할 계층과 다른 추가 계층 구조가 필요한 경우(보고 계층, 영업 계층)
단일 사용자는 계층 구조에서 여러 레벨을 보유 해야 하는 경우(겸직 등)
전 지역 계정의 모든 것을 볼 필요가 계정 관리 사용자가 있는 경우(사업 총괄 관리자)
Components
25. Account Territory Sharing Rules
계정 영역 공유 규칙은 조직에 원래 영역 관리 기능이 활성화 된 경우에만 사용할 수 있습니다.
이러한 공유 규칙을 통해 규칙에 정의 된 지역으로 지정된 계정 레코드에 액세스 할 수 있습니다.
Account Territory Sharing Rule Use Case
사용자 그룹에 소유권(Ownership)을 기반이 아닌 정의된 영역(Territory)에 속한 계정에 대한 추가 데이터 액세스를 제공합니다.
영역 관리가 활성화 된 경우 계정에만 적용됩니다.
Original territory managemen에서 사용 가능합니다.
Original territory management는 Summer'21에 비활성화 예정입니다.
Components
26. Programmatic Sharing
프로그래밍 방식 공유를 사용하면 다른 방법으로 데이터 접근/제한 요구 사항을 충족 할 수 없는 경우
코드 (Apex 또는 기타)를 사용하여 정교하고 동적인 공유 설정을 구성 할 수 있습니다.
프로그래밍 방식으로 공유 레코드를 생성하고 공유 사유(row cause)를 매뉴얼 공유(Manual Share)로 지정하여 사용하는 경우
레코드 상세페이지의 Share 버튼을 사용하여 이 공유내역을 관리 수 있습니다.
공유 사유가 매뉴얼 공유(Manual Share)인 공유 레코드는 소유권 변경 시 사용자가 수동으로 등록한 매뉴얼 공유와 동일하게
해당 레코드의 매뉴얼 공유 내역이 삭제됩니다.
Apex Sharing Reason을 사용하면 소유권 변경에 영향 받지 않습니다.
아래 문서에서 Apex Sharing에 대한 자세한 내용을 확인 할 수 있습니다.
https://developer.salesforce.com/page/Using_Apex_Managed_Sharing_to_Create_Custom_Record_Sharing_Logic
Components
27. Programmatic Sharing Use Cases
다른 선언적 공유 기능으로 데이터 접근 요구사항을 충족 할 수 없는 경우
사용자 접근제어를 할당하는 외부시스템과 세일즈포스를 연동하는 경우
기본 공유기능이 성능 저하를 유발하는 경우(High Volume Data)
커스텀 오브젝트에 팀 기능을 적용 해야 하는 경우
Components
28. Implicit Sharing
암시적 공유는 자동으로 적용됩니다. 기능을 끄거나 켤 수 없습니다. 하지만 시스템 관리자는 의도하지 않은 자동 공유를
회피하거나 자동 공유를 유도 하기 위해 암시적 공유를 이해하는 것이 중요합니다.
Parent – Account 하위 스탠다드 오브젝트에 접근 권한이 있는 경우 상위 Account에 대한 Read권한 부여
Child – Account의 접근 권한이 있는 경우 하위 오브젝트의 접근권한 부여
Portal – 포탈 사용자는 자신의 Account의 레코드 접근 권한 및 그 하위 포탈 사용자의 Contact 정보에 대한 읽기권한 부여
High Volume, High Volume Parent – Sharing Set에 속한 High Volume 라이선스 사용자가 소유한 레코드를 Sharing Set의
Access Group의 멤버에게 접근 권한 부여
자세한 내용은 이전 미팅 자료를 참고
https://www.youtube.com/watch?v=GDdwB6Icu4Q
Components
29. Role Hierarchy
• 가능한 단순하게 계층단계가 많지 않도록 구성
• 추가 계층이 필요한 경우 영영 계층(Territory Hierarchy)를 영업 계층으로 역할 계층은 보고 계층으로 구성
• 역할 계층과 영역 계층을 동일하지 않도록 구성(동일할 경우 역할 계층만 사용)
Teams
• 팀을 사용하는 것 보다 영역 계층 구조를 사용하는 것이 좋음
• 다른 공유 기능으로 요구사항을 충족 할 수 없는 경우에만 팀을 적용(공유 재계산시 많은 클라우드 리소스 사용)
Realignment and Reassignment
• 공유 기능 변경 또는 공유 재 할당 시 변경 대상 데이터 양과 변경의 양과 변경 완료에 필요한 작업의 수를 고려
• 계층 구조 변경은 많은 리소스 사용
Considerations
30. Large Data Volumes
• 대용량 데이터가 존재하는 경우 최초 적용 또는 공유 규칙 변경은 샌드박스에서 테스트 후 운영에 반영
• 팀 또는 영역 관리를 구현 한 경우 특히 성능에 주의 필요(성능이슈)
Defer Sharing Calculations
• 공유 재계산을 지연시킬 필요가 있는 경우 세일즈포스에 요청(주중 공유 재설정 주말 공유 재계산)
Data Skews/Ownership Skews
• 데이터 Relationship은 1:10,000 이하를 유지하는 것이 바람직
• 사용자가 오브젝트 당 소유 레코드 10,000건 이하 유지가 불가피 할 경우 사용자의 역할을 역할 계층 최상단에 할당
The Account Hierarchies Impact on Data Access
• 계정의 계층 구조는 공유와 연관 없음
• 예)고객 지주사 계정에 접근 권한이 있어도 하위 고객 계정의 접근권한은 별개
Considerations
31. A Guide To Sharing Architecture
• https://resources.docs.salesforce.com/226/latest/en-us/sfdc/pdf/sharing_architecture.pdf
User Licenses
• https://help.salesforce.com/articleView?id=users_understanding_license_types.htm
Sharing a Record Using Apex
• https://developer.salesforce.com/docs/atlas.en-
us.apexcode.meta/apexcode/apex_bulk_sharing_creating_with_apex.htm
Source
