共有パフォーマンスを最適化するためのベストプラクティス

この領域の詳細なガイドについては、「エンタープライズ規模のレコードアクセスの設計」を参照してください。

組織の共有設定

• セキュリティ設定で許可されている場合は、機密以外のデータへのデフォルトの内部アクセス権として [公開/参照のみ] または [参照・更新可能] を使用します。外部ユーザーのアクセスを保護するために、デフォルトの外部アクセス権を [非公開] に設定することをお勧めします。
• 親の暗黙的な共有が作成されないようにするには、この設定がセキュリティ要件を満たしているすべての場所で、子オブジェクトを親で制御するように設定します。

ロール階層

• データアクセスの設定に不要なロールは作成しないでください。たとえば、同じアクセス要件があり、組み合わせることができるロールがある場合は、会社の組織図を正確に再作成しないでください。
• ロール階層のレベル数を最小限に抑えます。最大 10 レベルにすることをお勧めします。
• Experience Cloud サイトでは、できるだけパートナーロールと顧客ロールの数を 1 つに減らします。
• パートナーロールをロール階層内の別のブランチに移動します。次に、共有ルールを使用して、パートナーユーザーにパートナー取引先へのアクセス権を付与します。この設定により、取引先所有者の変更があった場合の再配置操作のパフォーマンスが向上します。

公開グループ

• 公開グループは、ロールが異なる複数のユーザーの表示要件が同じで、グループメンバーシップを頻繁に変更する必要がない場合に使用します。
• 公開グループメンバーより上位のユーザーがグループで共有されているレコードにアクセスする必要がない場合は、[階層を使用したアクセス権の付与] 設定を無効にします。
• 公開グループのメンバーを 10,000 人に制限します。
• 5 レベルを超えるネストが発生する公開グループ内に公開グループを作成しないでください。

共有ルール

• 共有ルールを定期的に確認し、アクセスの冗長パスを削除します。たとえば、共有ルールは、ロール階層を介してすでに共有ルールを持つユーザーにアクセス権を付与するため、不要になります。
• 2 つの異なる公開グループを対象とする 2 つの同一の共有ルールがある場合、パフォーマンス上の理由から、両方の公開グループのメンバーを含む 1 つの公開グループを対象とする共有ルールを 1 つ作成することをお勧めします。

データアクセスと所有権

• 1 人のユーザーまたはキューが 10,000 件を超えるオブジェクトのレコードを所有することを許可しないでください。この状態は所有権データスキューと呼ばれ、所有するユーザーのロールまたは公開グループを調整すると、パフォーマンスの問題が発生する可能性があります。この問題を修正する
  • レコードの所有権をより多くのユーザーに分散します。
  • 10,000 件を超えるレコードを所有するユーザーにロールを割り当てないでください。
  • 10,000 件を超えるレコードを所有するユーザーにロールを割り当てる必要がある場合は、階層の最上位にユーザーを別のロールに配置して、階層内の上位者に対する共有が実現されないようにします。次に、このユーザーをこの最上位ロールから移動したり、共有ルールで使用できる公開グループにユーザーを含めたりしないでください。
• 10,000 件を超える子レコードを 1 つの親取引先に関連付けないでください。この設定は親子データスキューと呼ばれ、データの更新またはアップロードのパフォーマンスが低下する可能性があります。この問題を修正する
  • 取引先のプールを作成し、ラウンドロビン方式で子を割り当てます。
  • 歪んだアカウントがある場合、レコードレベルのロックの競合の影響を軽減するために、ピーク時間外に子オブジェクトをチャンクで再配布します。一括処理 Apex または Bulk API は、親プロセスを作成するのに役立ちます。
  • 可能な場合は、親取引先がロックされたままで、共有適用が実行されない公開/参照・更新可能共有モデルを検討します。
• 特定のオブジェクトの 10,000 件を超えるレコードをユーザーと手動で共有しないでください。共有ルールなど、別の共有メカニズムを使用します。