JinJin48

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

July 8, 2026 · 9 min read

SAP Fieldglass User

The User is the second object configured in the Phase 2 User & Permission Settings sequence — it cannot be created until at least one User Role already exists, and it is the record every person in the tenant actually logs in through, whether they work for the Client, a Supplier, or an MSP. A User carries identity attributes (name, email, status), one or more assigned User Roles that determine what it can see and do, and — when its Role grants approval permissions — the Approval Authority that lets it be added to an Approval Group. This article maps the User’s core concepts across all Fieldglass capability areas (Part 1), then details every field an administrator configures when creating and maintaining User records (Part 2).

Part 1: User — Core Concepts (All Modules)#

1.1 What Is the User?#

The User is the individual login account in SAP Fieldglass — the record that represents one specific person and determines, through its assigned Role(s), what that person can access and do across the tenant. Unlike User Role, which is a small reusable permission template, User is a high-volume object: a mid-size program can easily carry hundreds or thousands of active User records, one per employee, supplier recruiter, or MSP coordinator who touches the system.

1.2 User Types by Access Domain#

Every User is created within one of three access domains, and that domain is fixed at creation — it is not a field that gets changed later, because it determines which company’s email/login format is expected and which User Roles can even be assigned. Getting this wrong at onboarding (for example, creating a Supplier recruiter as a Client User) is a fast path to a failed access review, since the User would then be eligible for Roles far broader than their actual job requires.

Design principle: A User’s access domain must match the User Type Scope of every Role assigned to it — Fieldglass enforces this at assignment time, not as a manual convention. Confirm the domain is correct before the first Role is attached; correcting it later means deactivating and recreating the User rather than editing a field.

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  ◄── this article
       └── Approval Group "AG-ENG-01" — Eng approvers pool

User Role "ROLE-APR" — Approver
│
└── User "u.brian" — Brian, Program Mgr  ◄── this article

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

User sits in the middle of this zone, between User Role above it and Approval Group below it. Its relationship to User Role is not true containment: the underlying multiplicity is N:M (one Role can be assigned to many Users, and one User can hold several Roles at once), rendered above as a single assignment per User only to keep the concrete example readable — u.mavis, for instance, could also carry a second, narrower Role in addition to ROLE-MGR. Approval Group membership is likewise an N:M assignment that flows through User, not through Role directly: a User must first hold a Role with the right approval permission before it can be added to an Approval Group, which is why u.brian (an Approver-Role User in this example) has no Approval Group shown — Approval Group assignment is a separate, additional step, not an automatic consequence of the Role.

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 Role or User — see FG-A03-04 (Distribution List) for that relationship in detail.

1.4 Integration with Other Master Data Objects#

The User record does not stand alone — every login and every action recorded in the tenant traces back to one.

Part 2: FG-Specific Field Details#

2.0 Scope of FG Ownership#

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

2.1 Basic Identification & Status#

These fields uniquely identify a person and control whether their account can be used to log in.

2.2 Role & Approval Assignment#

These fields connect the User to the permission model and, where applicable, the approval workflow.

Prerequisite: At least one Active User Role must exist before a User can be created and assigned to it (Setup Flow Phase 2, Step 8 → Step 9).

What to Read Next#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction