レコードアクセス権に関連し て Salesforce 内部で実行され る処理 Salesforce, Summer ’15 @salesforcedocs 最終更新日: 2015/5/21 © Copyright 2000–2015 salesforce.com, inc. All rights reserved. Salesforce およびその他の名称や商標は、salesforce.com, inc. の登録商標です。本ドキュメントに記載されたその他の商標は、各社に所有権があります。 目次 レコードアクセス権に関連して Salesforce 内部で実行される処 理................................................................1 このドキュメントについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Salesforce のデータアクセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 レコードアクセス権の計算 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 アクセス権の付与 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 データベースアーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 共有行 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Group Maintenance テーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 サンプルシナリオ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 すべてを総合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 レコードアクセス権に関連して Salesforce 内部で実 行される処理 このドキュメントについて Salesforce のアーキテクトであれば、データセキュリティの包括的目標が、組織のエンタープライズセキュリ ティモデルを理解し、各自のSalesforce組織でそのモデルを反映するデータアクセスモデルを構築することであ ることをご存じのことと思います。Salesforce では、こうしたデータアクセスを管理するための豊富なツール セットを自由に使用できますが、1 つのレベルのみでデータアクセスを管理するわけではありません。アクセ スをいつ、どのように制御するかをオブジェクト、レコード、項目の各レベルで慎重に検討する必要がありま す。 このドキュメントでは、各レベルのデータアクセスと、内部で実行されるレコードレベルのアクセス権のテー ブルレベルビューについて概説します。『レコードアクセス権に関連して内部で実行される処理』を読むと、 適切な時点で適切なユーザに適切なレコードへの適切なアクセス権を、可能な限り早いタイミングで、確信を もって付与できるようになります。 対象利用者 このドキュメントは、Salesforce実装で複雑なレコードアクセス要件や大規模なセールス組織の再配置に対応す るエキスパートアーキテクトを対象としています。 前提条件 また、読者に、Salesforce の管理とセキュリティ、SQL およびリレーショナルデータベースの概念についての専 門知識があることを前提としています。 Salesforce のデータアクセス 自社のセキュリティ上のニーズを満たすためには、ユーザにとって、そして開発者自身にとってデータアクセ スが何を意味するのかを理解しておくことが重要です。 データアクセス: ユーザの観点 ユーザの立場では、レコードにどのようにアクセスしているのかを知ることは必ずしも重要ではありません が、組織のコンテキスト内でアクセス権を持つことの意味を理解しておくことが推奨されます。次のグラフに は、Salesforce で構成可能な各種のアクセス権がわかりやすく図示されています。 1 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 Salesforce のデータアクセス たとえば、ユーザに取引先項目へのアクセス権があれば、取引先項目と取引先オブジェクト自体のどちらにも アクセスできます。ただし、共有ルールその他のツールによって追加のアクセス制御が適用されている場合 は、「取引先 A」など特定の取引先レコードにアクセスできなくなります。 データアクセス: アーキテクトの観点 アーキテクトは、ユーザの観点を理解すると同時に、ユーザがアクセスする必要のあるデータのみへの適切な アクセスレベルを付与する方法を把握しておく必要があります。 アーキテクトの観点からみると、Salesforce のデータアクセスは、オブジェクトレベルのアクセス権 (項目レベ ルのアクセス権を含む) とレコードレベルのアクセス権に大別されます。 オブジェクトレベルのアクセス権は、ユーザが特定のオブジェクトにアクセスできるかどうか、そのオブジェ クトのどの項目を表示できるか、どのアクションを実行できるかを決定します。オブジェクトレベルのアクセ ス権はユーザプロファイルで設定します。 アクセスの制限 「参照」、「作成」、「編集」、および「削除」のオブジェクト権限は、ユーザがアクセス権を持つオブ ジェクトのレコードでどのアクションを実行できるかを決定します。項目レベルセキュリティでは、特定 のユーザに対して、表示されるレコードに含まれる部外秘または機密の情報を非表示にすることができま す。 アクセス権の開放 「すべての参照」および「すべての編集」オブジェクト権限を使用すると、ユーザが、レコードレベルの アクセス権に関係なく、オブジェクトの全レコードにアクセスできます。 2 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 レコードアクセス権の計算 レコードレベルのアクセス権 (Salesforce では「共有」という) は、次のツールを使用して、ユーザが特定のオブ ジェクトのどのレコードを表示できるかを決定します。 • 組織の共有設定 • ロール階層 • テリトリー階層 • 共有ルール • チーム • 共有の直接設定 • プログラムによる共有 レコードレベルのアクセス権の管理にはさまざまなオプションがあり、さらに、一部のオプションは組織的連 動関係の影響を受けるため、ユーザがどのレコードにアクセスできるかの判別がすぐに複雑になってしまう可 能性があります。さらに、ビジネス要件の刷新に応じて共有設定を頻繁に変更している可能性があります。こ うした変更によるレコードアクセス権の変更が組織全体に波及する場合があります。大規模な組織では、これ らの変更による影響がとりわけ大きく、多数のユーザのアクセス権を再計算し、アクセス権限を記録するテー ブルを調整するために時間がかかる場合があります。こうした理由により、Salesforceではデータベースレベル でアクセス権がどのように計算および付与されるのかを理解しておくことが重要です。 レコードアクセス権の計算 ユーザがユーザインターフェースまたは API を使用して、レコードを開こうとしたり、レポートを実行しよう としたり、リストビューにアクセスしようとしたり、データを検索しようとしたりするたびに、Salesforceによ り、ユーザがアクセスできるレコードを判別するためにレコードアクセス機能の設定がチェックされます。特 に何百もの階層ノード、何千もの共有ルール、何百万ものデータ行、および顧客やビジネスパートナー用の ポータルがある大規模な組織の場合、これらの設定が複雑になっている可能性があります。そのような異種 データや複雑なリレーションを処理する場合、ページを表示するのに 300 ミリ秒 (Salesforce ベンチマーク) をは るかに超える時間が必要になります。 Salesforceでは、各共有ルールの適用、すべての階層のトラバース、レコードアクセス権の継承の分析をリアル タイムで行うのではなく、設定の変更が発生した場合にのみレコードアクセスデータを計算します。計算結果 は、迅速なスキャンを容易にし、実行時にアクセスできるレコードを判別するために必要なデータベーステー ブル結合数を最小化するような方法で保持されます。 アクセス権の付与 オブジェクトに組織の共有設定として [非公開] または [公開/参照のみ] が設定されている場合、Salesforce では、 アクセス権の付与によって、ユーザまたはグループがそのオブジェクトのレコードにどの程度アクセスできる かを定義します。各アクセス付与によって、特定のレコードに対するアクセス権が、特定のユーザまたはグ ループに付与されます。また、そのアクセス権の付与に使用する共有ツールの種類 (共有ルール、チームなど) も記録されます。Salesforceでは、明示的付与、グループメンバーシップの付与、継承による付与、暗黙的付与 の 4 種類のアクセス付与を使用します。 3 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 データベースアーキテクチャ 明示的付与 Salesforceは、レコードがユーザまたはグループと直接共有される場合に明示的付与を使用します。Salesforce が明示的付与を使用するのは、具体的に次の場合です。 • ユーザまたはキューがレコードの所有者になる。 • 共有ルールが、非公開グループ、公開グループ、キュー、ロール、またはテリトリーとレコードを共有 している。 • 割り当てルールが、ユーザまたはキューとレコードを共有している。 • テリトリー割り当てルールが、テリトリーとレコードを共有している。 • ユーザが、ユーザ、非公開グループ、公開グループ、キュー、ロール、またはテリトリーとレコードを 手動で共有している。 • ユーザが、取引先、商談、またはケースのチームの一員になる。 • プログラムを使用するカスタマイズで、ユーザ、非公開グループ、公開グループ、キュー、ロール、ま たはテリトリーとレコードを共有している。 メモ: 組織に効率的な共有アーキテクチャがない場合、大規模な営業の再配置など、膨大な権限を明 示的に付与する自動化プロセスを使用した場合に、パフォーマンス上の問題が発生することがありま す。 グループメンバーシップの付与 ユーザ、公開グループ、非公開グループ、キュー、ロール、またはテリトリーが、レコードへの明示的ア クセス権を持つグループのメンバーである場合に行われる付与です。たとえば、共有ルールによって Acme レコードへのアクセス権が「Strategy」というグループに明示的に付与され、Bob がそのグループのメンバー である場合、Bob の Strategy グループのメンバーシップによって、Acme レコードへのアクセス権が Bob に付 与されます。 継承による付与 ユーザ、公開グループ、非公開グループ、キュー、ロール、またはテリトリーが、ロールまたはテリトリー 階層に従ってアクセス権を継承するか、グループ階層に従ってアクセス権を継承するグループのメンバー である場合に行われる付与です。 暗黙的付与 Salesforce のセールス、サービス、およびポータルのアプリケーション内に組み込まれた、設定不可能なレ コード共有動作によって、特定の親レコードと子レコードへのアクセス権が付与される場合に行われる付 与です。たとえば、組み込みの共有と呼ばれることもあるこのデフォルトロジックを使用して、ユーザは、 親取引先レコードを、その子である商談、ケース、または取引先責任者のレコードへのアクセス権を持っ ている場合に表示できます。これらのユーザが親取引先レコードへのアクセス権を持っている場合、その 子である商談、ケース、および取引先責任者レコードにもアクセスできます。 データベースアーキテクチャ Salesforce では、3 種類のテーブルにアクセス権が保存されます。 Object Record テーブル 特定のオブジェクトのレコードが保存されるテーブルで、各レコードを所有するユーザ、グループ、また はキューを示します。 4 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 データベースアーキテクチャ Object Sharing テーブル 明示的または暗黙的な権限をサポートするデータが保存されるテーブル。オブジェクトが主従関係の従オ ブジェクトである場合を除き、オブジェクトごとに独自の Object Sharing テーブルがあります。主従関係が ある場合、主オブジェクトのオブジェクト共有テーブルが従オブジェクトへのアクセスを制御します。 Group Maintenance テーブル グループメンバーシップと継承されたアクセス権をサポートするデータが保存されるテーブル。たとえば、 Object Sharing テーブルが Bob に Acme 取引先レコードへの明示的なアクセス権を付与した場合、Salesforce は、 Group Maintenance テーブルをチェックして、Bob からレコードアクセス権を継承したユーザを確認し、ユー ザに Acme レコードへのアクセス権を付与します。これらの付与は、グループ (またはロールあるいはテリ トリー) メンバーシップ情報の作成または変更時にあらかじめ確定されます。 Object Sharing テーブルには個人およびグループへのアクセス付与が保存されるのに対し、Group Maintenance テー ブルにはグループメンバーシップを示す、各グループに属するユーザまたはグループのリストが保存されま す。どちらのタイプのテーブルも、ユーザがレポートまたはリストビューを検索、クエリ、またはプルアップ する場合にそのユーザのデータへのアクセス権を判断するために使用されます。 ユーザが 1 つ以上のレコードを取得しようとすると、Salesforce は、Object Record テーブルでユーザの検索文字列 に一致するレコードを検索する SQL ステートメントを生成します。レコードが存在する場合、Salesforce は、ス テートメントに Object Record テーブルと Object Sharing テーブル、Object Sharing テーブルと Group Maintenance テー ブルを結合する SQL を付加します。Salesforce は、結合されたテーブルで、クエリ実行ユーザにレコードへのア クセスを許可するアクセス権をクエリします。 結合するテーブル Salesforce の一致基準 Object Record と Object Sharing レコード ID Object Sharing と Group Maintenance ユーザ ID またはグループ ID この図は、Salesforce の一致プロセスを順序に従って示しています。 Salesforce は、付加した SQL を含め、ステートメント全体を満たすレコードのみを返します。ステートメントを 満たすには、レコードが存在し、Object Sharing テーブルまたは Group Maintenance テーブルがクエリ実行ユーザ にアクセス権を付与する必要があります。 オブジェクト共有テーブルとグループメンテナンステーブルの両方がアクセス権を付与することができます が、その方法は大きく異なります。 • Object Sharing テーブルでは、単純に各アクセス権が共有行と呼ばれる個別の行に保存され、各共有行がユー ザまたはグループに特定のレコードへのアクセス権を付与します。 5 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 共有行 • グループメンテナンステーブルでは、1 つのグループメンバーシップまたは継承されたアクセス権によっ て、各ユーザおよびグループがレコードにアクセスする方法が複数存在するため、より複雑です。 共有行 各共有行には、次の情報が含まれます。 • この行がアクセス権を付与するレコードの ID • この行がアクセス権を付与するユーザまたはグループの ID • この行が許可するアクセスレベル (参照のみ、フルアクセスなど) • Salesforce がユーザまたはグループにレコードへのアクセス権を付与する理由を示す共有理由 たとえば、レコード所有者がレコードをユーザまたはグループとの共有を直接設定する場合、Salesforceは、 共有理由が Manual の共有行を作成します。共有ルールによってレコードをユーザまたはグループと共有 する場合、Salesforce は、共有理由が Rule の共有行を作成します。 次の例の簡略化されたテーブルは、Salesforce が内部で共有行を作成する方法を示します。 メモ: 判読しやすいように、これらのテーブルには、実際のデータベース値や構造のすべては含まれてい ません。 例1 Sales Executive ロールの Maria が、「Acme」という企業の取引先レコード (ID=A1) を作成します。内部では、Salesforce が Account Sharing テーブル (Account オブジェクトの Object Sharing テーブル) にレコード所有者として Maria の共有 行を作成します。 例2 Maria は Acme 取引先レコードを Services Executive の Frank と共有するよう直接設定します。内部では、Salesforce が Frank の共有行を作成します。 6 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 Group Maintenance テーブル Acme の取引先レコードは 1 件のみですが、Account Sharing テーブルには、Acme レコード用に 2 つのエントリが 含まれます。この更新は、Salesforce が Acme 取引先レコードへのアクセス権を 2 回 (所有者として Maria に 1 回、 Frank に 1 回) 付与したために発生します。 例3 システム管理者が、Sales Executive のレコードを Strategy グループと共有する共有ルールを作成し、Strategy グルー プに「参照のみ」アクセス権を付与します。内部では、Salesforce が、Strategy グループに Maria の Acme 取引先レ コードへのアクセス権を付与する共有行を作成します。 レコードへのアクセス権を複数持つユーザの場合、Salesforceは、レコードアクセス権を判定するときに最も権 限の高い権限を使用します。たとえば、Frank が Strategy グループに参加した場合、Frank には例 2 で Maria から付 与された「参照・更新」アクセス権もあります。 複数のユーザのレコードアクセス要件が同じ場合、それらのユーザをグループにして、個人ではなくそのグ ループにアクセス権を付与すると効率的です。この方法では時間が節約され、結果的に共有行の数が少なくな るため、組織のレコードアクセスデータ量が削減されます。 Group Maintenance テーブル 共有行でユーザおよびグループにアクセス権が付与されますが、各グループに属するユーザを示すデータは Group Maintenance テーブルにあります。これらのテーブルには、システム定義グループを含む、すべてのSalesforce グループのメンバーシップデータが保存されています。システム定義グループは、キューなどの各種機能およ び動作をサポートするためにSalesforceが内部的に作成して管理するユーザのグループです。このタイプの管理 では、キューをサポートするデータと非公開グループまたは公開グループをサポートするデータが同じデータ ベーステーブルで共存でき、Salesforce のデータ管理方法を統合できます。たとえば、Salesforce は、公開グルー プにレコードアクセス権を付与する場合と同じ方法でキューにレコードアクセス権を付与できます。 また、Salesforce は、システム定義グループを使用して階層を実装します。Salesforce は、再適用時にロール階層 のノードごとに Role グループと RoleAndSubordinates グループの 2 種類のシステム定義グループを作成します。組 織で外部組織の共有設定が有効になっている場合は、3 つ目の種類のシステム定義グループ RoleAndInternalSubordinates が作成されます。 グループ 構成 目的 Role 次のいずれかに割り当てられるユー マネージャに部下のレコードへの ザ アクセス権を付与するために使用 する • 特定のロール 7 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 グループ Group Maintenance テーブル 構成 目的 • いずれかのマネージャロール RoleAndSubordinates RoleAndInternalSubordinates 次のいずれかに割り当てられるユー 次のロールで一連のレコードを共 ザ 有するルールを組織で定義する場 合に使用する • 特定のロール • いずれかのマネージャロール • 特定のロール • いずれかの下位ロール • 下位ロール 次のいずれかに割り当てられるユー 次のロールで一連のレコードを共 ザ 有するルールを組織で定義する場 合に使用する • 特定のロール • いずれかのマネージャロール • 特定のロール • いずれかの下位ロール (ポータル • 下位ロール (ポータルロールを除 く) ロールを除く) 3 つの種類のどのグループにも、次のメンバーが含まれます。 • グループの直接メンバーからレコードアクセス権を継承し、マネージャロールに割り当てられる間接メン バー • グループの種別に応じて定義される直接メンバー – Role グループの場合、直接メンバーはグループが表すロールに割り当てられるメンバーです。 – RoleAndSubordinates グループの場合、直接メンバーはグループが表すロールまたはいずれかの下位ロール に割り当てられるメンバーです。 – RoleAndInternalSubordinates グループの場合、直接メンバーはグループが表すロールまたはポータルを除く いずれかの下位ロールに割り当てられるメンバーです。 次の簡単なロール階層を例に、考えてみましょう。 この階層で確立されるレコードアクセス権の継承をサポートするために、Salesforce は次の Role グループと RoleAndSubordinates グループ (合計 8 個のグループ) を定義します。 8 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 Group Maintenance テーブル Salesforce は、Role グループをスキャンすることで、このロールに該当するユーザからレコードアクセス権を継 承する間接メンバーをすばやく識別できます。たとえば、ロール階層で Bob からレコードアクセス権を継承す るユーザを識別する場合、Salesforce は、Bob が直接メンバーである Role グループ (East Sales Rep Role グループ) を 検索するだけで、このグループのすべての間接メンバー (Marc と Maria) を見つけることができます。 同様に、Salesforce は、RoleAndSubordinates グループをスキャンすることで、ロールと下位ロールの共有ルールを 介してアクセス権が付与されるユーザをすばやく識別できます。たとえば、Sales Executive ロールのユーザとそ の下位ロールのユーザで一連のレコードを共有するルールが設定されている場合、Salesforce は、Sales Executive ロールの RoleAndSubordinates グループをスキャンすることでこれらのユーザを識別できます。 システム定義グループでは、同様にテリトリー管理がサポートされています。 テリトリーごとに、Salesforce は次のグループを作成します。 • テリトリーに割り当てられたユーザが直接メンバーとなり、階層の上位のテリトリーに割り当てられたユー ザが間接メンバーとなる Territory グループ • 該当のテリトリーまたは階層の下位のテリトリーに割り当てられたユーザが直接メンバーとなり、そのブ ランチの上位のテリトリーに割り当てられたユーザが間接メンバーとなる TerritoryAndSubordinates グループ システム定義グループがない場合、レコードアクセスが試行されるたびに、ユーザデータのテーブルと階層 データのテーブルとの間を行ったり来たりして、階層のすべてのブランチでSalesforceトラバースを送信する必 要があります。また、Salesforce は、まったく異なるプロセスを使用して、実質的にすべてのユーザのコレク ションを処理する必要があります。 ユーザは、非公開グループや公開グループのようにユーザインターフェースまたは API を使用してシステム定 義グループを変更できません。ただし、キューや階層を変更すると、Salesforceにより、それに関連付けられて いるシステム定義グループが再適用されます。そのため、組織のキューや階層のサイズおよび複雑さは、レ コードアクセス権の計算時間に直接影響します。 9 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 サンプルシナリオ サンプルシナリオ 次のシナリオでは、簡略化されたテーブルを使用して、Salesforce がさまざまなレコードアクセス権の変更に 従って Object Sharing テーブルと Group Maintenance テーブルをどのように再計算し、アクセスできるレコードを 判別するためにそれらの計算をどのように使用するのかを説明します。黄色で強調表示されている部分は、サ ンプルの取引先レコードへのアクセス権を付与するデータを示しています。 メモ: これらのシナリオでは、例に不可欠なデータのみが示されています。Salesforce がレコードアクセス 権を計算するために使用するすべての項目とテーブルが表示されているわけではありません。 これらのシナリオでは、組織全体にわたるデフォルト設定はすべてのオブジェクトに対して非公開であり、 ロール階層とユーザは次のように設定されます。 Salesforceは次のグループを生成して、ロール階層によって構築されるレコードアクセス権の継承をサポートし ます。 10 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 サンプルシナリオ シナリオ 1 Maria は、Acme の取引先レコード (A1) を作成します。内部では、Salesforce が Account Sharing テーブルに、Acme の 新しい取引先レコードと、所有者として Maria の共有行を作成します。 11 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 サンプルシナリオ シナリオ 2 Maria は Acme の取引先レコードを Bob と共有するように直接設定します。内部では、Salesforce が Account Sharing テーブルに、Bob の共有行を作成します。 レコード共有の直接設定、プログラムによるレコード共有の設定、およびチーム共有設定の場合、いずれも同 様に Object Sharing テーブルに共有行が作成されますが、共有理由は異なります。 12 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 サンプルシナリオ シナリオ 3 システム管理者は、Sales Executive のレコードを、Services Executive ロールとその下位のロールに含まれるユーザ と共有する共有ルールを作成します。内部では、Salesforce が Services Executive ロールの RoleAndSubordinates グルー プの Account Sharing テーブルに共有行を作成し、Frank と Sam に Acme レコードへのアクセス権を与えます。 13 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 サンプルシナリオ シナリオ 4 Maria は Acme のレコードの所有者を Wendy に変更します。レコードの所有者が変わると、Salesforce は所有者に 関連付けられ、共有理由が直接設定となっている共有行を削除するため、Bob はそのレコードへのアクセス権 を失います。また、Sales Executive である Maria はレコードを所有しなくなるため、シナリオ 3 のルールは適用さ れなくなります。内部では、Salesforce がシナリオ 3 で作成された Services Executive ロールの RoleAndSubordinates グ ループの共有行を削除するため、Frank と Sam は Acme レコードへのアクセス権を失います。また、Salesforceは、 Account Sharing テーブルで Maria の名前を Wendy の名前に置き換えます。 図中で赤い楕円形で囲まれた部分は、所有者の変更によって影響を受ける項目です。この一見したところ軽微 に見える変更ですが、多数の項目に影響が及ぶことがわかります。 14 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 すべてを総合 すべてを総合 このドキュメントのシナリオでは、ユーザのアクセス権が Salesforce プラットフォームの Object Sharing テーブル および Group Maintenance テーブルにどのように記録されるかを確認しました。これらの例は比較的単純で、多 くのテーブルでは数行しか変更されませんでした。ただし、一般的な管理操作では多くの場合、より膨大な量 のアクセス権を再計算する必要があり、基盤となるテーブルに多くの更新が加えられます。大量のデータおよ び複雑なロール階層を使用する組織では、特に複雑になります。ユーザロールの変更を例に挙げて、これらの 操作がどのように関係するかを説明します。この変更は、単純なグループ操作のように思えますが、実際には 共有の再計算に大幅な影響を与えるものです。前述のシナリオと同様に、組織全体のすべてのオブジェクトの デフォルト設定は非公開です。 ロール階層とユーザは、次の 2 点を除きほとんど同じです。 15 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 すべてを総合 • 小規模および中規模のビジネスパートナー販売組織で、新しいロールが作成されています。 • すべての Sales データへのアクセス権を Services ブランチに提供する広範囲な共有ルールではなく、West Sales Rep ロールのデータへのアクセス権のみを提供する、焦点を絞った共有ルールがあります。SMB Partner デー タは、 Services ブランチと共有しません。 このシナリオでは、West Sales Rep ロールから、ロール階層の別のブランチにある新しい SMB Partner Sales ロール に Wendy を移動します。 Wendy が移動すると、基盤となる共有システムの内部で、次の操作が実行されます。 • データを所有する新しいロールで Wendy が最初のメンバーである場合、階層内で Wendy の上位にあるロー ルに属すすべてのユーザに対して、Wendy のデータへのアクセス権が Salesforce によって付与されます。こ の処理は、それらのユーザを Wendy の新しいロールの間接メンバーにすることによって行われます。SMB Partner Sales ロールに Maria と Marc が追加されました。 • Wendy の古いロール設定では、取引先の子レコード (取引先責任者、ケース、および商談) にアクセスでき たが、新しいロールの設定がこれと異なる場合は、Salesforce で次の処理が実行されます。 – 子レコードに対する Wendy の一部の共有を削除する – 新しい共有を追加して、設定の変更を反映する 16 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 すべてを総合 • カスタマーポータルまたはパートナーポータルのいずれかに対して有効化された取引先を Wendy が所有す る場合は、Salesforce で次の処理が実行されます。 – グループメンバーシップに変更を加える – ポータルユーザが所有するかポータルユーザと共有する、階層内のレコードにアクセス権を付与する共 有を調整する ポータルが有効化された取引先ごとに、取引先所有者のロールの下で 1 ～ 3 個のロールが主階層に付加さ れます。Wendy が移動すると、Salesforceで、これらのポータルロールが Wendy の古いロールから削除され、 Wendy が所有し、ポータルが有効化されたすべての取引先の新しいロールに付加されます。 メモ: Salesforce では、Wendy の古いロールに書き込まれた共有 (各ポータル取引先のメンバーが所有す るか、そのメンバーに表示されるレコードへのアクセス権を Wendy および Wendy のすべての上司に付 与する共有) を削除して、それを新しいロールに追加する必要があります。 • Wendy の新しい割り当てを反映するため、ソースグループ内の Wendy の古いロールと新しいロールを含め、 すべての共有ルールが Salesforce で再適用されます。 17 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 すべてを総合 特に、Wendy のすべてのレコードに対する共有が次の場所から Salesforce によって削除されます。 – 階層の Service ブランチにある最上位ロール – そのすべての下位ロール Wendy の取引先の共有ルール設定に応じて、Wendy の取引先の子レコードに対する共有もSalesforceで削除し なければならない場合があります。 メモ: Wendy がポータル取引先を所有し、ポータルロールをソースグループとして使用する共有ルール が存在する場合、これらのルールを Salesforce で再適用しなければならない場合があります。これらの ルールは、階層内の Wendy の新しい場所では無効になる可能性があります。その場合は、システム管 理者がルールを変更または削除する必要があります。 これらの変更に加え、ブランチで Wendy の古いロールの上位にいるマネージャは、Wendy が所有するすべての データ、およびロール設定を使用して共有される子レコードにアクセスできなくなります。この処理は、階層 内での通常の継承操作の一部であり、グループメンバーシップまたは共有テーブルを更新する必要はありませ ん。 システム管理者がユーザのロールを変更するという単純に見えるアクションでも、内部ではさまざまな処理が 行われます。共有管理で行われる可能性のあるすべての処理を示すため、特に複雑な操作を選択しましたが、 このほかにも、グループおよびデータの一般的な更新などで同様の影響が生じる可能性があります。 階層内の別のブランチへのロールの移動 ロール全体を移動する利点の 1 つとして、どのポータル取引先も親ロールと一緒に移動するため、関連す る共有を Salesforce で変更する必要がないという点があります。一方、移動するロールに含まれるすべての ユーザと、そのユーザのすべてのデータについては、Wendy の移動に関連する残りの作業をすべてSalesforce で行う必要があります。 ポータル取引先の所有者の変更 この操作は、[取引先所有者] 項目のユーザ名を変更するという単純なデータ更新のように見えますが、か なり多くの作業を必要とします。前の例と同様に所有者が異なるロールに存在する場合、Salesforce では、 単にポータルロールを新しい親ロールに移動するだけでなく、この取引先に関連付けられているポータル ロールの親を変更し、ポータル取引先に関連付けられているすべてのデータの共有を調整します。 18 レコードアクセス権に関連して Salesforce 内部で実行さ れる処理 まとめ まとめ このドキュメントの簡単な例やシナリオでは、堅牢なレコードアクセスメカニズムをサポートするために Salesforce内部で行われる複雑なデータ処理および計算の一端を垣間見ることができます。大規模な組織では取 引先レコード数が 10,000,000、ユーザ数が 7,000、ロール数が 2,000、テリトリー数が 1,000 を超えることが多く、 この場合、大幅に複雑性が増します。このような組織のレコードアクセスモデルを設計する場合、これらの基 本事項を踏まえておくことで、組織のビジネスニーズに合った最も効率的なSalesforce実装を設計できるように なります。 組織のSalesforceレコードアクセス権の拡張に関するベストプラクティスについての詳細は、「企業の規模に応 じたレコードアクセス権の作成」を参照してください。 メモ: このドキュメントに関するご意見は、[email protected] までメールでご送信ください。 19
© Copyright 2024 ExpyDoc
