レコードアクセス権に関連して Salesforce 内部で実行される処理

Size: px

Start display at page:

Download "レコードアクセス権に関連して Salesforce 内部で実行される処理"

ちえこかに
5 years ago
Views:

1 レコードアクセス権に関連して Salesforce 内部で実行される処理 Salesforce, Winter 最終更新日 : 2015/11/3

3 目次レコードアクセス権に関連して Salesforce 内部で実行される処理このドキュメントについて Salesforce のデータアクセスレコードアクセス権の計算アクセス権の付与データベースアーキテクチャ共有行 Group Maintenance テーブルサンプルシナリオすべてを総合まとめ

5 このドキュメントについて Salesforce のアーキテクトであればデータセキュリティの包括的目標が組織のエンタープライズセキュリティモデルを理解し各自の Salesforce 組織でそのモデルを反映するデータアクセスモデルを構築することであることをご存じのことと思います Salesforce ではこうしたデータアクセスを管理するための豊富なツールセットを自由に使用できますが 1 つのレベルのみでデータアクセスを管理するわけではありませんアクセスをいつどのように制御するかをオブジェクトレコード項目の各レベルで慎重に検討する必要がありますこのドキュメントでは各レベルのデータアクセスと内部で実行されるレコードレベルのアクセス権のテーブルレベルビューについて概説しますレコードアクセス権に関連して内部で実行される処理を読むと適切な時点で適切なユーザに適切なレコードへの適切なアクセス権を可能な限り早いタイミングで確信をもって付与できるようになります対象利用者このドキュメントは Salesforce 実装で複雑なレコードアクセス要件や大規模なセールス組織の再配置に対応するエキスパートアーキテクトを対象としています前提条件また読者に Salesforce の管理とセキュリティ SQL およびリレーショナルデータベースの概念についての専門知識があることを前提としています Salesforce のデータアクセス自社のセキュリティ上のニーズを満たすためにはユーザにとってそして開発者自身にとってデータアクセスが何を意味するのかを理解しておくことが重要ですデータアクセス : ユーザの観点ユーザの立場ではレコードにどのようにアクセスしているのかを知ることは必ずしも重要ではありませんが組織のコンテキスト内でアクセス権を持つことの意味を理解しておくことが推奨されます次のグラフには Salesforce で構成可能な各種のアクセス権がわかりやすく図示されています 1

Salesforce のデータアクセスたとえばユーザに取引先項目へのアクセス権があれば取引先項目と取引先オブジェクト自体のどちらにもアクセスできますただし共有ルールその他のツールによって追加のアクセス制御が適用されている場合は取引先 A など特定の取引先レコードにアクセスできなくなりますデータアクセス : アーキテクトの観点アーキテクトはユーザの観点を理解すると同時に

6 Salesforce のデータアクセスたとえばユーザに取引先項目へのアクセス権があれば取引先項目と取引先オブジェクト自体のどちらにもアクセスできますただし共有ルールその他のツールによって追加のアクセス制御が適用されている場合は取引先 A など特定の取引先レコードにアクセスできなくなりますデータアクセス : アーキテクトの観点アーキテクトはユーザの観点を理解すると同時にユーザがアクセスする必要のあるデータのみへの適切なアクセスレベルを付与する方法を把握しておく必要がありますアーキテクトの観点からみると Salesforce のデータアクセスはオブジェクトレベルのアクセス権 ( 項目レベルのアクセス権を含む ) とレコードレベルのアクセス権に大別されますオブジェクトレベルのアクセス権はユーザが特定のオブジェクトにアクセスできるかどうかそのオブジェクトのどの項目を表示できるかどのアクションを実行できるかを決定しますオブジェクトレベルのアクセス権はユーザプロファイルで設定しますアクセスの制限参照作成編集および削除のオブジェクト権限はユーザがアクセス権を持つオブジェクトのレコードでどのアクションを実行できるかを決定します項目レベルセキュリティでは特定のユーザに対して表示されるレコードに含まれる部外秘または機密の情報を非表示にすることができますアクセス権の開放すべての参照およびすべての編集オブジェクト権限を使用するとユーザがレコードレベルのアクセス権に関係なくオブジェクトの全レコードにアクセスできます 2

7 レコードアクセス権の計算レコードレベルのアクセス権 (Salesforce では共有という ) は次のツールを使用してユーザが特定のオブジェクトのどのレコードを表示できるかを決定します組織の共有設定ロール階層テリトリー階層共有ルールチーム共有の直接設定プログラムによる共有レコードレベルのアクセス権の管理にはさまざまなオプションがありさらに一部のオプションは組織的連動関係の影響を受けるためユーザがどのレコードにアクセスできるかの判別がすぐに複雑になってしまう可能性がありますさらにビジネス要件の刷新に応じて共有設定を頻繁に変更している可能性がありますこうした変更によるレコードアクセス権の変更が組織全体に波及する場合があります大規模な組織ではこれらの変更による影響がとりわけ大きく多数のユーザのアクセス権を再計算しアクセス権限を記録するテーブルを調整するために時間がかかる場合がありますこうした理由により Salesforce ではデータベースレベルでアクセス権がどのように計算および付与されるのかを理解しておくことが重要ですレコードアクセス権の計算ユーザがユーザインターフェースまたは API を使用してレコードを開こうとしたりレポートを実行しようとしたりリストビューにアクセスしようとしたりデータを検索しようとしたりするたびに Salesforce によりユーザがアクセスできるレコードを判別するためにレコードアクセス機能の設定がチェックされます特に何百もの階層ノード何千もの共有ルール何百万ものデータ行および顧客やビジネスパートナー用のポータルがある大規模な組織の場合これらの設定が複雑になっている可能性がありますそのような異種データや複雑なリレーションを処理する場合ページを表示するのに 300 ミリ秒 (Salesforce ベンチマーク ) をはるかに超える時間が必要になります Salesforce では各共有ルールの適用すべての階層のトラバースレコードアクセス権の継承の分析をリアルタイムで行うのではなく設定の変更が発生した場合にのみレコードアクセスデータを計算します計算結果は迅速なスキャンを容易にし実行時にアクセスできるレコードを判別するために必要なデータベーステーブル結合数を最小化するような方法で保持されますアクセス権の付与オブジェクトに組織の共有設定として [ 非公開 ] または [ 公開 / 参照のみ ] が設定されている場合 Salesforce ではアクセス権の付与によってユーザまたはグループがそのオブジェクトのレコードにどの程度アクセスできるかを定義します各アクセス付与によって特定のレコードに対するアクセス権が特定のユーザまたはグループに付与されますまたそのアクセス権の付与に使用する共有ツールの種類 ( 共有ルールチームなど ) も記録されます Salesforce では明示的付与グループメンバーシップの付与継承による付与暗黙的付与の 4 種類のアクセス付与を使用します 3

8 アクセス権の付与明示的付与 Salesforce はレコードがユーザまたはグループと直接共有される場合に明示的付与を使用します Salesforce が明示的付与を使用するのは具体的に次の場合ですユーザまたはキューがレコードの所有者になる共有ルールが非公開グループ公開グループキューロールまたはテリトリーとレコードを共有している 1 割り当てルールがユーザまたはキューとレコードを共有しているテリトリー割り当てルールがテリトリーとレコードを共有しているユーザがユーザ非公開グループ公開グループキューロールまたはテリトリーとレコードを手動で共有している 2 ユーザが取引先商談またはケースのチームの一員になるプログラムを使用するカスタマイズでユーザ非公開グループ公開グループキューロールまたはテリトリーとレコードを共有している 3 メモ : 組織に効率的な共有アーキテクチャがない場合大規模な営業の再配置など膨大な権限を明示的に付与する自動化プロセスを使用した場合にパフォーマンス上の問題が発生することがありますグループメンバーシップの付与ユーザ公開グループ非公開グループキューロールまたはテリトリーがレコードへの明示的アクセス権を持つグループのメンバーである場合に行われる付与ですたとえば共有ルールによって Acme レコードへのアクセス権が Strategy というグループに明示的に付与され Bob がそのグループのメンバーである場合 Bob の Strategy グループのメンバーシップによって Acme レコードへのアクセス権が Bob に付与されます継承による付与ユーザ公開グループ非公開グループキューロールまたはテリトリーがロールまたはテリトリー階層に従ってアクセス権を継承するかグループ階層に従ってアクセス権を継承するグループのメンバーである場合に行われる付与です暗黙的付与 Salesforce のセールスサービスおよびポータルのアプリケーション内に組み込まれた設定不可能なレコード共有動作によって特定の親レコードと子レコードへのアクセス権が付与される場合に行われる付与ですたとえば組み込みの共有と呼ばれることもあるこのデフォルトロジックを使用してユーザは親取引先レコードをその子である商談ケースまたは取引先責任者のレコードへのアクセス権を持っている場合に表示できますこれらのユーザが親取引先レコードへのアクセス権を持っている場合その子である商談ケースおよび取引先責任者レコードにもアクセスできます 1 エンタープライズテリトリー管理を使用している場合テリトリー共有グループは共有ルールで使用できません 2 エンタープライズテリトリー管理を使用している場合テリトリー対してレコードの共有を直接設定することはできません 3 エンタープライズテリトリー管理を使用している場合テリトリー共有グループをプログラムで使用できません 4

データベースアーキテクチャデータベースアーキテクチャ Salesforce では 3 種類のテーブルにアクセス権が保存されます Object Record テーブル特定のオブジェクトのレコードが保存されるテーブルで各レコードを所有するユーザグループまたはキューを示します Object Sharing テーブル明示的または暗黙的な権限をサポートするデータが保存されるテーブル

9 データベースアーキテクチャデータベースアーキテクチャ Salesforce では 3 種類のテーブルにアクセス権が保存されます Object Record テーブル特定のオブジェクトのレコードが保存されるテーブルで各レコードを所有するユーザグループまたはキューを示します 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 は結合されたテーブルでクエリ実行ユーザにレコードへのアクセスを許可するアクセス権をクエリします結合するテーブル Object Record と Object Sharing Object Sharing と Group Maintenance Salesforce の一致基準レコード ID ユーザ ID またはグループ ID この図は Salesforce の一致プロセスを順序に従って示しています 5

10 共有行 Salesforce は付加した SQL を含めステートメント全体を満たすレコードのみを返しますステートメントを満たすにはレコードが存在し Object Sharing テーブルまたは Group Maintenance テーブルがクエリ実行ユーザにアクセス権を付与する必要がありますオブジェクト共有テーブルとグループメンテナンステーブルの両方がアクセス権を付与することができますがその方法は大きく異なります Object Sharing テーブルでは単純に各アクセス権が共有行と呼ばれる個別の行に保存され各共有行がユーザまたはグループに特定のレコードへのアクセス権を付与しますグループメンテナンステーブルでは 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

Group Maintenance テーブル Acme の取引先レコードは 1 件のみですが Account Sharing テーブルには Acme レコード用に 2 つのエントリが含まれますこの更新は Salesforce が Acme 取引先レコードへのアクセス権を 2 回 ( 所有者として Maria に 1 回 Frank に 1 回 ) 付与したために発生します例 3

Salesforce はレコードアクセス権を判定するときに最も権限の高い権限を使用しますたとえば Frank が Strategy グループに参加した場合 Frank には例 2 で Maria から付与された参照更新アクセス権もあります複数のユーザのレコードアクセス要件が同じ場合それらのユーザをグループにして個人ではなくそのグループにアクセス権を付与すると効率的です

11 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 が作成されます 7

Group Maintenance テーブルグループ Role 構成次のいずれかに割り当てられるユーザ特定のロールいずれかのマネージャロール目的マネージャに部下のレコードへのアクセス権を付与するために使用する RoleAndSubordinates 次のいずれかに割り当てられるユーザ特定のロールいずれかのマネージャロールいずれかの下位ロール

12 Group Maintenance テーブルグループ Role 構成次のいずれかに割り当てられるユーザ特定のロールいずれかのマネージャロール目的マネージャに部下のレコードへのアクセス権を付与するために使用する RoleAndSubordinates 次のいずれかに割り当てられるユーザ特定のロールいずれかのマネージャロールいずれかの下位ロール次のロールで一連のレコードを共有するルールを組織で定義する場合に使用する特定のロール下位ロール RoleAndInternalSubordinates 次のいずれかに割り当てられるユーザ特定のロールいずれかのマネージャロールいずれかの下位ロール ( ポータルロールを除く ) 次のロールで一連のレコードを共有するルールを組織で定義する場合に使用する特定のロール下位ロール ( ポータルロールを除く ) 3 つの種類のどのグループにも次のメンバーが含まれますグループの直接メンバーからレコードアクセス権を継承しマネージャロールに割り当てられる間接メンバーグループの種別に応じて定義される直接メンバー Role グループの場合直接メンバーはグループが表すロールに割り当てられるメンバーです RoleAndSubordinates グループの場合直接メンバーはグループが表すロールまたはいずれかの下位ロールに割り当てられるメンバーです RoleAndInternalSubordinates グループの場合直接メンバーはグループが表すロールまたはポータルを除くいずれかの下位ロールに割り当てられるメンバーです次の簡単なロール階層を例に考えてみましょう 8

Group Maintenance テーブルこの階層で確立されるレコードアクセス権の継承をサポートするために Salesforce は次の Role グループと RoleAndSubordinates グループ ( 合計 8 個のグループ ) を定義します Salesforce は Role グループをスキャンすることで

13 Group Maintenance テーブルこの階層で確立されるレコードアクセス権の継承をサポートするために Salesforce は次の Role グループと RoleAndSubordinates グループ ( 合計 8 個のグループ ) を定義します 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 がさまざまなレコードアクセス権の変更に従って Object Sharing テーブルと Group Maintenance

14 サンプルシナリオいるシステム定義グループが再適用されますそのため組織のキューや階層のサイズおよび複雑さはレコードアクセス権の計算時間に直接影響しますサンプルシナリオ次のシナリオでは簡略化されたテーブルを使用して Salesforce がさまざまなレコードアクセス権の変更に従って Object Sharing テーブルと Group Maintenance テーブルをどのように再計算しアクセスできるレコードを判別するためにそれらの計算をどのように使用するのかを説明します黄色で強調表示されている部分はサンプルの取引先レコードへのアクセス権を付与するデータを示していますメモ : これらのシナリオでは例に不可欠なデータのみが示されています Salesforce がレコードアクセス権を計算するために使用するすべての項目とテーブルが表示されているわけではありませんこれらのシナリオでは組織全体にわたるデフォルト設定はすべてのオブジェクトに対して非公開でありロール階層とユーザは次のように設定されます Salesforce は次のグループを生成してロール階層によって構築されるレコードアクセス権の継承をサポートします 10

15 サンプルシナリオシナリオ 1 Maria は Acme の取引先レコード (A1) を作成します内部では Salesforce が Account Sharing テーブルに Acme の新しい取引先レコードと所有者として Maria の共有行を作成します 11

16 サンプルシナリオシナリオ 2 Maria は Acme の取引先レコードを Bob と共有するように直接設定します内部では Salesforce が Account Sharing テーブルに Bob の共有行を作成しますレコード共有の直接設定プログラムによるレコード共有の設定およびチーム共有設定の場合いずれも同様に Object Sharing テーブルに共有行が作成されますが共有理由は異なります 12

17 サンプルシナリオシナリオ 3 システム管理者は Sales Executive のレコードを Services Executive ロールとその下位のロールに含まれるユーザと共有する共有ルールを作成します内部では Salesforce が Services Executive ロールの RoleAndSubordinates グループの Account Sharing テーブルに共有行を作成し Frank と Sam に Acme レコードへのアクセス権を与えます 13

サンプルシナリオシナリオ 4 Maria は Acme のレコードの所有者を Wendy に変更しますレコードの所有者が変わると Salesforce は所有者に関連付けられ共有理由が直接設定となっている共有行を削除するため Bob はそのレコードへのアクセス権を失いますまた Sales Executive である Maria はレコードを所有しなくなるためシナリオ 3

18 サンプルシナリオシナリオ 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 プラットフォームの Object Sharing テーブルおよび Group Maintenance テーブルにどのように記録されるかを確認しましたこれらの例は比較的単純で多くのテーブルでは数行しか変更されませんでしたただし一般的な管理操作では多くの場合

19 すべてを総合すべてを総合このドキュメントのシナリオではユーザのアクセス権が Salesforce プラットフォームの Object Sharing テーブルおよび Group Maintenance テーブルにどのように記録されるかを確認しましたこれらの例は比較的単純で多くのテーブルでは数行しか変更されませんでしたただし一般的な管理操作では多くの場合より膨大な量のアクセス権を再計算する必要があり基盤となるテーブルに多くの更新が加えられます大量のデータおよび複雑なロール階層を使用する組織では特に複雑になりますユーザロールの変更を例に挙げてこれらの操作がどのように関係するかを説明しますこの変更は単純なグループ操作のように思えますが実際には共有の再計算に大幅な影響を与えるものです前述のシナリオと同様に組織全体のすべてのオブジェクトのデフォルト設定は非公開ですロール階層とユーザは次の 2 点を除きほとんど同じです 15

すべてを総合小規模および中規模のビジネスパートナー販売組織で新しいロールが作成されていますすべての Sales データへのアクセス権を Services ブランチに提供する広範囲な共有ルールではなく West Sales Rep ロールのデータへのアクセス権のみを提供する焦点を絞った共有ルールがあります SMB Partner データは Services ブランチと共有しません

20 すべてを総合小規模および中規模のビジネスパートナー販売組織で新しいロールが作成されていますすべての 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

すべてを総合カスタマーポータルまたはパートナーポータルのいずれかに対して有効化された取引先を Wendy が所有する場合は Salesforce で次の処理が実行されますグループメンバーシップに変更を加えるポータルユーザが所有するかポータルユーザと共有する階層内のレコードにアクセス権を付与する共有を調整するポータルが有効化された取引先ごとに取引先所有者のロールの下で 1 ~ 3

21 すべてを総合カスタマーポータルまたはパートナーポータルのいずれかに対して有効化された取引先を Wendy が所有する場合は Salesforce で次の処理が実行されますグループメンバーシップに変更を加えるポータルユーザが所有するかポータルユーザと共有する階層内のレコードにアクセス権を付与する共有を調整するポータルが有効化された取引先ごとに取引先所有者のロールの下で 1 ~ 3 個のロールが主階層に付加されます Wendy が移動すると Salesforce でこれらのポータルロールが Wendy の古いロールから削除され Wendy が所有しポータルが有効化されたすべての取引先の新しいロールに付加されますメモ : Salesforce では Wendy の古いロールに書き込まれた共有 ( 各ポータル取引先のメンバーが所有するかそのメンバーに表示されるレコードへのアクセス権を Wendy および Wendy のすべての上司に付与する共有 ) を削除してそれを新しいロールに追加する必要があります Wendy の新しい割り当てを反映するためソースグループ内の Wendy の古いロールと新しいロールを含めすべての共有ルールが Salesforce で再適用されます 17

すべてを総合特に Wendy のすべてのレコードに対する共有が次の場所から Salesforce によって削除されます階層の Service ブランチにある最上位ロールそのすべての下位ロール Wendy の取引先の共有ルール設定に応じて Wendy の取引先の子レコードに対する共有も Salesforce で削除しなければならない場合がありますメモ : Wendy

22 すべてを総合特に Wendy のすべてのレコードに対する共有が次の場所から Salesforce によって削除されます階層の Service ブランチにある最上位ロールそのすべての下位ロール Wendy の取引先の共有ルール設定に応じて Wendy の取引先の子レコードに対する共有も Salesforce で削除しなければならない場合がありますメモ : Wendy がポータル取引先を所有しポータルロールをソースグループとして使用する共有ルールが存在する場合これらのルールを Salesforce で再適用しなければならない場合がありますこれらのルールは階層内の Wendy の新しい場所では無効になる可能性がありますその場合はシステム管理者がルールを変更または削除する必要がありますこれらの変更に加えブランチで Wendy の古いロールの上位にいるマネージャは Wendy が所有するすべてのデータおよびロール設定を使用して共有される子レコードにアクセスできなくなりますこの処理は階層内での通常の継承操作の一部でありグループメンバーシップまたは共有テーブルを更新する必要はありませんシステム管理者がユーザのロールを変更するという単純に見えるアクションでも内部ではさまざまな処理が行われます共有管理で行われる可能性のあるすべての処理を示すため特に複雑な操作を選択しましたがこのほかにもグループおよびデータの一般的な更新などで同様の影響が生じる可能性があります階層内の別のブランチへのロールの移動ロール全体を移動する利点の 1 つとしてどのポータル取引先も親ロールと一緒に移動するため関連する共有を Salesforce で変更する必要がないという点があります一方移動するロールに含まれるすべてのユーザとそのユーザのすべてのデータについては Wendy の移動に関連する残りの作業をすべて Salesforce で行う必要がありますポータル取引先の所有者の変更この操作は [ 取引先所有者 ] 項目のユーザ名を変更するという単純なデータ更新のように見えますがかなり多くの作業を必要とします前の例と同様に所有者が異なるロールに存在する場合 Salesforce では単にポータルロールを新しい親ロールに移動するだけでなくこの取引先に関連付けられているポータルロールの親を変更しポータル取引先に関連付けられているすべてのデータの共有を調整します 18

23 まとめまとめこのドキュメントの簡単な例やシナリオでは堅牢なレコードアクセスメカニズムをサポートするために Salesforce 内部で行われる複雑なデータ処理および計算の一端を垣間見ることができます大規模な組織では取引先レコード数が 10,000,000 ユーザ数が 7,000 ロール数が 2,000 テリトリー数が 1,000 を超えることが多くこの場合大幅に複雑性が増しますこのような組織のレコードアクセスモデルを設計する場合これらの基本事項を踏まえておくことで組織のビジネスニーズに合った最も効率的な Salesforce 実装を設計できるようになります組織の Salesforce レコードアクセス権の拡張に関するベストプラクティスについての詳細は企業の規模に応じたレコードアクセス権の作成を参照してくださいメモ : このドキュメントに関するご意見は ccefeedback@salesforce.com までメールでご送信ください 19

rakumoソーシャルスケジューラー【管理者用マニュアル】ver

rakumoソーシャルスケジューラー【管理者用マニュアル】ver 2016.3.17 ソーシャルエンタープライズアプリケーション管理者 rakumo ソーシャルスケジューラーマニュアル Ver. 1.18.0 対応お申し込みお問い合わせ rakumo サポート 9:00~18:00( / / 祝除く ) 03-4582-6074 support-sfdc@rakumo.com https://rakumo.com /rakumo-support/inquiry/