Security Groups, Roles, and Permissions
Two independent permission systems
Workday authorizes access through domain security policies (what data you can view or modify) and business process security policies (what actions you can initiate, approve, cancel, or correct). They are separate: View on a domain does not let someone approve a step, and being an approver on a step does not automatically surface the underlying data. Approvers typically also need View access to the source object.
Security groups
A security group is the container that receives permissions. Common types:
- Role-based - membership from a role assignment such as Manager or a custom role.
- User-based - an explicit list of workers.
- Job-based - membership derived from job profile or position attributes.
- Aggregation - the union or intersection of other groups, used to express things like managers plus HR partners, or people who meet two conditions at once.
Traps to watch:
- Confusing intersection with union. Intersection is restrictive and is the answer whenever a question says only users who meet both conditions.
- Integration users: an Integration System User must be paired with an Integration System Security Group carrying an explicit domain scope. Without the ISSG the user has nothing, and granting all domains is a finding, not a fix.
- Segmented domains: worker data and report fields are secured by segment, so two people with domain access may still see different fields.
Rule of thumb: troubleshoot with View Security for User, walking group membership to policy to permission. Fix at the group, never by hand-editing individual policy permissions. Deactivate referenced groups rather than deleting them, since policies and routing steps may still point at them.