In Workday HCM, user-based security groups grant access to specific individuals rather than to positions or organizations. These security groups are designed to provide permissions directly to a Workday user account , making them appropriate when access should not change automatically based on position changes or organizational movement.
To include a new hire in an existing user-based security group, you must associate the group with the individual’s Workday Account . A Workday Account represents the system login identity for a worker and is the object that security groups reference when assigning user-based access. Once the new hire’s Workday Account is created as part of the Hire business process, the account can be added to the user-based security group, immediately granting the associated permissions.
The other options are incorrect because they apply to different security models. Worker Position is used for role-based security groups, where access follows the position rather than the individual. Worker Location and Job Profile are organizational and job architecture attributes and are not valid association objects for user-based security groups.
From a Workday Pro HCM best-practice perspective, user-based security groups should be used sparingly, typically for exceptions, administrators, or roles that require access independent of organizational structure. Because access does not automatically transfer when a worker changes jobs or positions, administrators must manually manage membership by adding or removing Workday Accounts as needed.
Therefore, the correct and Workday-verified way to include a new hire in an existing user-based security group is to associate the Workday Account with the security group.
