Salesforce 共有モデルは、組織がアプリケーションデータに安全にアクセスできるようにするうえで不可欠な要素です。そのため、現在および将来のデータアクセス要件を満たすために、共有モデルを正しく設計することが重要です。このドキュメントでは、データアクセシビリティコンポーネント、共有モデルの使用事例、および実際の顧客共有ソリューションを確認し、トラブルシューティングガイドラインを示します。

このドキュメントは、高度なシステム管理者とアーキテクトを対象としています。概念を理解するには、Salesforce のセキュリティおよび共有モデルに関する実務 Knowledge が必要です。このガイドの前提条件は次のとおりです。

• Salesforce ヘルプ:共有設定
• Trailhead モジュール:データセキュリティ
• 企業の規模に応じたレコードアクセス権の作成
• Salesforce の適切なアーキテクチャ - セキュリティ

このガイドでは、標準オブジェクトとカスタムオブジェクトへのレコードレベルのアクセスを制御するために使用される主な機能に焦点を当てています。このガイドで扱っていないトピックは次のとおりです。

• フォルダーアクセス権
• コンテンツアクセス
• Chatter アクセス
• Knowledge ベースのアクセス権
• アイデア、質問/回答へのアクセス権
• モバイルデータアクセス

レコードレベルセキュリティでは、一部のオブジェクトレコードへのアクセス権をユーザーに付与できますが、他のオブジェクトレコードへのアクセス権をユーザーに付与することはできません。ほとんどのアプリケーションと同様に、データアクセスはユーザーから始まります。アプリケーションは、アクセス権を付与する前にユーザーが誰であるかを把握する必要があります。Salesforce では、ユーザーの種別は異なり、種別によってアクセスレベルが異なることがあります。ここでは、すべてのライセンス種別のすべての属性を確認するのではなく、データアクセスに大きな影響を与える興味深い属性に焦点を当てます。レコードの所有権とフルアクセス権は同義であり、交換可能で、ユーザーにレコードへの最高レベルのアクセス権を付与します。

大規模ユーザー

大規模ユーザー (カスタマーコミュニティ、大規模カスタマーポータル、認証 Web サイトライセンス種別を持つユーザーを含む) は、ライセンス種別でロールがサポートされないため、共有モデルを使用しません。これらのライセンスには、ユーザー (ライセンスを保持) と取引先および取引先責任者のルックアップのデータ間の外部キーの一致によって機能する独自の共有モデルがあります。システム管理者は、共有セットまたは共有グループを作成して、大規模ユーザーにレコードへのアクセス権を付与できます。

Chatter Free および Chatter External ライセンス

Chatter Free および Chatter External ライセンスは、標準共有モデルに従っていません。これらのライセンスには、CRM レコード (標準またはカスタムオブジェクト) およびコンテンツ機能へのアクセス権がなく、ロールもサポートしていません。そのため、共有はありません。

このドキュメントの残りでは、完全な共有モデルを使用する Salesforce ユーザー種別を想定しています。使用可能な各ライセンスの種類についての詳細は、「ユーザーライセンス」を参照してください。

プロファイルおよび権限セット

プロファイルと権限セットは、ユーザーに表示されるデータ型と、ユーザーがレコードを編集、作成、削除できるかどうかを決定することで、オブジェクトレベルセキュリティを提供します。各オブジェクトに対する「すべて表示」および「すべて変更」権限では共有ルールと設定が無視されるため、管理者は組織全体で特定のオブジェクトに関連付けられたレコードへのアクセス権をすばやく付与できます。多くの場合、これらの権限は、「すべてのデータの参照」および「すべてのデータの編集」管理者権限に代わるものとして適しています。これらの権限により、ユーザーはすべてのアプリケーションとデータを表示または変更できます。

プロファイルと権限セットは、ユーザーがアクセスできるすべてのオブジェクト内の項目を決定する項目レベルセキュリティも制御します。たとえば、オブジェクトには 20 個の項目を含めることができますが、20 個の項目のうち 5 個がユーザーに表示されないように項目レベルセキュリティを設定できます。

ユーザーのオブジェクト権限を管理するには、プロファイルの代わりに権限セットおよび権限セットグループを使用することを強くお勧めします。小さな権限セットのビルディングブロックを再利用できるため、ユーザーや職務ごとに数十から数百のプロファイルを作成する手間を省けます。

レコード所有権とキュー

すべてのレコードは、1 人のユーザーまたはキューが所有する必要があります。所有者は、所有者のプロファイルの [オブジェクト設定] に基づいてレコードにアクセスできます。たとえば、所有者のプロファイルにオブジェクトに対する「作成」および「参照」権限があり、「編集」または「削除」権限がない場合、所有者はオブジェクトのレコードを作成して新しいレコードを表示できます。ただし、所有者はレコードを編集または削除できません。階層の上位のユーザー (ロールまたはテリトリー) は、標準オブジェクトの下位ユーザーと同じデータアクセス権を継承します。下位ロールに参照のみアクセス権がある場合、ロール階層で上位のユーザーにもアクセス権が付与されます。このアクセス権は、ユーザーが所有するレコードと、ユーザーと共有されているレコードに適用されます。

キューは、レコードに優先度を付けたり、レコードを配布したり、ワークロードを共有するチームにレコードを割り当てたりするのに役立ちます。キューメンバーとロール階層の上位のユーザーは、リストビューからキューにアクセスし、キュー内のレコードの所有権を取得できます。

1 人のユーザーが 10,000 件を超えるレコードを所有している場合、ベストプラクティスとして次の点に留意してください。

• 所有者のユーザーレコードには、ロール階層内のロールを含めることはできません。

• 所有者のユーザーレコードでロールを保持する必要がある場合は、ロール階層の独自のブランチでロールを階層の最上位に配置します。

詳細は、「Salesforce Well-Architected - Reliable (Salesforce の適切なアーキテクチャ - 信頼性)」を参照してください。

組織の共有設定

組織の共有設定では、ユーザーが互いのレコードに対して持つデフォルトのアクセスレベルを指定します。組織の共有設定を使用して、データを最も制限の厳しいレベルにロックします。他のレコードレベルのセキュリティや共有ツールを使用して、他のユーザーに選択的にアクセス権を付与します。たとえば、商談を参照および編集するオブジェクトレベルの権限をユーザーに許可し、組織全体の共有設定は参照のみであるとします。デフォルトでは、これらのユーザーはすべての商談レコードを参照できますが、レコードを所有するか他の権限が付与されていない限り、編集することはできません。

組織の共有設定は、ある設定から別の設定に変更できます ([非公開] から [親によって制御]、[非公開] に戻る)。ただし、これらの変更には共有の再適用が必要であり、量によっては処理時間が長くなる可能性があります。

カスタムオブジェクトの場合のみ、[階層を使用したアクセス権の付与] 設定を定義できます。このチェックボックスがオフの場合 (デフォルトはオン)、ロール階層の上位のユーザーはアクセス権を継承しません。この設定は、組織の共有設定にあります。

ロール階層

ロール階層は、ユーザーまたはユーザーグループが必要とするデータアクセスのレベルを表します。ロール階層により、組織の共有設定に関係なく、マネージャーは常に従業員と同じデータにアクセスできます。ロール階層は組織図と完全に一致する必要はありません。代わりに、階層内の各ロールは、ユーザーまたはユーザーグループが必要とするデータアクセスレベルを表します。

Spring '21 以降に作成された Salesforce 組織では、最大 5,000 個のロールを作成できます。Spring '21 より前に作成された組織では、最大 500 個のロールを作成できます。この制限を増やすには、Salesforce カスタマーサポートにお問い合わせください。ベストプラクティスとして、内部ロール数は 25,000、外部ロール数は 100,000 にしてください。

ベストプラクティスとして、ロール階層は階層内のブランチのレベルを 10 以下に抑えることをお勧めします。

ユーザーのロールが変更されると、関連する共有ルールが評価され、必要に応じてアクセス権が修正されます。同じロール内のピアは、互いのデータへのアクセスを保証しません。

ロール階層のモデル化は、まず組織の構造を理解することから始まります。通常、これはマネージャーの範囲を把握することから構築され、上から開始されます。CEO は会社全体を監督します。通常、CEO の直属部下は、ビジネスユニット (セールスまたはサポート) または地域 (EMEA、APAC) でセグメント化できます。そのユーザーは、さらにセグメント化できる直属部下になります。これは HR 組織図によく似ていま���が、データアクセスをモデル化するときは、HR レポートを考慮してデータアクセスに焦点を絞ります。

オーバーレイは常に階層の難しい部分です。独自のブランチにいる場合、必要なアクセス権を取得するには、共有ルール、チーム、またはテリトリー管理のいずれかが必要です。階層に折りたたまれている場合、レポートに影響する可能性があります。

ロール階層は共有モデルの基本的な側面の 1 つであるため、時間をかけてロール階層を設定することが重要です。

公開グループ

公開グループは、共通の機能を持つ個々のユーザー、ロール、テリトリーなどのコレクションです。公開グループは、次の要素で構成されます。

• ユーザー
• カスタマーポータルユーザー
• パートナーユーザー
• ロール
• ロール & 内部下位ロール
• ロール、内部 & ポータル下位ロール
• ポータルロール
• ポータルロール & 下位ロール
• テリトリー
• テリトリーおよび下位テリトリー
• その他の公開グループ (ネスト)

グループはネストできますが (グループ A はグループ B にネスト)、ネストするレベルは 5 レベルまでに制限されます。ネストは、グループメンバーシップの計算により、グループのメンテナンスとパフォーマンスに影響します。組織の公開グループの総数を 100,000 に抑えることをお勧めします。

所有者ベースの共有ルール

所有者に基づく共有ルールでは、所有していないレコードへのアクセス権を他のユーザーに付与する組織の共有設定とロール階層の例外が許可されます。所有者に基づく共有ルールは、レコード所有者のみに基づきます。

取引先責任者所有者に基づく共有ルールは、非公開の取引先責任者、または取引先に関連付けられていない取引先責任者には適用されません。

オブジェクトあたりの共有ルールの合計数の制限は 300 です。

条件に基づく共有ルール

条件に基づく共有ルールでは、レコードの項目値 (条件) に基づいてレコードにアクセスできます。条件が満たされると (1 つ以上の項目値)、ルールの共有レコードが作成されます。レコードの所有権は考慮されません。

オブジェクトあたりの条件に基づく共有ルールとゲストユーザー共有ルールの制限は 50 です。

ゲストユーザー共有ルール

ゲストユーザー共有ルールは、認証されていないゲストユーザーにレコードアクセス権を付与するために使用される特殊な条件に基づく共有ルールです。オブジェクトあたりの条件に基づく共有ルールとゲストユーザー共有ルールの制限は 50 です。

**警告:**ゲストユーザー共有ルールタイプは、ログイン情報のないゲストユーザーにアクセス権を付与するものです。ゲストユーザー共有ルールを作成すれば、共有ルールの条件に一致するすべてのレコードに、誰もが無制限にすぐさまアクセスできるようになります。Salesforce データを保護し、ゲストユーザーが必要な情報にアクセスできるようにするために、このタイプの共有ルールの作成に関するすべての使用事例と影響を検討してください。データの機密性に適したセキュリティコントロールを実装します。デフォルト設定からのこの変更により、認証されていないユーザーにデータが漏洩した場合でも Salesforce は責任を負わないものとします。

共有の直接設定

特定のレコードセットにアクセスする必要がある一貫したユーザーグループを定義できない場合があります。レコード所有者やシステム管理者など、適切な権限を持つユーザーは、共有の直接設定を使用して、他の方法ではアクセス権を持たないユーザーに参照および編集権限を付与できます。共有の直接設定は組織の共有設定、ロール階層、または共有ルールのように自動化されていません。ただし、レコード所有者は、表示する必要があるユーザーと柔軟にレコードを共有できます。

共有の直接設定は、レコード所有者が変更された場合、または付与された共有アクセス権によってオブジェクトの組織の共有設定のアクセス権を超える追加アクセス権が付与されていない場合に削除されます。これは、プログラムで作成された手動共有にも適用されます。

共有の直接設定レコードは、行の原因が共有の直接設定になっている共有レコードとして定義されます。

行原因が共有の直接設定になっているすべての共有レコード (標準オブジェクトおよびカスタムオブジェクト) は、共有レコードがプログラムで作成されていても、オブジェクトのページレイアウトの [共有] ボタンを使用して編集および削除できます。

チーム

チームは、取引先、商談、またはケースで一緒に作業するユーザーのグループです。レコード所有者は、所有しているレコードごとにチームを作成できます。レコード所有者は、チームメンバーを追加し、各チームメンバーのレコードに対するアクセス権を指定します。一部のチームメンバーは参照のみアクセス権を持ち、他のチームメンバーは参照・更新アクセス権を持ちます。

チームメンバーを追加し、メンバーにさらにアクセス権を付与できるのは、所有者、階層の上位のユーザー、管理者のみです。参照・更新アクセス権を持つチームメンバーは、チームに関連付けられているレコードにすでにアクセス権を持つ別のメンバーを追加できます。チームメンバーは追加のアクセス権を付与できません。

アプリケーションでチームメンバーを作成すると、チームレコードと関連する共有レコードの 2 つのレコードが作成されます。プログラムでチームメンバーを作成する場合、チームレコードと関連共有レコードの両方を管理する必要があります。レコードごとに 1 つのチーム (取引先、商談、ケース) のみが存在する。複数のチームが必要な場合、特定のニーズに応じて、テリトリー管理またはプログラムでの共有を検討します。

テリトリー階層

エンタープライズテリトリー管理を使用する場合、モデルのテリトリー構造を表示し、そのメインインタラクションポイントとして機能するテリトリー階層を設定します。エンタープライズテリトリー管理が有効になっている場合、ロール階層とテリトリー階層の両方を管理する必要があります。詳細は、Salesforce ヘルプの「エンタープライズテリトリー管理」を参照してください。

Apex による共有管理

Apex による共有管理 (プログラムによる共有とも呼ばれる) では、データアクセスの要件を他の方法で満たすことができない場合に、コードを使用して高度で動的な共有設定を作成できます。

プログラムで共有レコードを作成し、標準の行原因 (手動共有) が使用されている場合、アプリケーションの [共有] ボタンを使用してこの共有レコードを維持できます。共有レコードには、所有者の移行時に削除など、共有行を手動で設定したすべてのルールが適用されます。

また、カスタム・オブジェクトの独自の Apex 共有理由を作成して、ユーザーまたはユーザー・グループとレコードを作成した理由を追跡し、共有レコードの更新や削除に必要なコーディングを合理化することもできます。

詳細は、プログラムによる共有の使用を検討する前に、「Apex を使用したレコードの共有」を参照してください。

制限ルール

データアクセス設定では、機密データが含まれる可能性があるレコードや、作業に不可欠ではないレコードをユーザーに表示しないようにすることができます。制限ルールを使用して、指定した条件を満たすレコードへのアクセスのみをユーザーに許可できます。制限ルールをユーザーに適用すると、組織の���有設定、共有ルール、および他の共有メカニズムを通じてそのユーザーにアクセス権が付与されているレコードが、指定した条件によって絞り込まれます。制限ルールは、このトピックで説明する共有コンポーネントとは逆に機能し、ユーザーにアクセスを許可する代わりに、さらに制限します。

制限ルールは、カスタムオブジェクト、外部オブジェクト、契約、行動、ToDo、タイムシート、タイムシートエントリで使用できます。Enterprise Edition と Developer Edition ではオブジェクトあたり最大 2 つの有効な制限ルールを作成でき、Performance Edition と Unlimited Edition ではオブジェクトあたり最大 5 つの有効な制限ルールを作成できます。制限ルールは、次の Salesforce 機能に適用されます。

• リストビュー
• ルックアップ
• 関連リスト
• レポート
• 検索
• SOQL
• SOSL

暗黙的な共有

暗黙的な共有は自動的に行われます。無効にすることも、有効にすることもできません。つまり、アプリケーションにネイティブです。つまり、暗黙的な共有は設定可能な設定ではありませんが、アーキテクトが理解しておくことが重要です。親の暗黙的な共有とは、ユーザーがその取引先の子商談、ケース、または取引先責任者にアクセスできる場合に、親レコード (取引先のみ) へのアクセス権を付与することです。Salesforce には、ユーザーが取引先責任者 (または商談、ケース、注文) を表示できるかどうかを示すデータアクセスポリシーがあり、ユーザーには関連付けられた取引先が暗黙的に表示されます。子の暗黙的な共有は、取引先所有者に取引先の子レコードへのアクセス権を付与します。このアクセス権は、ロール階層内の所有者のロールで定義されます。子の暗黙的な共有は、取引先責任者、商談、ケースオブジェクト (取引先の子) にのみ適用されます。指定できるアクセスレベルは、ロールの作成時に各子オブジェクトに対して「参照」、「編集」、および「アクセス権なし」です。[表示] に設定すると、取引先所有者は関連付けられたオブジェクトレコード (取引先責任者、商談、またはケース) を暗黙的に表示できます。[編集] に設定すると、取引先所有者は関連付けられたオブジェクト (取引先責任者、商談、またはケース) を暗黙的に変更できます。

暗黙的な共有はカスタムオブジェクトには適用されません。

すべての Salesforce 組織に適合する共有モデルはありません。最適な共有モデルを構築しようとする場合、組織ごとに異なる要件と課題があります。組織の共有要件に合わせて最適なデータアクセスコンポーネントを使用することが重要です。次のシナリオは、共有モデルを作成するときの一般的な課題です。

• ロール階層の処理

  • テリトリー階層も使用している場合は、ロール階層には何も影響しません。ただし、テリトリーベースの売上予測とロールベースの売上予測の両方を使用している場合は、2 つの階層を管理する必要があります。この場合、ロール階層を使用して HR レポート構造をモデル化し、テリトリー階層を使用して実際のセールス階層をモデル化することをお勧めします。テリトリー階層は、誰かが複数のマネージャーの部下になれるマトリックスレポート構造をモデル化する場合に最適です。

    テリトリーベー��の売上予測とロールベースの売上予測を併用していない場合、テリトリー階層のみをセールス階層として使用できます。このシナリオでは、階層をできるだけ簡略化するかフラット化することをお勧めします。

    ロール階層とテリトリー階層を同じにすることはお勧めしません。これは、不要な共有活動が発生するためです。

• Can You Still Use Teams? (まだチームを使用できますか?)

  • はい、できます。ただし、テリトリー階層内 (オーバーレイなど) でアクセス要件を満たすことができる場合は、チームを使用するのではなく、そこで行うことをお勧めします。すでに複数の階層 (ロールとテリトリー) を管理しているため、できるだけシンプルにするために、他の既存の共有コンポーネントで要件を満たせない場合にのみチームを実装します。

• 再配置と再割り当て

  • ロール、チーム、またはテリトリーのメンバーシップと階層の構造の 2 種類の変更が行われます。メンバーシップの変更は通常、毎日 (1 時間ごと) 行われます。階層構造 (再配置) の変更は一般的に頻度が低く (四半期、半年、または毎年)、リソースコストが高くなる可能性があります。考慮する必要があるのは、変更の量と、各変更によって発生するカスケード変更の数です。経験則として、構造的な変更は四半期ごとに行い、大量の変更 (一括または一括変更) はすべて綿密に計画、テスト、調整します。

• 大量のデータ

  • 最初のロールアウトに向けてモデル化する場合も、再配置の変更を計画する場合も、データ量を真剣に考慮する必要があります。パフォーマンスに影響するしきい値があるため、本番環境に移行する前に Sandbox で変更をテストすることを強くお勧めします。このテストにより、変更にかかる時間のベースラインもわかります。

    200 万件を超える取引先があり、チームまたはエンタープライズテリトリー管理を実装している場合は、特にパフォーマンスに注意する必要があります。これらは、膨大な共有レコード、つまり実行時間の長いトランザクションが発生する可能性がある複雑な共有モデルコンポーネントです。

• 共有適用の延期

  • 共有を利用するオブジェクトがあり、大量のレコード (200 万件を超える取引先など) がある場合、一括変更 (階層の変更を必要とする四半期ごとの再配置など) を行う必要があると、Salesforce カスタマーサポートで共有の自動適用を延期できる機能があります。ネイティブに、ロール階層、テリトリー階層、グループ、共有ルール、ユーザーロール、チームメンバーシップ、またはレコードの所有権に対する個々の変更ごとに、自動共有適用を開始できます。一括変更が行われると、多数の共有の自動再適用が開始されます。これらの再適用を一時的にサスペンドすることで、変更を行い、共有適用を一度に行うことができます。通常、この方法は一括変更の効率とパフォーマンスが向上します。

• データと所有権の歪み

  • データスキューは、多数の子レコードを含むいくつかの親レコードとして定義されます。これらの歪みは、いくつかの取引先に多数の取引先責任者、商談、またはケースがある場合に非常に痛手となります。パフォーマンスの低下が見られる割合は 1 対 10,000 です。ベストプラクティスとして、この比率をできるだけ近くしてください (低い方が望ましい)。

    所有権のスキューはデータスキューと似ていますが、オブジェクトの多数のレコードを所有する 1 人のユーザー、ロール、またはグループを指します。データスキューと同様に、実行中のトランザクションも長くなるため、変更が発生するとパフォーマンスが低下する可能性があります。所有者とレコード数の比率も 1:10,000 にすることをお勧めします。

    1 人のユーザーが 10,000 件を超えるレコードを所有している場合、ベストプラクティスとして次の点に留意してください。

    • 所有者のユーザーレコードには、ロール階層内のロールを含めることはできません。

    • 所有者のユーザーレコードでロールを保持する必要がある場合は、ロール階層の独自のブランチでロールを階層の最上位に配置します。

• データアクセスに対する取引先階層の影響

  • 多くの場合、取引先階層を実装するときに誤った仮定をします。親取引先にアクセスできるユーザーが子取引先にもアクセスできると想定しています。2 つのレコード間に親/子リレーションしかないという単純な事実は、アクセスを促進しません。ロール階層とテリトリー階層はこの方法で機能しますが、取引先階層は機能しません。

共有モデルアーキテクチャを完了すると、ユーザーがレコードを表示または非表示にできる理由に関する疑問が生じる可能性があります。通常、ユーザーが表示すべきでないものをユーザーがいつ表示できるかは表示されませんが、必要に応じて、レコードへのアクセス権を持つすべてのユーザーとその理由を確認する方法があります。

より難しい問題 (おそらく一般的) は、ユーザーがレコードを表示できない理由です。構築したセキュリティレイヤーによって、どこから開始するかが決まります。共有モデルを熟知していれば、どのコンポーネントがアクセス権を提供すべきで、そこから開始できるのかがおそらくわかります。ただし、共有モデルに慣れていない場合は、ロール階層から開始し、各レイヤーを剥がしてアクセス権を付与するレイヤーを決定します。トラブルシューティングフローを次に示します。

1. ユーザーにオブジェクトにアクセスする権限があることを確認します。
2. レコードを表示およびメモできないユーザーのロールを特定します。
3. レコードのロールの所有者を特定し、メモします。
4. ロール階層を確認し、これら 2 つのロールが 2 つの異なるブランチにあることを確認します (異なるブランチにある必要があります)。
5. 次に、オブジェクトの共有ルールを確認し、ユーザーにアクセス権を付与するルールがないことを確認する必要があります。必要に応じて、公開グループも確認します。共有ルールがあるグループからユーザーが除外されたか、新しい共有ルールを作成してユーザーにアクセス権を付与することが理にかなっているか。この選択は、維持しようとしているアーキテクチャに応じて異なり、所有者に基づく共有ルールと条件に基づく共有ルールの両方に適用されます。
6. チームを使用している場合、このユーザーはそのレコードのチームに属している必要がありますか?チームの管理方法とミスの発生方法は?
7. 共有の直接設定を使用している場合、レコード所有者が変更されたためにユーザーがアクセス権を失った可能性があります。共有の直接設定は、所有者が変更されると削除されます。手動共有は、[共有] ボタンを使用して削除することもできます。
8. エンタープライズテリトリー管理を使用している場合、ユーザーがいずれかのテリトリーに欠落していませんか?テリトリーのメンバーシップはどこで維持され、ミスはどのように発生したか?または、ユーザーがメンバーであるテリトリーにレコードが割り当てられなかった可能性があります。
9. プログラムによる共有を作成する場合、コードで共有を作成する条件があるときは、コードを確認してこのユーザーが省略された理由を把握します。