制限ルールのユースケースと考慮事項

By | June 9, 2023
0 Comment

前提

「制限ルール」の基本的な仕様や設定方法については既に読者が把握しているものとする。

制限ルールの適用対象

  • カスタムオブジェクト
  • 外部オブジェクト（※OData 2.0・OData 4.0・組織間アダプタを利用した外部オブジェクトではサポートされる一方、カスタムアダプタを利用した外部オブジェクトはサポートされない）
  • 契約
  • ToDo
  • 行動

制限ルールの適用対象

  • リストビュー
  • ルックアップ
  • 関連リスト
  • レポート
  • 検索
  • SOQL
  • SOSL

制限ルールの利用を可能な限り避けるべき理由

アクセス権制御の柔軟性の喪失：ユーザは、制限ルールで定義したルールに合致しないレコードへのアクセス権を消失する。この制約はあらゆるレコード権限付与の手法に対しても優先される。つまり、既存の制限ルールそのものを見直さない限り、制限ルールでの定義に合致しないレコードに対してアクセス権を付与することが不可能となってしまう。

パフォーマンス低下：下で確認する通り、レコードデータ取得時に制限ルール計算のオーバーヘッドが発生するようになる。

https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5

制限ルールのユースケース

可能な限り利用を避けたい制限ルールのユースケースとは、要するに制限ルール以外にレコード表示制御の手段が存在しない場合である。

その具体的なパターンとしては以下を挙げることができる。

  • ShareObjectを持たないオブジェクト（Task, Event）
  • 外部ユーザへの「共有ルール」ベースでのアクセス権付与に対するフィルタ追加
  • 外部オブジェクト

公式ヘルプ記事のシナリオ例では、真ん中のパターン（共有ルール経由でアクセス権を付与せざるを得なかったレコードからアクセス権を剥奪したいパターン）が紹介されていないが、実務上はこのパターンの利用率が全体の99%を占める（※筆者の主観）

制限ルールの実行タイミングとパフォーマンスにおける考慮事項

制限ルールはPostgreSQL内のShare Object TableやGroup Maintenance Tableに対するSQLクエリのフィルタ条件になるわけではない。

つまり、クエリパフォーマンスの観点では、制限ルールの設定をすると必ずパフォーマンスが低下する。

とりわけLDVで制限ルールを利用した場合「3〜5%のオーバヘッド」が発生することがヘルプ記事内で明記されている（以下引用画像を参照）

また制限ルールの条件に利用している項目については、インデックスが付いた状態にすることが望ましい。

https://help.salesforce.com/s/articleView?id=sf.security_restriction_rule_considerations.htm&type=5

その他の考慮事項

Classic環境で動作しない（※詳細はこちらのヘルプ記事を参照）

参考

Salesforce Help – 制限ルール