JinJin48

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

July 8, 2026 · 11 min read

SAP Fieldglass 承認グループ

承認グループは、フェーズ2「ユーザー＆権限設定」シーケンスで3番目に設定されるオブジェクトです。少なくとも1人のユーザーが存在するまで作成できず、求人投稿、タイムシート、経費シート、またはSOW文書の承認が必要な場合に、承認ワークフローが参照するユーザーのプールです。承認グループは、識別情報（ID、名称、ステータス）と、モジュールのワークフローの特定の段階でグループが呼び出されるたびに承認者として行動できるメンバーユーザーのセットを持ちます。この記事では、パート1でFieldglassの全機能領域にわたる承認グループのコアコンセプトをマッピングし、パート2で管理者が承認グループレコードを作成および保守する際に設定するすべてのフィールドを詳しく説明します。

第1部: 承認グループ — 中核概念（全モジュール共通）#

1.1 承認グループとは#

承認グループとは、Fieldglass の承認ワークフローの1つ以上のステージにおいて、トランザクション伝票を承認する権限を付与されたユーザーの名前付きコレクションです。管理者は、個々のワークフローごとに承認者を個別に指定するのではなく、「IT部門レベル1承認者」「財務部門承認」などの再利用可能な対象ユーザープールを一度作成し、そのプールを任意の承認ルール（全モジュール対象）から参照します。承認グループ自体は、誰が承認資格を持つかのみを定義します。各グループがいつ行動するかの順序や並行処理は、ワークフローの承認ルールで別途設定されます。

1.2 ワークフロー動作別の承認グループタイプ#

承認グループには正式な「タイプ」コードフィールドはありません。代わりに、同じグループレコードが、それを参照する承認ルールの設定方法に応じて、異なる方法で使用されます。これらの4つの使用パターンを理解することは重要です。なぜなら、それらによってワークフローに実際に必要なグループの数と、それらが作用する順序が決まるからです。この設計を誤ると、次の承認者が明確でないまま伝票が停滞する一般的な原因となります。

設計原則: 承認グループは誰が承認できるかを定義し、いつ承認するかは定義しません。順序、並列処理、エスカレーションのタイミングは、グループを参照する承認ルール（ワークフロー定義）に存在し、承認グループレコード自体には存在しません。同じグループが、あるワークフローではレベル1となり、別のワークフローでは並列の財務チェックとなることができます。

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

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

User Role "ROLE-MGR" — Hiring Manager
│
└── User "u.mavis" — Mavis, Eng Mgr
       └── Approval Group "AG-ENG-01" — Eng approvers pool  ◄── this article

User Role "ROLE-APR" — Approver
│
└── User "u.brian" — Brian, Program Mgr
       └── Approval Group "AG-ENG-01" — Eng approvers pool  ◄── this article
       └── Approval Group "AG-FIN-01" — Finance sign-off pool  ◄── this article

User Role "ROLE-ADMIN" — Administrator
│
└── User "u.admin" — System Admin
       └── Distribution List "DL-ENG-ALL" — Notification group

承認グループはこのゾーンの最下部に位置し、ユーザ経由でのみ到達可能であり、ユーザロールとの直接的な関係はありません。ユーザと承認グループの間の多重度はN:Mです。u.mavisとu.brianは両方ともAG-ENG-01に属し、u.brianはさらにAG-FIN-01にも属しており、これは1人のユーザが複数のグループに所属でき、1つのグループが複数のユーザを保持できることを示しています。兄弟記事であるユーザと同様に、ユーザは承認グループに追加される資格を得る前に、承認権限を持つロールを保持している必要があります。承認グループのメンバーシップは、別個の追加ステップであり、ロールやユーザ作成の自動的な結果ではありません。

この同じゾーンには、管理上の近接性から配布リストも表示されます（ユーザーや承認グループと同じ管理領域から管理されます）。しかし、その実際のマスタデータ前提条件はユーザーではなく仕入先です。この関係の詳細については、FG-A03-04（配布リスト）を参照してください。

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

承認グループレコードは単独では存在しません。その唯一の目的は、テナント内の他のワークフローから参照されることです。

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

2.0 FG所有権の範囲#

凡例: ◎ = オーナー/重要、○ = 直接関与

2.1 基本識別とステータス#

これらのフィールドはグループを識別し、今後ワークフローにアタッチできるかどうかを制御します。

2.2 メンバーシップとワークフロー設定#

これらのフィールドは、どのユーザーがグループを代理してアクションを実行できるか、およびグループがワークフローにアタッチされた後のグループの動作を決定します。

前提条件: 承認グループにユーザを追加する前に（セットアップフローフェーズ2、ステップ9 → ステップ10）、関連する承認権限を持つアクティブなユーザが少なくとも1人存在している必要があります。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction