Salesforceのレコード共有モデルを図解：組織の共有設定・ロール階層・共有ルール・手動共有

このページには広告リンクを含みます。

レコード共有の全体像：閉じてから開く

Salesforce のデータの守りは、組織、オブジェクト、項目、レコードの層に分かれています。この記事で扱うのはレコードの層、つまり「他の人が持っているレコードが見えるか」です。

先に押さえたい前提が2つあります。

1つ目は、オブジェクト権限が先に効くことです。商談の参照権限がないユーザーは、共有をどう設定しても商談を開けません。組織の共有設定はオブジェクト権限を超えるアクセスを与えません。権限の設計はプロファイルと権限セットの使い分けで扱います。

2つ目は、共有の仕組みは基本的に「足し算」であることです。組織の共有設定が土台で、その上に重ねる仕組みはアクセスを増やすだけです。部長だけ見えないようにする、という引き算はできません。

組織の共有設定（OWD）：最も制限される人に合わせる

組織の共有設定（Organization-Wide Defaults、OWD）は、自分が所有していないレコードへの基準のアクセスを決めます。オブジェクトごとに、また社内ユーザーと社外ユーザーで別々に設定します。

決め方は Trailhead の3つの問いで整理できます。

1. このオブジェクトで、最も制限される利用者は誰か
2. その人に見せてはいけないレコードはあるか。あれば非公開
3. その人に編集させてはいけないレコードはあるか。あれば公開/参照のみ

ありがちな失敗は、一番多く見る人に合わせて決めることです。営業全員が見たいから公開にすると、後から「派遣社員には見せないで」と言われても共有では閉じられません。土台は開けるより閉じる方が後の調整が楽です。なお、設定を変えると共有の再計算が走り、データ量によっては長い時間がかかります。

親レコードに連動は、主従関係の子のオブジェクトで使う設定です。詳しくは主従関係と参照関係の違いを読んでください。

ロール階層：縦に開く

ロール階層は、階層の上にいるユーザーが、下のユーザーのレコードにアクセスできるようにする仕組みです。課長のロールを営業担当のロールの上に置けば、課長は部下の商談を見られます。

ロールは組織図と同じである必要はありません。Trailhead は、ロールを「必要なデータアクセスの水準」と説明しています。役職が違っても見る範囲が同じなら、1つのロールにまとめられます。Architect の資料は、階層の深さを10段以内に抑えることをすすめています。

カスタムオブジェクトでは、階層を使用したアクセス許可（Grant Access Using Hierarchies）を外すと、上司へ自動で開かなくなります。外せるのは親レコードに連動ではないカスタムオブジェクトだけです。人事評価のように、上司にも見せたくないデータで検討します。

共有ルール：横に開く

共有ルールは、部署をまたいで決まった相手にレコードを開く仕組みです。ロール階層では届かない、横の関係に使います。

種類は2つです。所有者ベースは「大阪支店のメンバーが持つ商談を東京支店へ」のように、持ち主で決めます。条件ベースは「フェーズが受注の商談を経理へ」のように、項目の値で決めます。共有先はユーザーのロール、ロールと下位ロール、テリトリー、公開グループなどで、アクセスは参照のみか参照・更新を選びます。

条件ベースのルールは合計にも数えられます。オブジェクトマネージャーの Object Limits で現在の数を確認できます。上限は変わることがあるので、作る前に確かめてください。

Trailhead は、複数のロールやグループにまたがるなら公開グループを作ることをすすめています。逆に、面接官のようにレコードごとに顔ぶれが変わる相手には共有ルールは向きません。その場合は次の手動共有やチームを検討します。

手動共有とチーム：例外を1件ずつ開く

手動共有（Manual Sharing、画面やヘルプの表示は「共有の直接設定」）は、特定のレコードを特定のユーザー、公開グループ、ロールに開く仕組みです。実行できるのは、所有者、階層で所有者より上のユーザー、対象オブジェクトの「すべてのレコードの編集」（Modify All Records）を持つユーザー、管理者です。

注意点は所有者の変更です。既定では、所有者が変わると手動共有は削除され、見えていた人が急に見えなくなります。[レコードの移行時に共有の直接設定を保持]（Keep manual shares when transferring records）という組織の設定で動作を変えられます。異動の時期に問い合わせが増える原因になりやすいところです。

取引先、商談、ケースには、チームという別の開き方もあります。1レコードに1チームを持ち、メンバーに参照のみ、または参照・更新を与えます。担当者が案件ごとに変わるなら、手動共有よりチームの方が管理しやすくなります。

共有で見落としやすい例外

設定どおりなのに見える、という相談では次を確かめます。

• すべてのレコードの参照、すべてのレコードの編集（View All Records / Modify All Records）：対象オブジェクトの共有設定を無視します。「すべてのデータの参照」「すべてのデータの編集」（View All Data / Modify All Data）は全オブジェクトに効きます。項目レベルセキュリティは無視しません。
• 暗黙の共有：商談が見えるユーザーは親の取引先も見える、といった自動の共有です。無効にできません。カスタムオブジェクトには適用されません。
• 制限ルール（Restriction Rules）：共有とは逆に、与えたアクセスを条件で絞る仕組みです。使えるのはカスタムオブジェクト、外部オブジェクト、契約、行動、ToDo、タイムシート、タイムシート項目です。有効なルールの数は1オブジェクトあたり、Enterprise と Developer で2つ、Performance と Unlimited で5つまでです。

また、所有者1人に大量のレコードが集まると、共有の再計算が重くなります。Architect の資料は、所有者とレコードの比を1対1万に抑えることをすすめています。連携用のユーザーに全レコードを持たせる設計では特に確かめてください。

依頼から設計する

設計の順番をもう一度まとめます。

1. オブジェクトごとに、最も制限される利用者を決める
2. 組織の共有設定を決める
3. 上司へ開く必要があるか確かめ、ロール階層を作る
4. 部署をまたぐ要件を、所有者ベースと条件ベースの共有ルールに分ける
5. 残った例外を手動共有かチームにする

設定を変えた後は、最も制限される立場のユーザーで見え方を確かめてください。

共有の考え方は認定アドミニストレーターの学習でも中心になる内容です。学習の順序は認定アドミニストレーターの勉強法にまとめています。Salesforce の基本から確かめたい人は基本ガイドに戻ってください。