見えてはいけないレコードがユーザーに見える ― 原因の特定法

なぜこの人にあのレコードが見えるのか? は、Salesforceで最もよく寄せられるアクセスに関する疑問であり、目視で答えるのが最も難しい問いでもあります。なぜなら、プラットフォームは可視性を1か所で決めることが決してないからです。複数の仕組みの和集合を付与するのです。本ガイドでは、アクセスを開いた仕組みを突き止めるための、再現可能な手順を示します。

まずはメンタルモデルから

Salesforceの共有は加算的で、最も寛容なものが勝つ仕組みです。アクセスを許可するルールと、それをブロックするルールの両方を探しているわけではありません。探しているのはたった1つの付与です。1つあれば十分だからです。(階層構造の全体像については、Salesforceで誰がレコードを見られるかを参照してください。)

たとえ1つの仕組みでもアクセスを付与していれば、そのユーザーはアクセスを持ちます。あなたの仕事は、それがどれなのかを見つけることです。

ステップ1 ― 「共有」ボタンを読む

レコード上で共有をクリックします(組織の共有設定が完全な公開ではないオブジェクトで利用できます)。一覧には、アクセスを持つユーザーと理由列が表示されます ― 所有者、ロール階層、共有ルール、手動共有、チームなど。たいていの場合、これだけで犯人がすぐに分かります。

そのユーザーが一覧にすら載っていないのにレコードが見えている場合は、プロファイルレベルでの迂回を疑ってください ― ステップ2へ進みます。

ステップ2 ― 権限レベルの迂回を除外する

これらは共有モデルを完全に無視します。

すべてのデータの参照 / すべてのデータの編集(システム権限。たとえばシステム管理者プロファイルに付与されています)。
そのオブジェクト固有の、オブジェクトレベルのすべて表示 / すべて変更。

ユーザーがプロファイルや権限セットを通じてこれらのいずれかを持っている場合、共有設定を変更してもレコードは隠せません。その権限を削除する必要があります。プロファイルと、割り当てられているすべての権限セットを確認してください。

ステップ3 ― 共有のレイヤーを上から下へたどる

それが本当に共有による付与であるなら、どのレイヤーかを特定します。

組織の共有設定が開放的すぎる

オブジェクトのOWDが「公開/参照のみ」または「公開/参照・更新可能」の場合、オブジェクトへのアクセスを持つ全員がすべてのレコードを見られます。修正は構造的なもの ― 組織の共有設定を厳しくし、アクセスを意図的に再付与することになります。

ロール階層によってアクセスが上位へ巻き上がる

ユーザーがロール階層上でレコード所有者の上位にいて、「階層を使用したアクセス許可」がオンになっている場合、そのユーザーは所有者のアクセスを自動的に継承します。これは最もよくある意外な原因です。

範囲が広すぎる共有ルール

Region = EMEA → ロールXに共有 のような条件ベースのルールは、特にデータやロールの変更後には、意図よりもはるかに多くの人を含んでしまうことがあります。対象ユーザーのロール、公開グループ、テリトリーを対象とするルールを見直してください。

手動共有または暗黙の共有

手動共有: 誰かがレコードの共有ボタンを使った場合です。
暗黙の共有: 親の取引先へのアクセスが、その子の各ケースや取引先責任者に対して限定的な参照アクセスを付与します。これは常に見落とされがちで ― そして必ず参照のみです。
Apex管理共有: カスタムコードが共有を作成した場合です。「共有」ボタンには表示されますが、その出所はコードの中にあります。

チームとテリトリー

取引先/商談/ケースのチームメンバーシップや、エンタープライズテリトリー管理の下で一致するテリトリーは、それぞれ独立してアクセスを付与します。

ステップ4 ― 再計算の遅延でないことを確認する

アクセスが一貫しないように見える場合、最近の所有権・ロール・ルールの変更後に共有の再計算が完了するのを目にしているだけかもしれません。バグだと宣言する前に、完了を待ちましょう。

診断チェックリスト

「共有」ボタン → そのユーザーの理由を読む。
プロファイル + 権限セット → すべて表示 / すべて変更はないか?
このオブジェクトのOWDが開放的すぎないか?
ユーザーはロール階層上で所有者より上位にいないか?
対象ユーザーを含む共有ルール(特に条件ベース)はないか?
手動、暗黙、またはApexによる共有はないか?
チームメンバー、または一致するテリトリーはないか?
最近の変更 → 再計算を待つ。

最初に出た「はい」があなたの答えです ― そして、同じアクセスを付与する経路が複数存在することもあります。逆の問題、つまり本来見えるべきレコードが見えないユーザーについては、アクセス不足の診断チェックリストを参照してください。

半日がかりの作業を数秒で

ユーザーとレコードの組み合わせごとに、プロファイル、権限セット、6つの共有メカニズムにまたがる8つのレイヤーをたどる作業 ― これこそ、本当の露出を覆い隠してしまう手作業の繰り返しです。AgentForceAccessがあなたの代わりにそれを行います。なぜそのユーザーにレコードが見えるのかを平易な言葉で尋ねれば、すべてのレイヤーをたどり、正確な付与元を示します ― だから、あなたは一直線に修正へ進めるのです。

よくある質問

最初に行うべき最速のチェックは何ですか?

レコードを開き、「共有」ボタンをクリックして、対象ユーザーの「理由」列を読みます。ほとんどの標準オブジェクトでは、アクセスを付与している仕組み ― 所有者、ロール階層、共有ルール、手動共有など ― がそこに示されます。あわせて、そのユーザーが単に「すべてのデータの参照」やオブジェクトレベルの「すべて表示」を持っていないことも確認してください。

「共有」ボタンに「ロール階層」と表示されています ― どうすればよいですか?

ロール階層上でそのユーザーより下位にいる誰かがレコードを所有している(または共有されている)うえ、そのオブジェクトで「階層を使用したアクセス許可」が有効になっています。このアクセスを取り除くには、階層を変更するか、所有権を変更するか、カスタムオブジェクトであれば階層によるアクセスを無効化することになります ― いずれも安易に行うべきではありません。

共有ではなく、プロファイルの権限が原因という可能性はありますか?

あります。「すべてのデータの参照」/「すべてのデータの編集」やオブジェクトレベルの「すべて表示」/「すべて変更」は、共有モデルを完全に迂回します。ユーザーがこれらのいずれかを持っている場合、共有設定をいくら変更してもレコードは隠せません ― 代わりにその権限を削除する必要があります。

なぜアクセスが断続的に現れたり消えたりするのですか?

共有の再計算です。所有権の変更、ロールの移動、ルールの編集の後、Salesforceは共有を非同期で再処理します。その間はアクセスが一貫しないように見えることがあります。設定上のバグだと結論づける前に、再計算が完了するのを待ってください。