【Salesforce】ロール階層を変えたら見えるレコードが変わる時の注意点

Salesforceを運用していると、組織再編や担当者変更に伴い、ロール階層を修正する場面があります。しかし、ロール階層を変更した直後から、特定のユーザーが本来見えるべきレコードを見られなくなったり、逆に不要なレコードが見えるようになるトラブルが発生することがあります。このような現象は、Salesforceの共有モデルがロール階層に依存しているために起こります。本記事では、ロール階層変更によってレコードの可視性が変化するメカニズムを解説し、具体的な確認手順や注意点を整理します。

ロール階層とレコード可視性の関係

Salesforceでは、標準の共有モデルにおいて、組織の共有設定とロール階層が組み合わさってレコードの可視性が決まります。ロール階層は、ユーザーを組織図のように上下関係で配置したもので、上位のロールに属するユーザーは下位ロールのユーザーが所有するレコードを、共有設定の条件に応じて参照できるようになります。

例えば、営業部のマネージャーロールが営業メンバーロールの上位にある場合、マネージャーは自動的にメンバーが作成した商談や取引先責任者などのレコードを閲覧できます。ただし、この自動的な参照は、組織の共有設定で「参照のみ」または「参照・更新可能」が選択されているオブジェクトに限られます。また、ロール階層を完全に無効化することも可能です。

ロール階層を変更すると、上下関係が変わるため、それまで見えていたレコードが見えなくなったり、新たに見えるようになったりします。この変化は、変更が保存された直後に反映されます

階層の上下とレコード所有権の関係

レコードの可視性は、基本的に「自分が所有するレコード」「ロール階層の下位ユーザーが所有するレコード」「共有ルールや手動共有で共有されたレコード」の3つに分類されます。ロール階層を変えると、下位ユーザーが誰になるかが変わります。例えば、それまで同じ階層にいた複数のロールを一方の下位に移動すると、移動先の上位ロールのユーザーは、移動元のロールに所属するユーザーのレコードを見られるようになる一方、移動元の上位ロールのユーザーはそのレコードを見られなくなる可能性があります。

ロール階層変更後に発生しやすいトラブルとその原因

実際の現場でよくあるトラブルを3つ紹介します。いずれもロール階層の変更がトリガーとなっています。

トラブル現象	考えられる原因	確認すべきポイント
マネージャーが部下の商談を見られなくなった	ロール階層でマネージャーロールが部下のロールの上位でなくなった、または組織の共有設定でロール階層が無効になっている	ロール階層の編成、共有設定の「ロール階層によるアクセス」が有効か
別部署のレコードが突然見えるようになった	ロール階層変更で他部署が自分のロールの下位に移動した	ロール階層のツリー表示でどのロールが下位になったか確認
特定のレコードだけ見られない(一部のレコードのみ)	手動共有や共有ルールが存在する、またはレコード所有者が変更前と変わった	レコードの共有状況、共有ルールの条件を確認

ロール階層変更前後で可視性を確認する手順

トラブルを防ぐためには、変更前に現状の可視性を記録し、変更後に影響範囲を確認するプロセスが重要です。以下に推奨する手順をまとめました。

1. 変更前のロール階層とユーザー割り当てをエクスポートする。 Salesforceの設定画面から「ユーザー」→「ロール」を開き、階層ツリーをスクリーンショットで保存します。また、各ロールに属するユーザーリストもCSVで書き出しておきます。
2. 組織の共有設定を確認する。 「設定」→「共有設定」で、主要なオブジェクト(取引先、商談、ケースなど)が「参照のみ」か「参照・更新可能」か、またロール階層によるアクセスが有効かを確認します。
3. 影響を受けるユーザーを特定する。 変更予定のロールの上位・下位にいるユーザーをリストアップし、そのユーザーが普段見ているレコードのサンプルを事前に取得します。例えば、特定の商談レコードの「共有」ボタンから、どのユーザーにアクセス権があるかを確認できます。共有ボタンはレコード詳細画面にあります。
4. テスト環境でロール階層を変更する。 可能であればSandboxなどのテスト環境で同じ変更を行い、影響を検証します。本番環境で直接変更する場合は、影響が大きいと予想される時間外に実施します。
5. 変更後に可視性を再確認する。 影響を受けるユーザーでログインし、レコード一覧や詳細画面で見え方が変わっていないかチェックします。特に、事前に記録したサンプルレコードのアクセス権を再確認します。
6. 共有ルールに問題がないか確認する。 ロール階層変更後、既存の共有ルールがまだ有効か、条件に合致しているかを確認します。ロールが削除された場合、そのロールを参照している共有ルールは無効になることがあります。

ロール階層変更でよくある失敗パターン

失敗パターン1:ロール階層の上位に誤って配置する

新しいロールを作成して既存のロールの上位に置くと、その上位ロールのユーザーが今まで見えなかった大量のレコードにアクセスできるようになります。これにより、本来見せるべきでない機密データが表示されるリスクがあります。例えば、本来は部門ごとに分離すべきデータが、階層変更で上位ロールに統合されてしまいます。対応として、共有ルールや組織の共有設定で必要な制限をかける必要があります。

失敗パターン2:ロール階層をフラットに変更したら情報が遮断された

ロール階層をフラット(階層なし)に変更すると、マネージャーが部下のレコードを自動的に見られなくなります。この場合、共有ルールで明示的にアクセス権を付与しない限り、階層によるアクセスは失われます。組織の共有設定でロール階層を無効にした場合も同様です。事前に共有ルールの整備が必要です。

失敗パターン3:ロールを削除したら既存の共有ルールがエラーになる

共有ルールで特定のロールを参照している場合、そのロールを削除すると共有ルールは無効になります。しかし、Salesforceは削除時に警告を出さないことがあるため、気づかずにデータアクセスが失われることがあります。削除前に、共有ルールやキュー、割り当てルールなどでそのロールが使用されていないか確認します。

管理者に伝えるべき情報と確認依頼のポイント

一般ユーザーがロール階層の変更を行うことはほとんどありませんが、システム管理者に変更を依頼する場合に以下の情報を伝えるとスムーズです。

• 変更したいロールの新旧の位置関係: どのロールをどのロールの上位/下位に移動したいのか、具体名を挙げます。
• 変更理由と期待する可視性: 例えば「営業部マネージャーが新しいチームの商談も見られるようにしたい」など、目的を明確にします。
• 影響を受けるユーザー名: 変更の前後でアクセス権が変わる可能性のあるユーザーをピックアップします。
• テスト環境の有無: Sandboxがある場合はそちらで先にテストしてほしいと依頼します。
• 期限: いつまでに変更が必要か伝えます。

管理者は変更後に、組織の共有設定、共有ルール、プロファイルのオブジェクト権限などを総合的にチェックする必要があります。

よくある質問(FAQ)

Q1. ロール階層を変更したら、すぐに反映されますか?
はい、変更を保存した直後にユーザーのアクセス権に反映されます。バッチ処理や待ち時間はありません。

Q2. ロール階層を変更しても、手動共有で付与されたアクセス権は維持されますか?
手動共有はロール階層とは独立しているため、維持されます。ただし、手動共有の期限や共有元のレコード所有者が変わった場合は影響を受けます。

Q3. ロール階層の変更を取り消したい場合、どうすればいいですか?
変更前の状態にロール階層を戻すことで復元できますが、変更履歴はSalesforceの設定監査証跡に記録されます。大規模な変更の場合は、Sandboxで事前にテストすることを推奨します。

Q4. ロール階層を無効にした場合、すべてのレコードが見えなくなりますか?
ロール階層による自動アクセスがなくなるだけで、手動共有や共有ルール、グループ、公開グループなどでアクセス権を付与したレコードは引き続き見えます。組織の共有設定で「公開/参照のみ」に設定されていれば、全ユーザーが見えることもあります。

まとめ

Salesforceのロール階層を変更すると、レコードの可視性が広範囲に影響を受けるため、変更前後の確認が欠かせません。特に、共有設定や共有ルールとの兼ね合いを理解していないと、意図しないデータ漏洩やアクセス権喪失につながります。変更は必ずテスト環境で検証し、影響範囲を事前に洗い出した上で本番環境に適用しましょう。管理者へ依頼する際は、変更内容と目的を具体的に伝え、変更後はユーザーに新しいアクセス権を周知することも重要です。日頃からロール階層と共有設定の関係をドキュメント化しておくことで、組織変更にも迅速に対応できます。