JinJin48

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

July 8, 2026 · 8 min read

SAP Fieldglass User Role

The User Role is the first object configured in the Phase 2 User & Permission Settings sequence — it has no upstream master data dependency, and every User created afterward must be assigned at least one Role before they can log in and do anything useful. A Role defines what a person can see and do: which Fieldglass modules they can open, which actions they are permitted to perform, and how much of the tenant’s data is visible to them. This article maps the User Role’s core concepts across all Fieldglass capability areas (Part 1), then details every field an administrator configures when creating and maintaining Role records (Part 2).

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

1.1 What Is the User Role?#

The User Role is a named permission set in SAP Fieldglass that determines what a User can access and do across the tenant. Rather than assigning permissions directly to individual people, an administrator defines a small library of Roles once — Hiring Manager, Approver, Administrator, and similar — and then assigns one or more of those Roles to each User. It is the first object created in the Phase 2 User & Permission Settings setup sequence and has no upstream master data dependency; User, the very next object in the sequence, cannot be created without at least one existing Role to assign to it.

1.2 User Role Categories by User Type#

User Role does not carry a formal “Role Type” code field the way Rate Category carries a Rate Type — instead, every Role is created within one of three User Type scopes, and that scope determines which screens, permission catalogs, and Module Access options are even available to select when building the Role. Confusing these scopes at design time — for example, trying to grant a Supplier-scoped Role visibility into another Supplier’s submissions — is a common source of a failed security review before go-live.

Design principle: Fieldglass has no formal parent/child Role inheritance model — Roles do not “extend” a broader Role the way an org hierarchy nests. Assign the narrowest Role that matches the User’s actual job; if a Role turns out to be too broad, every User individually assigned to it must be reassigned one by one, since there is no parent Role to correct centrally.

1.3 Organizational Levels and Data Hierarchy#

Data hierarchy with a concrete example

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

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

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

User Role sits at the top of this zone, at the same tenant level as the other Company Structure and Rate objects — it has no organizational parent. Its relationship to User 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 Role only to keep the concrete example readable. 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 permissions before they can be added to an Approval Group.

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 Role record does not stand alone — it is the prerequisite that the entire User & Permission Settings phase, and everything downstream of it, depends on.

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 Role and control whether it can still be assigned to new Users.

2.2 Permission & Access Scope#

These three fields are the actual access-control logic of the Role — together they decide what a User assigned to this Role can see and do.

Prerequisite: User Role must exist and be Active before any 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