JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 19, 2026 · 17 min read

SAP SF 権限グループ

Permission Group（権限グループ）は、SuccessFactorsユーザーの再利用可能な母集団を定義するマスタデータオブジェクトであり、ライブのルールベース条件または手動選択による固定リストのいずれかから構築され、ロールベース権限（RBP）フレームワーク全体で使用されます。これはフェーズ2（権限とシステム設定）で最初に設定されるオブジェクトです。フェーズ1の法人からポジションまでのチェーンが誰がどこで働くかを確立するのに対し、Permission Groupは誰が何を表示または変更できるかを確立し、すべてのPermission Roleがその許可対象母集団またはターゲット母集団としてバインドする母集団を提供します。この記事では、Permission Groupの概要、Dynamic/Static/Everyoneのバリアント、同じランドスケープゾーン内で並行するTime Configurationチェーンとの関係、およびAdmin Centerコンサルタントが設定するすべてのフィールドについて説明します。

パート1: 権限グループ — 基本概念（全モジュール共通）#

1.1 権限グループとは#

Permission Group（権限グループ）は、クライアントレベル（テナントレベル）のファンデーションオブジェクトであり、ユーザーの集団に名前を付けるものの、それ自体ではいかなる権限も付与しません。独自のアクセスロジックを持たず、アクセスはすべて Permission Role（権限ロール）側で定義されます。しかし、すべての Permission Role の設定は、誰がロールを受け取るのか、そしてロールがどのデータにアクセスできるのかを伝える Permission Group がなければ意味をなしません。その意味で、Permission Group は、RBP セキュリティモデル全体が構築される基盤となる、アドレス可能な「集団」プリミティブです。

1.2 権限グループタイプ#

権限グループのグループタイプは、そのメンバーシップの計算方法を決定し、誤った設定は単なる見た目の問題ではありません。動的グループが必要な場所で静的グループを使用すると、組織再編や新規採用の追跡が黙って停止されます。一方、過度に広範な動的グループ（または組み込みの「全員」グループ）を機密性の高いロールに割り当てることは、アクセス制御監査で日常的に指摘される事項です。

設計原則: 1つの権限グループ内で動的ロジックと静的ロジックを混在させることはできません。グループごとに1つのグループタイプを選択してください。ルールベースと手動選択の両方のメンバーを本当に必要とする母集団がある場合は、両方のロジックを1つのグループに強制的に組み込むのではなく、権限ロール割当レベルで2つの別々のグループ（1つは動的、もう1つは静的）を組み合わせてください。

1.3 組織レベルとデータ階層#

具体的な例を用いたデータ階層

Permission Groupは、SuccessFactorsマスタデータランドスケープのテナントレベルの「Permission & Time」ゾーンに位置します。このゾーンには、3つの並行かつ独立したクライアントレベルの設定チェーンがバンドルされています（Permission Management、Holiday Calendar → Work Schedule、Time Type → Time Account Type（Time Profileで結合））。本記事の階層は最初のチェーンであり、他の2つは同じランドスケープゾーンに存在しますが、関連記事（SF-A03-03～SF-A03-06）に属しています。

Client (SuccessFactors Instance)
   │
   ├── Permission Group "PG_Manager" — Managers, Direct Reports
   │      │
   │      └── Permission Role "PR_ESS" — Employee Self-Service, of PG_Manager
   │
   ├── Holiday Calendar "HC_JP2024" — Japan 2024, 16 holidays  (Time Configuration chain, see SF-A03-03/04)
   │      │
   │      └── Work Schedule "WS_JP_Std" — JP Standard, 40H/week, of HC_JP2024
   │
   └── Time Type "TT_Annual" — Annual Leave, category  (Time Configuration chain, see SF-A03-05/06)
          │
          └── Time Account Type "TAT_Annual" — 20 days, 5-day carryover, of TT_Annual

Time Profile "TP_JP_Std" — JP Standard, Work Schedule + Time Account Type bundle
   ├── assigned to ──> Work Schedule "WS_JP_Std"
   └── assigned to ──> Time Account Type "TAT_Annual"

必須のランドスケープ検証に関する注意: モジュールMaster.mdのER図は、Permission Group ↔ Permission Roleの関係を「N:M」とラベル付けしています。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンC）は、これを単一の実線の親子コネクタ — PG_Manager → PR_ESS — として描き、ノードサブテキストに「Employee Self-Service · of PG_Manager」と記しています。これは矛盾ではありません。ランドスケープの実線は、1つのPermission Roleインスタンスのデータを代表する来歴チップであり、Permission Groupが正確に1つのPermission Roleを所有するという主張ではありません。実際のSuccessFactors設定では、単一のPermission Groupは、多くの無関係なPermission Role割り当てのGranted-ToまたはTarget Populationとして日常的に参照され、単一のPermission Roleは、異なる割り当て間で異なるPermission Groupを参照できます。これは、まさにMaster.mdのソースが説明する多対多のカーディナリティです。この再利用が実際にどのように機能するかについては、セクション1.4および2.4を参照してください。

設計原則: Permission Group自体にはアクセスロジックが含まれないため、階層内での位置付けは意図的に浅くなっています（クライアントレベル、サブレベルなし）。実際の設定の複雑さはすべて、Permission Roleの割り当てがPermission Groupをどのように組み合わせるか（セクション2.4）にあり、グループオブジェクト自体にはありません。

1.4 他のマスタデータオブジェクトとの統合#

権限グループは、どちらの方向においても単独で存在するわけではありません。動的グループは他のファンデーションオブジェクトからその基準を引き出し、また、すべてのグループの解決済みメンバーシップ（動的または静的）は、最終的に他のオブジェクト（およびログインしているすべてのユーザー）が依存する権限ロールの割り当てに供給されます。

パート 2: SF 固有のフィールド詳細#

2.0 SFの所有範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1 グループ定義（コア識別）#

グループ定義は、権限グループが存在するために最低限必要なレコードです。すべての権限ロールバインディング、および「権限ロール管理」内のすべてのグループピッカーは、この定義に解決されます。

2.2 動的グループ条件#

動的グループ条件は、ライブメンバーシップを決定するルール定義です。条件はリアルタイムの従業員データに対して評価されるため、このセクションによって権限グループが静的なリストから自己管理型の母集団へと変わります。

2.3 静的グループメンバーシップ#

静的グループメンバーシップは、意図的に手動のメカニズムであり、組織データから導出可能ではなく、真に名前ベースである集団のために予約されています。

2.4 ロール割当における使用#

権限グループ自体は何も許可しません。権限ロールの割り当てにバインドされて初めて意味を持ちます。このセクションでは、そのバインドの仕組みと、最も一般的な設定ミスが発生する箇所について説明します。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction