Salesforce 공유 모델은 조직의 보안 응용 프로그램 데이터 액세스를 제공하는 기능에 필수 요소입니다. 따라서 현재 및 향후 데이터 액세스 요구 사항을 충족하기 위해 공유 모델을 올바르게 구성하는 것이 중요합니다. 이 문서에서는 데이터 접근성 구성 요소, 모델 공유 사용 사례, 실제 고객 공유 솔루션을 검토하고 몇 가지 문제 해결 지침을 제공합니다.

이 문서는 고급 시스템 관리자 및 아키텍처용입니다. 개념을 이해하려면 Salesforce 보안 및 공유 모델에 대한 작업 Knowledge 있어야 합니다. 이 가이드의 전제 조건은 다음과 같습니다.

• Salesforce 도움말: 공유 설정
• Trailhead 모듈: 데이터 보안
• 엔터프라이즈 규모의 레코드 액세스 설계
• Salesforce 솔루션 - 안전

이 가이드는 표준 및 사용자 정의 개체에 대한 레코드 수준 액세스를 제어하는 데 사용되는 주요 기능에 중점을 둡니다. 이 가이드에서 다루지 않는 주제에는 다음이 포함됩니다.

• 폴더 액세스
• 콘텐츠 액세스
• Chatter 액세스
• Knowledge Base 액세스
• 아이디어, 질문/ 답변 액세스
• 모바일 데이터 액세스 가능성

레코드 수준 보안을 사용하면 사용자에게 일부 개체 레코드에 대한 액세스 권한을 부여할 수 있지만 다른 레코드에는 액세스할 수 없습니다. 대부분의 응용 프로그램과 마찬가지로 데이터 액세스는 사용자로부터 시작됩니다. 응용 프로그램이 액세스를 제공하기 전에 사용자가 누구인지 알아야 합니다. Salesforce의 경우 여러 유형의 사용자가 있으며, 경우에 따라 액세스 수준이 유형에 따라 다릅니다. 모든 라이센스 유형의 모든 특성을 검토하는 대신 데이터 액세스에 크게 영향을 미치는 흥미로운 특성에 중점을 둡니다. 레코드 소유권 및 전체 액세스는 동의어이며 상호 교환 가능하며 사용자에게 레코드에 대한 가장 높은 수준의 액세스 권한을 제공합니다.

고용량 사용자

대량 사용자(고객 커뮤니티, 대량 고객 포털, 인증된 웹 사이트 라이센스 유형이 있는 사용자 포함)는 라이센스 유형이 역할을 지원하지 않으므로 공유 모델을 사용하지 않습니다. 해당 라이센스에는 사용자(라이센스 보유자)와 계정 및 연락처 조회 데이터 간 외부 키 일치로 작동하는 자체 공유 모델이 있습니다. 관리자는 공유 집합 또는 공유 그룹을 만들어 대량 사용자에게 레코드에 대한 액세스 권한을 부여할 수 있습니다.

Chatter Free 및 Chatter 외부 라이센스

Chatter Free 및 Chatter External 라이센스는 표준 공유 모델을 따르지 않습니다. 해당 라이센스는 CRM 레코드(표준 또는 사용자 정의 개체) 및 콘텐츠 기능에 액세스할 수 없으며 역할을 지원하지 않으므로 공유가 없습니다.

이 문서의 나머지 부분에서는 전체 공유 모델을 사용하는 Salesforce 사용자 유형을 가정합니다. 사용 가능한 각 라이센스 유형에 대한 자세한 내용은 사용자 라이센스를 참조하십시오.

프로필 및 권한 집합

프로필 및 권한 집합은 사용자에게 표시되는 데이터 유형과 레코드를 편집, 만들기 또는 삭제할 수 있는지 여부를 결정하여 개체 수준 보안을 제공합니다. 각 개체에 대해 "모두 보기" 및 "모두 수정" 권한은 공유 규칙 및 설정을 무시하므로 관리자가 조직 전체에서 지정된 개체와 연결된 레코드에 대한 액세스 권한을 빠르게 부여할 수 있습니다. 이러한 권한은 사용자가 모든 앱과 데이터를 보거나 수정할 수 있도록 허용하는 "모든 데이터 보기" 및 "모든 데이터 수정" 관리 권한 대신 선호되는 대안이기도 합니다.

프로필 및 권한 집합은 사용자가 액세스할 수 있는 모든 개체 내의 필드를 결정하는 필드 수준 보안도 제어합니다. 예를 들어, 개체에 20개의 필드가 있을 수 있지만, 사용자에게 20개의 필드 중 5개가 표시되지 않도록 필드 수준 보안을 설정할 수 있습니다.

프로필 대신 권한 집합 및 권한 집합 그룹을 사용하여 사용자의 개체 권한을 관리하는 것이 좋습니다. 소규모 권한 집합 빌딩 블록을 재사용할 수 있으므로 각 사용자 및 직무에 대해 수십 개 또는 수백 개의 프로필을 생성하지 않아도 됩니다.

레코드 소유권 및 대기열

모든 레코드는 단일 사용자 또는 대기열에서 소유해야 합니다. 소유자는 소유자의 프로필에 대한 개체 설정을 기반으로 레코드에 액세스할 수 있습니다. 예를 들어 소유자의 프로필에 개체에 대한 만들기 및 읽기 권한이 있지만 편집 또는 삭제 권한이 없는 경우 소유자는 개체에 대한 레코드를 만들고 새 레코드를 볼 수 있습니다. 그러나 소유자는 레코드를 편집하거나 삭제할 수 없습니다. 계층(역할 또는 영역)의 상위 사용자는 표준 개체의 하위 역할과 동일한 데이터 액세스를 승계합니다. 하위 역할에 읽기 전용 액세스 권한이 있는 경우 역할 계층에서 상위 사용자도 마찬가지입니다. 이 액세스는 사용자가 소유한 레코드 및 사용자와 공유한 레코드에 적용됩니다.

대기열을 사용하면 작업 부하를 공유하는 팀에 레코드의 우선 순위를 지정하고 배포하고 할당할 수 있습니다. 역할 계층의 상위 대기열 구성원 및 사용자는 목록 보기에서 대기열에 액세스하고 대기열의 레코드 소유권을 가져올 수 있습니다.

단일 사용자가 10,000개가 넘는 레코드를 소유한 경우 모범 사례:

• 소유자의 사용자 레코드는 역할 계층에서 역할을 유지하지 않아야 합니다.

• 소유자의 사용자 레코드에 역할이 포함되어야 하는 경우 역할 계층의 상단에 역할을 배치합니다.

자세한 내용은 Salesforce Well-Architected - Reliable을 참조하십시오.

조직 전체 기본값

조직 전체 공유 설정은 사용자가 서로의 레코드에 대해 보유한 기본 액세스 수준을 지정합니다. 조직 전체 공유 설정을 사용하여 데이터를 가장 제한적인 수준으로 잠그십시오. 다른 레코드 수준 보안 및 공유 도구를 사용하여 다른 사용자에게 선택적으로 액세스 권한을 부여합니다. 예를 들어 사용자에게 기회를 읽고 편집할 수 있는 개체 수준 권한이 있고 조직 전체 공유 설정은 읽기 전용입니다. 기본적으로 이러한 사용자는 레코드를 소유하거나 다른 권한이 부여되지 않는 한 모든 기회 레코드를 읽을 수 있지만 편집할 수 없습니다.

조직 전체 기본 설정을 한 설정에서 다른 설정으로 변경할 수 있습니다(비공개에서 상위에 제어됨으로 변경한 후 다시 비공개로 변경). 그러나 이러한 변경 사항은 공유 재계산이 필요하며 볼륨에 따라 처리 시간이 길어질 수 있습니다.

사용자 정의 개체의 경우에만 계층을 사용하여 액세스 부여 설정을 구성할 수 있습니다. 선택 취소된 경우(기본값 선택) 역할 계층의 상위 사용자가 액세스를 상속할 수 없습니다. 이 설정은 조직 전체 기본 설정에서 확인할 수 있습니다.

역할 계층

역할 계층은 사용자 또는 사용자 그룹에 필요한 데이터 액세스 수준을 나타냅니다. 역할 계층을 통해 관리자는 조직 전체 기본 설정에 관계없이 항상 직원과 동일한 데이터에 액세스할 수 있습니다. 역할 계층은 조직 차트와 정확하게 일치하지 않아도 됩니다. 대신 계층의 각 역할은 사용자 또는 사용자 그룹에 필요한 데이터 액세스 수준을 나타내야 합니다.

Spring '21 이후에 생성된 Salesforce 조직에서는 최대 5,000개의 역할을 만들 수 있습니다. Spring '21 이전에 생성된 조직에서는 최대 500개의 역할을 만들 수 있으며 Salesforce 고객 지원에 문의하여 이 제한을 늘릴 수 있습니다. 가장 좋은 방법은 내부 역할의 수를 25,000개로 유지하고 외부 역할의 수를 100,000개로 유지하는 것입니다.

가장 좋은 방법은 역할 계층을 계층의 10개 이상의 분기 수준으로 유지하는 것입니다.

사용자의 역할이 변경되면 필요한 경우 관련 공유 규칙이 평가되어 액세스를 수정합니다. 동일한 역할 내 동료는 서로의 데이터에 대한 액세스를 보장하지 않습니다.

역할 계층 모델링은 조직의 구조화 방식을 이해하는 것으로 시작합니다. 이는 일반적으로 상단에서부터 관리자의 범위를 이해하여 구축됩니다. CEO는 전체 회사를 감독합니다. CEO는 일반적으로 다이렉트 보고서를 보유하며 사업부(판매 또는 지원) 또는 지리적 지역(EMEA, APAC)별로 세분화할 수 있습니다. 그러면 해당 개인에게 추가 세분화할 수 있는 다이렉트 보고서가 있습니다. 이는 HR 조직 차트와 매우 유사하지만 데이터 액세스를 모델링할 때 HR 보고에 대한 고려 사항을 사용하여 데이터 액세스 가능성에 초점을 맞춥니다.

오버레이는 항상 계층의 어려운 부분입니다. 자체 지점에 있는 경우 필요한 액세스 권한을 얻으려면 공유 규칙, 팀 또는 영역 관리가 필요합니다. 계층에 폴드되는 경우 보고에 영향을 미칠 수 있습니다.

공유 모델의 기본적인 측면 중 하나이므로 역할 계층을 설정하는 데 시간을 할애하는 것이 중요합니다.

공개 그룹

공개 그룹은 모두 공통 기능이 있는 개별 사용자, 역할, 영역의 모음입니다. 공개 그룹은 다음으로 구성할 수 있습니다.

• 사용자
• 고객 포털 사용자
• 파트너 사용자
• 역할
• 역할 및 내부 하위 역할
• 역할, 내부, 포털 하위 역할
• 포털 역할
• 포털 역할 및 하위 역할
• 영역
• 영역 및 하위 영역
• 기타 공개 그룹(중첩)

그룹을 중첩할 수 있습니다(그룹 A가 그룹 B에 중첩됨), 그러나 5개 이상의 수준을 중첩하지 마십시오. 중첩은 그룹 구성원 계산으로 인해 그룹 서비스 점검 및 성능에 영향을 미칩니다. 가장 좋은 방법은 조직의 총 공개 그룹 수를 100,000개로 유지하는 것입니다.

소유자 기반 공유 규칙

소유자 기반 공유 규칙은 소유하지 않는 레코드에 대한 추가 사용자 액세스 권한을 부여하는 조직 전체 기본 설정 및 역할 계층에 대한 예외를 허용합니다. 소유자 기반 공유 규칙은 레코드 소유자만 기반으로 합니다.

연락처 소유자 기반 공유 규칙은 비공개 연락처 또는 계정과 연결되지 않은 연락처에 적용되지 않습니다.

개체당 총 공유 규칙은 300개로 제한됩니다.

기준 기반 공유 규칙

기준 기반 공유 규칙은 레코드의 필드 값(기준)을 기반으로 레코드에 대한 액세스 권한을 제공합니다. 기준을 충족하는 경우(하나 이상의 필드 값) 규칙에 대한 공유 레코드가 생성됩니다. 레코드 소유권은 고려 사항이 아닙니다.

개체당 기준 기반 및 게스트 사용자 공유 규칙의 제한은 50입니다.

게스트 사용자 공유 규칙

게스트 사용자 공유 규칙은 인증되지 않은 게스트 사용자에게 레코드 액세스 권한을 부여하는 데 사용되는 특수 유형의 기준 기반 공유 규칙입니다. 개체당 기준 기반 및 게스트 사용자 공유 규칙의 제한은 50입니다.

경고: 게스트 사용자 공유 규칙 유형은 로그인 자격 증명이 없는 게스트 사용자에게 액세스 권한을 부여합니다. 게스트 사용자 공유 규칙을 만들면 누구나 공유 규칙의 기준과 일치하는 모든 레코드에 즉시 무제한으로 액세스할 수 있습니다. Salesforce 데이터를 보호하고 게스트 사용자에게 필요한 사항에 대한 액세스 권한을 부여하려면 이 유형의 공유 규칙을 만드는 데 미치는 모든 사용 사례와 영향을 고려하십시오. 데이터 민감도에 적합하다고 생각하는 보안 관리를 구현합니다. Salesforce는 기본 설정에서 이 변경 사항을 기반으로 인증되지 않은 사용자에게 데이터가 노출되는 경우에는 어떠한 책임도 지지 않습니다.

수동 공유

특정 레코드 집합에 액세스해야 하는 일관된 사용자 그룹을 정의할 수 없는 경우가 있습니다. 레코드 소유자 또는 시스템 관리자와 같은 적절한 권한이 있는 다른 사용자는 수동 공유를 사용하여 기타 액세스 권한이 없는 사용자에게 읽기 및 편집 권한을 부여할 수 있습니다. 수동 공유는 조직 전체 공유 설정, 역할 계층 또는 공유 규칙과 마찬가지로 자동화되지 않습니다. 그러나 레코드 소유자는 레코드를 확인해야 하는 사용자와 레코드를 유연하게 공유할 수 있습니다.

레코드 소유자가 변경되거나 부여된 공유 액세스가 개체의 조직 전체 공유 기본 액세스 수준 이상의 추가 액세스 권한을 부여하지 않는 경우 수동 공유가 제거됩니다. 이는 프로그래밍 방식으로 생성된 수동 공유에도 적용됩니다.

수동 공유 레코드는 수동 공유로 설정된 행 원인과 함께 공유 레코드로 정의됩니다.

수동 공유로 설정된 행 원인이 있는 모든 공유 레코드(표준 및 사용자 정의 개체)는 공유 레코드가 프로그래밍 방식으로 생성된 경우에도 개체의 페이지 레이아웃에서 공유 버튼을 통해 편집하고 삭제할 수 있습니다.

팀

팀은 계정, 세일즈 기회 또는 사례에 대해 함께 작업하는 사용자 그룹입니다. 레코드 소유자는 소유한 각 레코드에 대한 팀을 구축할 수 있습니다. 레코드 소유자가 팀 구성원을 추가하고 각 팀 구성원이 레코드에 대해 보유한 액세스 수준을 지정합니다. 일부 팀 구성원은 읽기 전용 액세스 권한을 보유하고, 다른 팀 구성원은 읽기/쓰기 권한을 보유합니다.

소유자, 계층의 상위 사용자, 관리자만 팀 구성원을 추가하고 구성원에게 더 많은 액세스 권한을 제공할 수 있습니다. 읽기/쓰기 액세스 권한이 있는 팀 구성원은 팀이 연결된 레코드에 이미 액세스 권한이 있는 다른 구성원을 추가할 수 있습니다. 팀 구성원은 추가 액세스 권한을 제공할 수 없습니다.

앱에서 팀 구성원을 만들면 팀 레코드와 관련 공유 레코드의 두 가지 레코드가 생성됩니다. 팀 구성원을 프로그래밍 방식으로 만드는 경우 팀 레코드와 관련 공유 레코드를 모두 관리해야 합니다. 레코드당 팀(계정, 기회 또는 사례)은 한 개만 있습니다. 여러 팀이 필요한 경우 특정 요구에 따라 영역 관리 또는 프로그램 방식 공유를 고려하십시오.

영역 계층

엔터프라이즈 영역 관리를 사용할 경우 모델의 영역 구조를 표시하고 기본 상호 작용 지점으로 사용하는 영역 계층을 설정합니다. 엔터프라이즈 영역 관리가 활성화되어 있는 경우 역할 계층과 영역 계층을 모두 관리해야 합니다. 자세한 내용은 Salesforce 도움말의 엔터프라이즈 영역 관리를 참조하십시오.

Apex 관리되는 공유

Apex 관리되는 공유(프로그래밍 공유라고도 함)를 사용하면 데이터 액세스 요구 사항을 다른 방법으로 충족할 수 없는 경우 코드를 사용하여 정교하고 동적 공유 설정을 구축할 수 있습니다.

공유 레코드를 프로그래밍 방식으로 생성하고 부재 행 원인(수동 공유)을 사용하는 경우 앱에서 공유 버튼을 사용하여 이 공유 레코드를 유지할 수 있습니다. 공유 레코드에는 소유자 이전 시 삭제와 같은 수동 공유 행 원인이 있는 모든 규칙이 적용됩니다.

또한 사용자 정의 개체에 대한 자체 Apex 공유 이유를 만들어 사용자 또는 사용자 그룹의 레코드를 추적하고 공유 레코드의 업데이트 및 삭제에 필요한 코딩을 간소화할 수 있습니다.

자세한 내용은 프로그래밍 방식의 공유를 고려하기 전에 Apex를 사용하여 레코드 공유를 참조하십시오.

제한 규칙

데이터 액세스 구성에서 사용자에게 중요한 데이터가 포함될 수 있거나 작업에 필요하지 않은 레코드가 표시되지 않도록 할 수 있습니다. 제한 규칙을 사용하여 사용자가 지정한 기준을 충족하는 레코드에만 액세스할 수 있도록 허용할 수 있습니다. 사용자에게 제한 규칙이 적용되면 사용자에게 조직 전체 기본값, 공유 규칙 및 기타 공유 메커니즘을 통해 액세스 권한이 부여된 레코드가 사용자가 지정한 기준에 따라 필터링됩니다. 제한 규칙은 이 주제에서 논의된 공유 구성 요소와 반대 방식으로 작동합니다. 사용자에게 액세스를 여는 대신 추가로 제한합니다.

제한 규칙은 사용자 정의 개체, 외부 개체, 계약, 이벤트, 과업, 시간 시트 및 시간 시트 항목에 사용할 수 있습니다. Enterprise 및 Developer Edition에서 개체당 최대 두 개의 활성 제한 규칙을 만들고 Performance 및 Unlimited Edition에서 개체당 최대 5개의 활성 제한 규칙을 만들 수 있습니다. 제한 규칙은 다음 Salesforce 기능에 적용됩니다.

• 목록 보기
• 조회
• 관련 목록
• 보고서
• 검색
• SOQL
• SOSL

묵시적 공유

암시적 공유는 자동입니다. 응용 프로그램에 기본적으로 적용되므로 비활성화 또는 켜기할 수 없습니다. 다시 말해 암시적 공유는 구성 가능한 설정이 아니지만, 모든 설계자가 이해하는 것이 중요합니다. 상위 암시적 공유는 사용자에게 해당 계정의 하위 기회, 사례 또는 연락처에 대한 액세스 권한이 있는 경우 상위 레코드(계정만 해당)에 대한 액세스 권한을 제공합니다. Salesforce에는 사용자가 연락처(또는 기회, 사례 또는 주문)를 볼 수 있는 경우 사용자에게 연결된 계정이 암시적으로 표시되는 데이터 액세스 정책이 있습니다. 하위 암시적 공유는 계정 소유자에게 계정의 하위 레코드에 대한 액세스 권한을 제공합니다. 이 액세스는 역할 계층에서 소유자의 역할에 정의됩니다. 하위 암시적 공유는 연락처, 기회, 사례 개체(계정의 하위 개체)에만 적용됩니다. 역할이 생성될 때 각 하위 개체에 대해 제공할 수 있는 액세스 수준은 보기, 편집, 액세스 없음입니다. 보기로 설정하면 계정 소유자가 연결된 개체 레코드(연락처, 기회 또는 사례)를 암시적으로 볼 수 있습니다. 편집으로 설정하면 계정 소유자가 연결된 개체(연락처, 기회 또는 사례)를 암시적으로 수정할 수 있습니다.

암시적 공유는 사용자 정의 개체에 적용되지 않습니다.

모든 Salesforce 조직에 맞는 공유 모델이 없습니다. 모든 조직은 최상의 공유 모델을 설계하려는 경우 각기 다른 요구 사항 및 과제가 있습니다. 가장 적절한 데이터 액세스 구성 요소를 사용하여 조직의 공유 요구 사항을 충족하는 것이 중요합니다. 다음 시나리오는 공유 모델을 구성하려는 경우 일반적인 문제입니다.

• 역할 계층에 어떤 일이 발생합니까?

  • 영역 계층을 사용하는 경우 역할 계층에도 문제가 발생하지 않습니다. 그러나 영역 기반 예측과 역할 기반 예측을 함께 사용하는 경우 두 개의 계층을 관리해야 합니다. 이 경우 역할 계층을 사용하여 HR 보고 구조를 모델링한 다음, 영역 계층을 사용하여 실제 판매 계층을 모델링하는 것이 좋습니다. 영역 계층은 여러 관리자에게 보고할 수 있는 매트릭스 보고 구조를 모델링하는 데 가장 적합합니다.

    영역 기반 예측 및 역할 기반 예측을 함께 사용하지 않는 경우 영역 계층만 판매 계층으로 사용할 수 있습니다. 이 시나리오에서는 가능한 한 계층을 간소화하거나 평면화하는 것이 가장 좋습니다.

    불필요한 공유 활동을 유발하므로 역할 계층과 영역 계층을 동일하게 만들지 않는 것이 좋습니다.

• 팀을 계속 사용할 수 있습니까?

  • 예. 그러나 영역 계층 내의 액세스 요구 사항을 충족할 수 있는 경우(오버레이 등) 팀을 사용하는 것보다 오버레이를 사용하는 것이 좋습니다. 이미 여러 계층(역할 및 영역)을 유지하고 있으므로 가능한 한 간단하게 유지하려는 경우 다른 기존 공유 구성 요소가 요구 사항을 충족하지 않는 경우에만 팀을 구현하십시오.

• 재정렬 및 재할당

  • 역할, 팀 또는 영역의 멤버십 및 계층 구조와 같은 두 가지 유형의 변경 사항이 발생합니다. 멤버십 변경은 일반적으로 매일, 심지어 매시간 발생할 수 있습니다. 계층 구조(재정렬) 변경은 일반적으로 자주 발생하지 않으며(분기별, 반년별 또는 연간) 자원이 많이 소모될 수 있습니다. 고려해야 할 사항은 변경량 및 각 변경 사항이 유발하는 계단식 변경 수입니다. 반드시 분기별로 구조적 변경 사항이 발생하지 않도록 하며 모든 대용량 변경 사항(대량 또는 대량 변경 사항)이 제대로 계획, 테스트, 조정되어야 합니다.

• 대용량 데이터

  • 초기 롤아웃을 위해 모델링하거나 재정렬 변경을 계획하는지 여부와 상관없이 데이터 용량을 심각하게 고려해야 합니다. 성능이 요소가 될 수 있는 임계값이 있으므로 프로덕션 전에 Sandbox에서 변경 사항을 테스트하는 것이 좋습니다. 이 테스트는 변경에 소요되는 시간에 대한 기준도 제공합니다.

    200만 개가 넘는 계정이 있고 팀 또는 엔터프라이즈 영역 관리를 구현한 경우 성능에 특히 주의를 기울여야 합니다. 이는 대량의 공유 레코드를 만들 수 있으므로 트랜잭션을 오랫동안 실행할 수 있는 복잡한 공유 모델 구성 요소입니다.

• 공유 계산 지연

  • 공유를 활용하는 개체가 있고 대량 레코드(예: 2백만 개가 넘는 계정)가 있고 대량 변경을 수행해야 하는 경우(예: 계층을 변경해야 하는 분기별 재정렬) Salesforce 고객 지원에서 자동 공유 계산을 지연하는 데 사용할 수 있는 기능이 있습니다. 기본적으로 역할 계층, 영역 계층, 그룹, 공유 규칙, 사용자 역할, 팀 멤버십 또는 레코드 소유권에 대한 모든 개별 변경 사항이 자동 공유 계산을 시작할 수 있습니다. 대량 변경 사항이 적용되면 여러 자동 공유 재계산이 시작됩니다. 이러한 재계산을 일시적으로 일시적으로 일시 중지하면 변경 사항을 적용한 다음, 공유 계산을 한 번에 모두 수행할 수 있습니다. 이 방법은 일반적으로 더 효율적이며 대량 변경에 더 잘 작동합니다.

• 데이터 및 소유권 스키우

  • 데이터 왜곡은 하위 레코드가 많은 몇 가지 상위 레코드로 정의됩니다. 이러한 왜곡은 몇몇 계정에 연락처, 기회 또는 사례가 많은 경우에 유해할 수 있습니다. 성능 저하가 시작되는 비율은 1:10,000입니다. 최대한 비슷한 비율을 유지하는 것이 가장 좋습니다(더 낮음이 좋습니다).

    소유권 왜곡은 개체에 대한 많은 레코드를 소유한 단일 사용자, 역할 또는 그룹을 참조하는 경우를 제외하고 데이터 왜곡과 유사합니다. 데이터 왜곡과 마찬가지로 오래 실행되는 트랜잭션을 유발하여 변경 사항이 발생하면 성능이 저하될 수 있습니다. 권장 소유자와 레코드 수의 비율도 1:10,000입니다.

    단일 사용자가 10,000개가 넘는 레코드를 소유한 경우 모범 사례:

    • 소유자의 사용자 레코드는 역할 계층에서 역할을 유지하지 않아야 합니다.

    • 소유자의 사용자 레코드에 역할이 포함되어야 하는 경우 역할 계층의 상단에 역할을 배치합니다.

• 계정 계층이 데이터 액세스에 미치는 영향

  • 많은 사람들이 계정 계층을 구현할 때 나쁜 가정을 내립니다. 상위 계정에 액세스할 수 있는 사용자가 하위 계정에도 액세스할 수 있다고 가정합니다. 두 레코드 간에 상위/하위 관계만 있다는 간단한 사실은 액세스를 유도하지 않습니다. 역할 계층 및 영역 계층은 이 방식으로 작동하지만 계정 계층은 그렇지 않습니다.

공유 모델 아키텍처를 완료하면 사용자가 레코드를 볼 수 있거나 볼 수 없는 이유에 대한 문제를 겪을 수 있습니다. 일반적으로 레코드에 액세스할 수 있는 모든 사용자와 그 이유를 확인할 수 있는 방법이 필요할 경우 사용자에게 표시되지 않는 내용을 볼 수 없습니다.

더욱 어려운 문제이며, 더 일반적인 문제는 사용자가 레코드를 볼 수 없는 이유입니다. 구축한 보안 계층에 따라 시작 위치가 결정됩니다. 공유 모델을 잘 알고 있다면 액세스 권한을 제공해야 하며 시작할 수 있는 구성 요소를 알고 있을 수 있습니다. 그러나 공유 모델에 익숙하지 않은 경우 역할 계층에서 시작하고 각 레이어를 다시 뽑아 액세스 권한을 제공해야 하는 레이어를 결정합니다. 다음은 문제 해결 플로입니다.

1. 사용자에게 개체에 액세스할 수 있는 권한이 있는지 확인합니다.
2. 레코드를 볼 수 없는 사용자의 역할을 식별하고 기록합니다.
3. 레코드의 역할 소유자를 식별하고 기록합니다.
4. 역할 계층을 검토하고 두 역할이 서로 다른 두 가지 지점에 있는지 확인합니다.
5. 이제 개체에 대한 공유 규칙을 검토하고 사용자에게 액세스 권한을 부여하는 규칙이 없는지 확인해야 합니다. 필요한 경우 공개 그룹도 살펴봅니다. 사용자가 공유 규칙이 있는 그룹에서 제외되었거나 사용자에게 액세스 권한을 부여하기 위해 새 공유 규칙을 만들어야 하는 것이 좋습니까? 이 선택 항목은 유지 관리하려는 아키텍처에 따라 다르며 소유자 기반 공유 규칙과 기준 기반 공유 규칙 모두에 적용됩니다.
6. 팀을 사용하는 경우 이 사용자가 해당 레코드의 팀에 있어야 합니까? 팀을 유지 관리하는 방법 및 누락 발생 방법
7. 수동 공유를 사용하는 경우 레코드 소유자가 변경되어 사용자가 액세스하지 못할 수 있습니다. 소유권이 변경되면 수동 공유가 삭제됩니다. 수동 공유는 공유 버튼을 사용하여 제거할 수도 있습니다.
8. 엔터프라이즈 영역 관리를 사용하는 경우 영역 중 하나에서 사용자가 누락되었습니까? 영역 멤버십이 유지되는 위치 및 누락 발생 방법 또는 레코드가 사용자가 구성원인 영역에 할당되지 않았을 수도 있습니다.
9. 프로그램 공유를 만들고 코드에서 공유를 만드는 기준이 있는 경우 코드를 검토하여 이 사용자가 생략된 이유를 이해합니다.