In Workday, User-Based security groups are manually assigned directly to a user account for unconstrained, tenant-wide access, whereas Role-Based security groups derive membership from a worker's position ("chair") and typically constrain target data access to assigned organizations. When single security groups cannot express your support model, Intersection security groups combine multiple groups using AND logic (intersecting both membership and organizational constraints), while Aggregation security groups combine multiple groups using OR logic (uniting members while preserving each underlying group's individual target constraints).

Side-by-side comparison of the four security group types

A user's effective access in Workday is the union of all security groups attached to their account. Choosing the right group type depends on two questions: how a worker becomes a member, and what target data constraint Workday must enforce when they run a report or act on an event.

Security Group Type How Membership Is Assigned Target Context / Constraint Logic / Primary Use Case
Security Group TypeUser-BasedHow Membership Is AssignedManually assigned to the Workday Account; follows the person across job changes.Target Context / ConstraintUnconstrained (sees all target instances across the tenant).Logic / Primary Use CaseCentral administrators (HR Administrator, Payroll Administrator, Security Administrator, Report Writer).
Security Group TypeRole-Based (Constrained)How Membership Is AssignedDerived from an Assignable Role placed on a worker's position or job for an organization.Target Context / ConstraintConstrained to target workers/data in the assigned organization (and configured subordinates).Logic / Primary Use CaseDecentralized leaders and partners (Manager, HR Partner, Cost Center Manager, Accountant).
Security Group TypeIntersectionHow Membership Is AssignedDerived (AND logic)—user must belong to all included security groups and no excluded group.Target Context / ConstraintMixed / Intersected—intersects the constraints of all included groups (plus optional target org exclusions).Logic / Primary Use CaseMulti-dimensional support (e.g., Supervisory HR Partner AND Location Hierarchy HR Partner) or hiding sensitive populations.
Security Group TypeAggregationHow Membership Is AssignedDerived (OR logic)—user belongs to any included security group and no excluded group.Target Context / ConstraintMixed / Preserved—each included group retains its own underlying target constraints.Logic / Primary Use CaseGrouping multiple constrained or unconstrained groups into a single "hub" on domain and business process security policies.

1. User-Based security groups: Tenant-wide and person-bound

User-Based security groups are unconstrained and bound directly to the user's Workday account rather than their position. When a user is granted a User-Based group (via Assign Users to User-Based Security Group or Assign User-Based Security Groups for Person), they can access every target worker or object instance secured by the domains and business process policies where that group is permitted.

Operational risks and lifecycle hygiene

Because User-Based assignments follow the individual person, a worker who transfers from Corporate HR into a line-of-business role retains their HR Administrator User-Based group until someone removes it. To prevent privilege creep:

  • Add the Review User-Based Security Group Assignments To Do step or Assign Roles - Change Assignments for Worker subprocess to your Change Job business process definition.
  • Add the Remove User-Based Security Groups and Terminate User Account Service steps to your Termination, End Contingent Worker Contract, and End Academic Appointment business process definitions so Workday automatically strips User-Based groups upon exit.
  • Optionally enable the User-Based Security Group Event For User and User-Based Security Group Event for Group workflows (via the Process: User-Based Security Group Event domain) so changes via Update User-Based Security Group Assignments require peer approval.

2. Role-Based security groups: Position-bound and organization-constrained

Role-Based security groups derive membership from an Assignable Role (configured via Maintain Assignable Roles). Instead of assigning the security group to a person, you assign the role to a worker's position ("chair") for a specific organization instance (such as a Supervisory Organization, Company, Cost Center, Pay Group, or Location Hierarchy).

Tying the assignment to the position means that if a manager leaves, the role assignment can stay on the unfilled position so the replacement hire automatically inherits the role. You can create multiple Role-Based security groups referencing the same assignable role with different organizational span-of-control settings:

  • Current Organization Only (COO): Access is restricted strictly to the exact organization node where the user holds the role.
  • Current Organization and Unassigned Subordinates (COUS): Access extends down into child organizations only where no lower-level assignee fills that same role.
  • Current Organization and All Subordinates (COAS): Access extends down through all subordinate organizations in the hierarchy (commonly used for a Management Chain security group).
  • Current Organization and Subordinates to Level: Access extends down a fixed number of hierarchy tiers.
  • Role-Based (Unconstrained): Grants tenant-wide access to anyone holding the role in any organization.

For workers with multiple jobs, Role-Based (Constrained) groups also let you specify whether the role holder has access only to the specific position they support (Role has access to the positions they support), only when supporting the primary job (Role for primary job has access to all positions), or across all positions (Role has access to all positions).

3. Intersection security groups: Narrowing access with AND logic

A single Role-Based security group can only reference one assignable role, and each assignable role should be enabled for a single organization type (or an organization type and its matching hierarchy). When an HR Partner should only see employees who sit in both a specific Supervisory Organization and a specific country or Location Hierarchy, neither group alone is sufficient.

An Intersection security group solves this by requiring AND membership and intersecting the target constraints:

How Intersection evaluation works

  1. Membership (AND): A user is a member of the Intersection security group only if they belong to every security group listed in the Intersection Criteria (and do not belong to an optional excluded unconstrained security group).
  2. Target Constraint (AND): If an HR Partner is assigned to the Sales Supervisory Organization (via HR Partner - Supervisory) and to Canada (via HR Partner - Location Hierarchy), the Intersection security group restricts them to target workers who are simultaneously in Sales and located in Canada.
  3. Target Exclusion Criteria (Hiding populations): Alternatively, you can configure the Exclusion section on an Intersection group to hide positions in specified organizations (such as a Hidden Staff custom organization for executives, HR staff, or student workers protected by privacy rules). Note that you can configure either an excluded security group or excluded target organizations on an Intersection group, not both, and target organization exclusions are intended for View domain policies rather than business process step routing.

Rules and limitations for Intersection groups

  • Critical policy rule: When you deploy an Intersection security group onto a domain or business process security policy, remove the component Role-Based security groups from that policy. Because Workday access is a union of all groups, leaving HR Partner - Supervisory on the policy alongside the Intersection group gives the user full supervisory access, bypassing the location intersection entirely.
  • Nesting restrictions: An Intersection security group can include an Aggregation security group, but cannot include another Intersection security group, a Rule-Based security group, or an Integration System security group.
  • Functional boundaries: Certain Workday areas that assume whole-organization context—such as Move Workers, Create Position, Create Job Requisition, Compensation Review, and Find Events—do not support Intersection security groups.

4. Aggregation security groups: Scaling policies with OR logic

An Aggregation security group combines multiple security groups using OR logic: any user who belongs to at least one of the included security groups (and is not in an excluded security group) is a member of the Aggregation group.

Crucially, included security groups retain their own target access constraints. If an Aggregation security group contains HR Partner (Constrained), Benefits Partner (Constrained), and Service Center Representative - Europe (Constrained):

  • Adding that single Aggregation group to 40 domain security policies and business process steps grants all three groups access without adding three separate lines to every policy.
  • When an HR Partner runs a report or receives a routed business process step via the Aggregation group, Workday still enforces their specific supervisory organization constraint; when the Europe Service Center user accesses the same item, Workday enforces their European organization constraint.
  • If you later introduce a new regional Intersection group or Service Center group, you simply add it to the Aggregation security group definition. Because security group edits take effect immediately, you do not have to edit the 40 domain/business process policies or run Activate Pending Security Policy Changes.

Rules for Aggregation groups

  • An Aggregation security group can include Intersection, Role-Based, User-Based, Job-Based, Segment-Based, or Service Center groups, but cannot include another Aggregation group, a Rule-Based group, or an Integration System security group.
  • Treat the Aggregation group as the lowest common denominator of access. If one included group (such as a specific country Service Center) needs extra domain access that the others should not have, grant that extra domain permission directly to the individual child group ("topping off"), never to the Aggregation group.

Troubleshooting security group membership and constraints

When a user sees too much data, sees blank fields, or fails to receive a routed task:

  1. Test exact target evaluation: Run Test Security Group Membership, entering the Workday Account, the Security Group, and the Target worker or organization instance. Workday reports whether the user is a member and whether their constraint permits access to that specific target.
  2. Audit cumulative user groups: Run View Security Groups for User to list every Workday-assigned, User-Based, Role-Based, Intersection, and Aggregation group on the account. If an unconstrained group (like an old User-Based group) is granting access to the same domain, it overrides any constrained or Intersection group via union logic.
  3. Check Intersection role alignment: For an Intersection of two Role-Based groups, run Role Assignments for Worker Position and confirm the worker's exact same position is assigned to both underlying roles. If one role is missing or future-dated, the user drops out of the Intersection group completely.
  4. Compare two workers: When one partner has expected access and a peer does not, run Compare Security of Two Worker Accounts or Compare Permissions of Two Security Groups to isolate the missing role assignment or group membership.

How kiweely fits

Auditing complex combinations of Role-Based, Intersection, and Aggregation security groups—especially verifying that component groups were removed from domain policies after introducing an Intersection group—is error-prone when done manually across dozens of reports. kiweely analyzes your tenant's security group hierarchy, role assignments, and policy permissions to pinpoint why a user can or cannot see a target population and catch union leaks before they reach production. Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.

Frequently asked questions

Why can a user in an Intersection security group still see workers outside their intersected location?

Workday calculates effective access as the union of all security groups on a user's account. If the underlying component Role-Based security group (or an unconstrained User-Based group) is still listed directly on the Domain Security Policy alongside the Intersection group, the user gets the broader access from that component group. Remove the component groups from the policy and run Activate Pending Security Policy Changes.

Can you put an Intersection security group inside an Aggregation security group?

Yes. Both combinations work: an Aggregation security group can contain one or more Intersection security groups (useful when different regions use different intersected support models), and an Intersection security group can contain an Aggregation security group. However, you cannot nest an Intersection inside another Intersection or an Aggregation inside another Aggregation.

Does adding a security group to an Aggregation group require Activate Pending Security Policy Changes?

No. Modifying the membership or definition of a security group—including adding or removing child security groups inside an Aggregation or Intersection group—takes effect immediately without running Activate Pending Security Policy Changes.

What happens to Role-Based vs. User-Based security when an employee changes jobs?

A User-Based security group is attached to the person's Workday Account and stays with them across job changes until manually or automatically removed. A Role-Based assignment is tied to the position ("chair"); depending on whether the organization uses Position Management or Job Management and how the Assign Roles - Change Assignments for Worker step is handled during Change Job, the role either stays on the vacated position for the backfill or transfers/is removed.

Sources checked