9.2 User-Based, Role-Based & Workday-Assigned Groups
Key Takeaways
- 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—exam-critical.
- 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.
9.2 User-Based, Role-Based & Workday-Assigned Groups
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. Exam items often present a scenario and 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 (exam-critical)
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 on the exam
- 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 an exam item says maintain 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.
What is a User-Based Security Group?
What is the difference between a Constrained and an Unconstrained Role-Based Security Group?
Which statement best describes a Workday-Assigned security group?
An administrator needs Managers to approve Hire only for workers in the supervisory organizations where those managers hold the Manager role. Which design is most appropriate?