When configuring security in Workday, assigning a security group to a domain security policy or business process policy is only half the equation. You must also understand whether the group is Constrained or Unconstrained.

This fundamental architectural distinction determines whether a user can see data across the entire tenant or only for workers inside their specific organizational purview.

Configuring this incorrectly leads to two common failure states: either a partner unexpectedly sees confidential compensation records for workers in another subsidiary, or a local manager cannot access reports for their own direct reports.

1. The Core Conceptual Difference

  • Unconstrained Security Groups: The user’s access is global. If an unconstrained group is granted access to a domain (for example, Worker Data: Personal Info), members of that group can see personal info for every worker in the tenant, regardless of company, location, or supervisory organization. User-based security groups (such as HR Administrator or System Auditor) are almost always unconstrained.
  • Constrained Security Groups: The user’s access is scoped by organizational context. If a constrained group is granted access to a domain, members can see data only for workers within the organizations to which the user is specifically assigned. Role-based security groups (such as HR Partner or Manager) are typically constrained.

2. How Context Shapes Effective Access

To understand how Workday evaluates constrained access, consider an HR Partner assigned to Regional Sales - West:

  1. Domain Policy Access: The security policy for Worker Data: Compensation grants View access to the HR Partner role-based security group.
  2. Context Evaluation: When the HR Partner runs a compensation report or searches for an employee, Workday does not simply check if they belong to HR Partner.
  3. Target Worker Membership: Workday checks whether the target employee belongs to Regional Sales - West (or one of its subordinate supervisory organizations).
  4. Grant or Deny: If the employee is in Regional Sales - West, the compensation fields render. If the employee is in Regional Sales - East, the compensation fields render as blank or the row is completely excluded from reports.

3. When to Use Each Group Type

Choose Constrained Groups When:

  • Access must follow supervisory hierarchies, companies, cost centers, or geographic regions.
  • You need decentralized administration where local HR teams manage local staff without seeing global executive records.
  • The role participates in localized business process routing (for example, the manager approving their own team's time-off requests).

Choose Unconstrained Groups When:

  • The user performs central governance, compliance, or tenant-wide reporting (for example, Global Payroll Operations or Corporate Compliance).
  • The user is an automated Integration System User (ISU) that extracts tenant-wide data for an external enterprise data warehouse.
  • The securable item has no organizational dimension (for example, configuring tenant setup, tenant branding, or foundational picklists).

4. Troubleshooting Checklist: Why Access Fails

When a user cannot see data they believe they should have access to:

  1. Check Group Constraint Type: Run the task View Security Group and verify whether the security group is labeled as Role-Based (Constrained) or Role-Based (Unconstrained).
  2. Check Role Assignment: Run the task View Role Assignments for the target organization. Confirm that the user is explicitly named in the role, or that role inheritance from parent organizations is enabled.
  3. Verify Target Worker's Placement: Confirm that the employee in question is actually an active member of the supervisory organization where the role assignment lives.
  4. Check Intersection Security Groups: If an intersection group is used (requiring a user to belong to Group A AND Group B), verify that constraints on both groups align. A constraint on one group will restrict the entire intersection.

Sources checked