JinJin48

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

July 8, 2026 · 9 min read

SAP Fieldglass Approval Group

The Approval Group is the third object configured in the Phase 2 User & Permission Settings sequence — it cannot be created until at least one User already exists, and it is the pool of Users that an approval workflow points to when a Job Posting, Timesheet, Expense Sheet, or SOW document needs someone to sign off. An Approval Group carries an identity (ID, name, status) and a set of member Users, each eligible to act as approver whenever the group is invoked at a given stage of a module’s workflow. This article maps the Approval Group’s core concepts across all Fieldglass capability areas (Part 1), then details every field an administrator configures when creating and maintaining Approval Group records (Part 2).

Part 1: Approval Group — Core Concepts (All Modules)#

1.1 What Is the Approval Group?#

The Approval Group is a named collection of Users granted the authority to approve transactional documents at one or more stages of a Fieldglass approval workflow. Rather than naming an individual approver on every workflow, an administrator builds a reusable pool of eligible Users once — “IT Dept Level 1 Approvers,” “Finance Sign-off,” and similar — and then references that pool from any Approval Rule that needs it, across any module. The Approval Group itself only defines who is eligible to approve; the sequencing and parallelism of when each group acts is configured separately, on the workflow’s Approval Rule.

1.2 Approval Group Types by Workflow Behavior#

An Approval Group does not carry a formal “Type” code field — instead, the same group record can be used in different ways depending on how the Approval Rule that references it is configured. Understanding these four usage patterns matters because they determine how many groups a workflow actually needs and in what order they act; designing this poorly is a common cause of documents stalling with no clear next approver.

Design principle: The Approval Group defines who can approve, not when. Sequence, parallelism, and escalation timing live on the Approval Rule (workflow definition) that references the group, not on the Approval Group record itself — the same group can be Level 1 on one workflow and a parallel Finance check on another.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

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

Approval Group sits at the bottom of this zone, reached only through User — it has no direct relationship to User Role. The underlying multiplicity between User and Approval Group is N:M: u.mavis and u.brian both belong to AG-ENG-01, and u.brian additionally belongs to AG-FIN-01, illustrating that one User can carry membership in several groups and one group can hold many Users. As with the sibling User article, a User must already hold a Role with approval permissions before it becomes eligible to be added to an Approval Group — Approval Group membership is a separate, additional step, not an automatic consequence of Role or User creation.

Distribution List appears in this same zone for administrative proximity (it is maintained from the same Admin area as Users and Approval Groups), but its actual master-data prerequisite is Supplier, not User — see FG-A03-04 (Distribution List) for that relationship in detail.

1.4 Integration with Other Master Data Objects#

The Approval Group record does not stand alone — its entire purpose is to be referenced by workflows elsewhere in the tenant.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Basic Identification & Status#

These fields identify a group and control whether it can still be attached to workflows going forward.

2.2 Membership & Workflow Configuration#

These fields determine which Users can act on behalf of the group and how the group behaves once attached to a workflow.

Prerequisite: At least one active User with the relevant approval permission must exist before that User can be added to an Approval Group (Setup Flow Phase 2, Step 9 → Step 10).

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction