9.2 User-Based, Role-Based & Workday-Assigned Groups

Workday Pro HCM Core Certification Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts & Format 1.2 Eligibility, Learning Path & Access 1.3 Study Strategy & Blueprint Map

2 Navigation & Business Objects

2.1 Navigation Techniques in Workday 2.2 Business Objects & Finding Data

3 Organizations & Hierarchy

3.1 Organization Types & Subtypes 3.2 Supervisory Organizations & Reporting Structure 3.3 Cost Centers, Company Hierarchies & Locations 3.4 Leadership Roles & Worker Organization Assignments

4 Staffing Models

4.1 Position Management Staffing Model 4.2 Job Management Staffing Model 4.3 Hiring Restrictions on Organizations

5 Job Profiles & Job Structure

5.1 Creating & Editing Job Profiles 5.2 Job Profiles, Jobs, Positions & Workers 5.3 Job Families, Family Groups & Job Requisitions

6 Compensation Fundamentals

6.1 Compensation Framework Components 6.2 Eligibility Rules & Compensation Defaulting 6.3 Packages, Grades & Grade Profiles 6.4 Salary Plans, Allowance Plans & Worker Comp Events

7 Jobs, Positions & Staffing Events

7.1 Creating Positions & Position Hiring Restrictions 7.2 Managing Filled, Unfilled, Close & Freeze 7.3 Hire Process End-to-End 7.4 Job Changes & Additional Staffing

8 Termination & Contingent Workers

8.1 Terminate Employees 8.2 Contracting Contingent Workers 8.3 Ending Contingent Worker Contracts

9 Configurable Security

9.1 Functional Areas, Domains & Business Processes 9.2 User-Based, Role-Based & Workday-Assigned Groups 9.3 Domain Security Policies 9.4 BP Security Policies, Org Access & Activation

10 Business Process Framework

10.1 Organizations, Security & BP Relationships 10.2 Default, Org-Specific & Rule-Based Definitions 10.3 Definition, Type, Event & Step

11 Business Process Steps & Approvals

11.1 Actions & Subprocesses 11.2 Approvals & Approval Chains 11.3 Completing Tasks During Business Processes

12 Business Process Configuration

12.1 Condition Rules 12.2 Advanced Routing, Labels & Help Text 12.3 Custom Notifications 12.4 Step Ordering Letters & Validation Conditions

13 BP Management & Security

13.1 Mass and Individual BP Management 13.2 BPs and Configurable Security Interaction

14 Report Writer Fundamentals

14.1 Standard Reports & Copy/Modify 14.2 Building Custom Reports: Index vs Standard 14.3 Sorting, Filtering & Prompts 14.4 Report Security, Sharing & Ownership

15 Advanced Reporting & Calculated Fields

15.1 Scheduling Reports 15.2 Matrix Reports 15.3 Discovery Boards 15.4 Calculated Fields & Report Performance

9.2 User-Based, Role-Based & Workday-Assigned Groups

Key Takeaways Explain This Topic AI

User-based security groups have manually maintained membership and suit administrative or special-access populations not driven by org role assignment.

Role-based security groups derive membership from assignable roles on organizations; membership updates as role assignments change.

Workday-Assigned (process-maintained) security groups have membership maintained by Workday based on delivered criteria—such as Employee as Self—not by ad-hoc admin lists.

Constrained role-based groups limit access to the organization context of the role assignment; unconstrained role-based groups grant the role's access across organizations—important.

Maintain security groups and assignable roles as paired design: create/update the group, define or use the assignable role, assign roles on orgs, then attach groups to policies.

Last updated: September 2026

9.2 User-Based, Role-Based & Workday-Assigned Groups

Study index: T-numbers here refer to this guide’s index of an older Workday topic list. They are not current Workday task IDs or published exam weights.

Quick Summary: Workday security groups come in multiple types. For HCM Core, master three: user-based (manual membership), role-based (membership from roles on organizations, constrained or unconstrained), and Workday-Assigned (membership maintained by Workday criteria such as Employee as Self). Maintaining groups and assignable roles is how you keep who-is-in-the-bucket correct before policies grant what they can do.

Tasks T39 and T40 sit at the center of Configurable Security. Practice scenarios should ask which group type fits—or whether a role-based design should be constrained or unconstrained . Get this wrong and every later policy discussion collapses.

Security Groups: The "Who" Layer

A security group is a named collection of users (or system identities) used as a permission target on domain and business process security policies. Groups do not store pay ranges or org hierarchies. They answer: which people share this access design?

Group type (HCM Core focus) How membership is determined Typical use

User-Based Administrator adds/removes members manually IT admins, special project access, small privileged sets

Role-Based Users who hold a specified assignable role on one or more organizations Manager, HR Partner, Compensation Partner by org

Workday-Assigned Workday maintains membership from delivered rules/criteria Employee as Self and similar process-maintained populations

Other group types exist in the broader product (for example Job-Based groups keyed to job profile/family criteria, Integration System Security Groups for integration system users, and public/authenticated patterns). HCM Core exam language emphasizes differentiating user-based , role-based , and Workday-Assigned , plus constrained vs unconstrained for role-based access.

User-Based Security Groups

A User-Based Security Group has manually maintained membership . An administrator adds workers (or accounts) to the group and removes them when access should end. Membership does not automatically follow a manager promotion or a transfer to a new supervisory org.

When user-based is the right design

Small numbers of administrators who need broad setup access not tied to a single org role.

Temporary elevated access for a project team that is not modeled as an org role.

Situations where no delivered role assignment cleanly describes the population.

Risks and controls

Because membership is manual, user-based groups can drift : people leave the company or change jobs but remain in the group until someone audits membership. Strong tenants schedule access reviews and treat user-based membership as privileged configuration.

Configuration scenario: Northwind needs three HRIS configuration specialists to maintain job profiles and staffing setup across the enterprise. The security admin creates a user-based group "HRIS Configurators," adds the three specialists, places the group on the appropriate domain policies with Modify, and reviews membership quarterly. These users are not Managers of every org; role-based Manager groups would be the wrong model.

Exam trap: User-based does not mean "all users in the tenant." That pattern is closer to public/authenticated concepts. User-based means admin-curated membership .

Role-Based Security Groups

A Role-Based Security Group ties access to an assignable role . When a worker is assigned a role (for example Manager or HR Partner ) on an organization, they become a member of the corresponding role-based security group(s) configured for that role. When the role assignment ends, membership ends. This is the workhorse pattern for HCM operational security.

Assignable roles and org assignment

Assignable roles are the role definitions you place on organizations—most importantly Supervisory Organizations , but also other org types depending on design (for example roles on cost centers or companies in broader designs). Common HCM roles include:

Manager
HR Partner
Compensation Partner
Recruiting Partner (when used)
Other supporting roles defined for the tenant

Maintain security groups and assignable roles means you:

Ensure the assignable role exists for the intended use.

Create or maintain the role-based security group linked to that role (and constrained/unconstrained design).

Assign the role to the correct workers on the correct organizations.

Place the security group on domain and BP policies as needed.

Confirm organization access options (section 9.4) match the intended population scope.

Role assignment is not the same as editing a domain policy. "Assign Roles" puts a person into the role context; policy work grants that role's group permission to act.

Constrained vs Unconstrained (important)

Within role-based security, constrained versus unconstrained is the highest-frequency trap.

Design Access scope Mental model Typical example

Constrained Limited to the organization context of the role assignment (and configured org access options) "HR Partner of Engineering sees Engineering (and allowed subordinates), not Finance" Local HR Partner, Manager of a team

Unconstrained Role-based access across organizations , not limited to the assignment's org context "Same functional access enterprise-wide regardless of which org the role was assigned on" Rare broad admin-style role-based designs; high risk if overused

Constrained groups identify and restrict support staff (or managers) to target instances within designated organizations . That is why constrained designs dominate healthy HCM tenants: they implement least privilege along the supervisory (or other) hierarchy.

Unconstrained role-based groups grant the role's configured access across all organizations regardless of the assignment context that made the person a member. They are powerful and dangerous: one unconstrained HR-style group can expose the whole worker population if policies are broad. Constrained HR Partner on "Engineering"

│
▼
Access to workers/orgs in Engineering scope (per org access options)

Unconstrained HR Partner (same role group type, unconstrained)
│
▼
Access spans organizations—not limited to a single assignment context

Exam scenario A: "HR Partner of Engineering can see Engineering workers but not Finance." → Constrained role-based security group design with correct org role assignment on Engineering.

Exam scenario B: "Unconstrained means the user has no permissions." → False. Unconstrained means broader organizational scope, not zero access.

Exam scenario C: "Constrained groups apply only to integrations." → False. Constrained is primarily about role-based population scope for human operational roles (and related designs), not "integrations only."

Maintaining role-based designs in practice

Task Purpose
Create / edit role-based security group Define role linkage and constrained vs unconstrained

Maintain assignable roles Ensure roles exist for Manager, HR Partner, etc.

Assign Roles on organizations Put the right people in the membership pipeline
Edit domain/BP policies Grant the group what it can do
Activate pending policy changes Publish policy edits
Review org access options Control included orgs / subordinate visibility

Configuration scenario: Global Retail Co. assigns Manager on each Store Team supervisory org and uses a constrained role-based Manager group on Hire Initiate/Approve and on worker View domains. Store managers see and act on their teams. Corporate HR assigns HR Partner constrained on Region Leadership orgs so partners cover a multi-store population without unconstrained enterprise access.

Workday-Assigned Security Groups

Workday-Assigned security groups (also discussed as process-maintained in some training materials) have membership maintained by Workday according to delivered criteria—not by an admin adding names one by one, and not primarily by org role assignment the way role-based groups work.

The classic example is Employee as Self (and similar self-service oriented groups). Workers become members because they are employees (or meet the delivered membership rule), enabling self-service tasks and personal data access patterns designed by Workday and refined by tenant policies.

Why Workday-Assigned matters in practice

Differentiates from user-based (manual list) and role-based (org role assignment).

Explains how every worker can have self access without being added to hundreds of manual groups.

Reminds you that some membership is system-driven ; admins still control what those groups can do via policies, but they do not hand-maintain every member.

Exam trap: Workday-Assigned is not "the admin forgot to assign roles." It is an intentional membership model. Also, do not confuse Workday-Assigned membership with Activate Pending Security Policy Changes —activation applies to policy edits, not to everyday membership changes for users already covered by existing live policies.

Comparing the Three Types Side by Side

Dimension User-Based Role-Based Workday-Assigned
Membership source Manual admin list Assignable role on org(s) Workday-delivered criteria

Updates with HR events Only if admin edits list Yes, when role assignments change Yes, when membership criteria change

Best for Privileged admins, special sets Managers and partners by org Self and similar delivered populations

Constrained concept Not the role constrained/unconstrained pair Critical constrained vs unconstrained Different membership model

Primary admin task Maintain members Maintain roles + assignments + group definition Rely on delivered membership; policy design

Additional Group Types You May See in Stems

Without expanding beyond Core, recognize nearby language so distractors fail:

Job-Based Security Group: membership from job profile / job family / job family group criteria; updates as workers change jobs.

Integration System Security Group (ISSG): for Integration System Users (non-human accounts) running EIBs/Studio; typically Get/Put on domains.

Public / Authenticated patterns: broad access to all authenticated users—not the same as a small user-based admin group.

If a stem says "non-human integration user," prefer ISSG over user-based HR Partner groups.

Practical Maintenance Checklist (T40)

When reviewing security groups and assignable roles , walk this checklist:

Choose the group type that matches the population model (user vs role vs Workday-Assigned).

For role-based, decide constrained vs unconstrained with least privilege as the default.

Confirm assignable role exists and is the one intended for Manager/HR Partner/etc.

Assign roles on the correct organizations (often Supervisory).

Attach the group to the correct domain and BP policies.

Set organization access options for constrained designs.

Activate policy changes if policies were edited.

Test with a real worker account in that role (Security Analysis tools exist in real tenants for diagnosis).

Realistic multi-part scenario: After a reorg, Engineering's new HR Partner cannot see the team. Likely causes in group terms: role not assigned on the new Supervisory Org; wrong security group (user-based empty group used instead of role-based); constrained group correct but org access options exclude subordinates; policies never included the group; or policies edited but not activated. Methodically separate membership , constraint , policy , and activation .

Master constrained vs unconstrained and the three membership models before domain permission checkboxes. Most security misses on practice tests are vocabulary and scope—not obscure UI clicks.