Workday Security Model: Groups, Policies & Domains

Security in Workday isn’t complicated.

It’s just unforgiving.

Make one mistake in your security configuration and you’ll either lock everyone out of critical tasks or accidentally expose sensitive data to the wrong people. There’s no middle ground.

I’ve seen Workday implementations grind to a halt because security wasn’t configured properly from day one. HR Partners can’t see their team’s data. Payroll can’t run payroll. Managers can’t approve time off. Integration users can’t pull worker files. And every troubleshooting session starts with the same question: “Do they have the right security groups?”

The problem isn’t that Workday security is hard to understand. The problem is that most teams never build a mental model for how it actually works. They copy security from templates, add groups when access breaks, and hope for the best.

That creates permission sprawl. Overlapping access. Shadow permissions nobody understands. And eventually, a security audit that reveals your tenant is a mess.

This guide gives you the mental model you need to understand Workday security from first principles. We’ll break it down into three parts: WHO gets access (Security Groups), WHAT they can do (Security Policies), and WHERE it applies (Functional Areas). Once you understand this framework, Workday security stops being mysterious and starts being predictable.

Let’s dive in.

The 3-Part Mental Model for Workday Security

Every Workday security question can be answered by understanding these three components:

1. Security Groups = WHO
Think of these as containers of people. Security Groups define which users, workers, or roles are grouped together for access control.

2. Security Policies = WHAT
These define what those people can actually do. Security Policies grant or restrict permissions for viewing data, modifying records, initiating business processes, or approving transactions.

3. Functional Areas = WHERE
This defines where those permissions apply. Functional Areas include Domains (for data access) and Business Processes (for workflow steps and approvals).

When you combine these three elements, you get complete access control:

WHO (Security Group) can do WHAT (Security Policy) in WHERE (Functional Area).

Example: HR Partners (WHO) can view and modify (WHAT) worker data in the Worker Data: Personal Information domain (WHERE).

Let’s break down each component.

Part 1: Security Groups (WHO Gets Access)

Security Groups are containers of people. They define WHO is included in a particular access grant. When you assign a Security Group to a Security Policy, everyone in that group inherits the permissions defined by that policy.

Workday provides three main types of Security Groups you’ll use in 90% of your security configurations:

Role-Based Security Groups

What They Are:
Role-Based Security Groups automatically include workers based on their assigned role in Workday. Common examples include HR Partner, Payroll Partner, Benefits Partner, Recruiter, and Compensation Partner.

How They Work:
When you assign a worker the role “HR Partner” for a specific Supervisory Organization, they automatically become a member of the HR Partner security group for that organization. The membership is dynamic and updates automatically when role assignments change.

Common Use Cases:

• HR Partners: View and modify worker data for their assigned organizations
• Payroll Partners: Process payroll and view compensation data
• Benefits Partners: Manage benefit enrollments and eligibility
• Recruiters: Manage requisitions, candidates, and hiring workflows
• Compensation Partners: Run compensation reviews and approve merit increases

Key Configuration Points:

• Roles are assigned using the Assign Roles task
• You can assign roles at the Supervisory Organization level (most common) or at the Company, Cost Center, or Custom Org level
• Role assignments can be future-dated to prepare for upcoming org changes or leadership transitions
• Membership in Role-Based Security Groups updates automatically based on current role assignments

Example:
Sarah is assigned the “HR Partner” role for the Engineering Supervisory Organization. She automatically becomes a member of the “HR Partner” security group. Through domain security policies, she can now view and modify worker data for all employees in the Engineering organization and its subordinate orgs.

User-Based Security Groups

What They Are:
User-Based Security Groups contain specific, manually assigned users. Membership is explicit and doesn’t change unless you manually add or remove users.

How They Work:
You create a User-Based Security Group and manually add Workday users to it. These groups are perfect for administrators, integration system users, or small teams that need specific access.

Common Use Cases:

• Security Administrators: Maintain security groups and policies
• Business Process Administrators: Configure business processes and workflows
• Integration System Users (ISU): Run integrations and web services
• Report Writers: Build and maintain custom reports
• Tenant Administrators: Perform system-wide configuration and maintenance

Key Configuration Points:

• Created using the Create Security Group task
• Select User-Based as the security group type
• Add members using the Maintain Security Group Membership task
• Membership is static unless you manually update it
• Good for small, stable groups that need precise access control

Example:
You create a User-Based Security Group called “Payroll System Administrators” and manually add three payroll leads. This group gets administrative access to payroll configuration tasks and sensitive compensation data. Membership is tightly controlled and only changes when you manually add or remove users.

Workday-Delivered Security Groups

What They Are:
Workday-Delivered Security Groups are preconfigured groups that Workday automatically assigns based on worker status, employment type, or specific conditions.

How They Work:
Workday maintains these groups automatically. You cannot manually add or remove members. Workday assigns workers to these groups based on system logic.

Common Examples:

• Employee as Self: Every active employee is automatically a member. This group grants workers access to view and update their own personal information, request time off, and view their pay.
• Manager: Every worker who manages at least one direct report is automatically a member. This group grants access to approve time off, view team data, and complete manager tasks.
• All Workers: Every active worker (employees and contingent workers) is automatically a member.
• Contingent Workers: All contingent workers (non-employees) are automatically members.

Key Configuration Points:

• You cannot modify membership in Workday-Delivered groups
• Membership updates automatically based on worker status, employment type, and organizational assignments
• These groups are the foundation of self-service access in Workday
• You can use these groups in your own security policies to grant broad access

Example:
The “Employee as Self” security group is used in domain security policies to allow workers to view and modify their own contact information, emergency contacts, and personal data. When a worker is hired, they automatically join this group. When they terminate, they automatically leave it.

---

Part 2: Security Policies (WHAT They Can Do)

Security Groups define WHO gets access. Security Policies define WHAT those people can actually do. Workday has two main types of security policies:

Domain Security Policies

What They Are:
Domain Security Policies control access to data. They define which Security Groups can view, modify, or access data through web services in specific functional domains.

How They Work:
Each functional area in Workday (like Worker Data, Compensation, Benefits, Payroll) is divided into security domains. A domain represents a specific slice of data or functionality. Domain Security Policies grant Security Groups permission to Get (view/read) or Put (modify/write) data in those domains.

Key Permission Types:

• Get (View): Allows users to view data in reports, tasks, and UI screens
• Modify: Allows users to update existing data
• Put (Web Service): Allows integrations to read data via web services (used by ISUs)
• Put (Web Service – Modify): Allows integrations to write/update data via web services

Common Domains:

• Worker Data: Personal Information (name, address, contact info)
• Worker Data: Employment Information (hire date, termination date, job history)
• Worker Data: Compensation (salary, bonuses, pay rates)
• Worker Data: Benefits (enrollments, coverage, dependents)
• Worker Data: Time Off (balances, requests, accruals)
• Worker Data: Payroll (earnings, deductions, tax data)
• Worker Data: Organization Assignments (Supervisory Org, Cost Center, Location)

How to Configure:

1. Navigate to Create Domain Security Policy
2. Select the Domain (e.g., Worker Data: Personal Information)
3. Add Security Groups and assign permissions:
   • View: Which groups can see this data?
   • Modify: Which groups can change this data?
4. Configure Scope: Does this apply to all workers, or only workers in specific organizations?
5. Activate the policy using Activate Pending Security Policy Changes

Example:
You create a Domain Security Policy for “Worker Data: Compensation.” You grant the Payroll Partner security group Get (View) and Modify permissions. You configure the scope so Payroll Partners can only view and modify compensation data for workers in their assigned Supervisory Organizations. Now Payroll Partners can process pay changes for their orgs but cannot see compensation data for other parts of the company.

Business Process Security Policies

What They Are:
Business Process Security Policies control access to workflow steps. They define which Security Groups can initiate, approve, view, or cancel specific business processes.

How They Work:
Every business process in Workday (like Hire Employee, Change Job, Request Time Off, Terminate Employee) has security policies that control who can perform each step in the workflow.

Key Permission Types:

• Initiate: Who can start this business process?
• Approve: Who can approve this business process at each step?
• View: Who can see in-progress or completed business processes?
• Cancel: Who can cancel an in-progress business process?
• Rescind: Who can rescind a completed business process?

Common Business Processes:

• Hire Employee (onboarding new workers)
• Change Job (promotions, transfers, org changes)
• Request Compensation Change (salary adjustments, bonuses)
• Request Time Off (vacation, sick leave)
• Terminate Employee (offboarding)
• Change Benefits (enrollment updates)

How to Configure:

1. Navigate to View Business Process
2. Search for the business process (e.g., “Hire Employee”)
3. Click Security Policy Configuration
4. Define which Security Groups can Initiate, Approve, View, and Cancel
5. Configure approval routing logic (who approves at each step?)
6. Activate changes using Activate Pending Security Policy Changes

Example:
For the “Request Time Off” business process, you configure:

• Initiate: Employee as Self (workers can request their own time off)
• Approve: Manager (workers’ direct managers approve time off requests)
• View: Employee as Self, Manager, HR Partner (workers, managers, and HR can view requests)

Now workers can submit time off requests, managers approve them, and HR can track all requests across the organization.

Part 3: Functional Areas (WHERE It Applies)

Security Groups and Security Policies work together within specific Functional Areas. There are two main types:

Domains (Data Access)

Domains define WHERE data access permissions apply. Each domain represents a specific category of data in Workday.

How Domains Work:

• Workday organizes data into functional domains (Personal Information, Compensation, Benefits, Payroll, etc.)
• Domain Security Policies grant Security Groups access to specific domains
• You can scope domain access by organization (e.g., HR Partners can only see workers in their assigned orgs)

Example Domains:

• Worker Data: Personal Information (name, DOB, address, contact info)
• Worker Data: Employment Information (hire date, job history, position)
• Worker Data: Job (Job Profile, Worker Type, Time Type)
• Worker Data: Organizations (Supervisory Org, Cost Center, Location, Company)
• Worker Data: Compensation (salary, pay rate, bonuses, allowances)
• Worker Data: Stock (equity grants, vesting, exercise)
• Worker Data: Benefits (enrollments, dependents, coverage)

Scoping Domain Access:
When you configure a Domain Security Policy, you can limit access by organization. For example:

• HR Partners can view Worker Data: Personal Information for workers in their assigned Supervisory Organizations only
• Payroll Partners can view Worker Data: Compensation for workers in their assigned Cost Centers only
• Benefits Partners can view Worker Data: Benefits for workers in their assigned Companies only

This scoping prevents users from seeing data outside their area of responsibility.

Business Processes (Workflow Steps)

Business Processes define WHERE workflow permissions apply. Each business process represents a specific transaction or workflow in Workday.

How Business Processes Work:

• Workday organizes workflows into business processes (Hire, Terminate, Change Job, etc.)
• Business Process Security Policies grant Security Groups permission to initiate, approve, view, or cancel specific processes
• You can configure approval routing logic to send transactions to the right approvers

Example Business Processes:

• Hire Employee (onboard new workers)
• Change Job (promotions, transfers, org changes, compensation updates)
• Request Time Off (vacation, sick leave, personal days)
• Terminate Employee (offboarding)
• Request Compensation Change (merit increases, bonuses, allowances)
• Change Benefits (enrollment updates during open enrollment or qualifying events)
• Add Additional Job (assign workers to secondary positions)

Approval Routing:
Business Process Security Policies define approval routing logic:

• Step 1: Manager approval
• Step 2: HR approval (if job change involves promotion or grade change)
• Step 3: Finance approval (if compensation change exceeds threshold)

Each step can have different approvers based on conditions (e.g., only route to Finance if salary increase is greater than 10%).

---

The Biggest Mistake: Permission Sprawl

Here’s the mistake I see in almost every Workday tenant:

Someone needs access to something. Security is locked down. The request comes to the Workday admin team: “Can you give Sarah access to view compensation data for her team?”

The admin creates a new User-Based Security Group, adds Sarah, and grants it access through a Domain Security Policy.

Problem solved.

Three months later: “Can you give John the same access?”

The admin adds John to Sarah’s group.

Six months later: “Can you give the entire Compensation team this access?”

The admin creates another group for the Compensation team and grants it the same access.

One year later: “Why does Sarah still have access? She moved to a different role six months ago.”

The admin forgot to remove her from the original group.

This is permission sprawl. Multiple security groups granting overlapping access. No clear ownership. No documentation. No audit trail. And eventually, no one knows who has access to what or why.

---

3 Moves to Prevent Permission Sprawl

Move 1: Use Intersection Security Groups for AND Logic

The Problem:
You need to grant access to users who belong to MULTIPLE groups. For example: “Only users who are BOTH HR Partners AND Benefits Partners should be able to approve benefits waivers.”

The Wrong Way:
Create a third security group, manually add users who have both roles, and hope you remember to update it when role assignments change.

The Right Way:
Use an Intersection Security Group.

How It Works:
An Intersection Security Group automatically includes users who are members of ALL specified security groups. It’s an AND condition.

Example:
You create an Intersection Security Group called “HR and Benefits Partners.” You configure it to include users who are members of:

• HR Partner security group AND
• Benefits Partner security group

Only users who have BOTH roles are automatically included. If a user loses one role, they automatically drop out of the Intersection group. No manual maintenance required.

How to Configure:

1. Navigate to Create Security Group
2. Select Intersection as the security group type
3. Add the security groups to intersect (e.g., HR Partner, Benefits Partner)
4. Save the group
5. Use this Intersection group in your security policies

This keeps your security configuration clean, automated, and self-maintaining.

Move 2: Treat Activate Pending Security Policy Changes Like a Deployment Step

The Problem:
You create a new Domain Security Policy. You configure all the permissions. You test it in your Implementation tenant. It works perfectly. You promote it to production. You recreate the exact same configuration. But nothing changes. Users still don’t have access.

What happened?

You forgot to Activate Pending Security Policy Changes.

How Workday Security Activation Works:
When you create or modify security policies in Workday, changes are saved in a pending state. They do NOT take effect until you explicitly activate them using the Activate Pending Security Policy Changes task.

This is intentional. It lets you stage multiple security changes, review them together, and activate them all at once during a maintenance window.

But it’s also the source of massive confusion.

The Right Way:
Treat Activate Pending Security Policy Changes like a deployment step. Add it to your change management checklist:

1. Create or modify security policies
2. Test access in Implementation tenant
3. Document changes in your security runbook
4. Promote to Production
5. Recreate security changes in Production
6. Navigate to Activate Pending Security Policy Changes
7. Review pending changes
8. Click OK to activate
9. Validate access with end users

Pro Tip:
Schedule security activations during off-peak hours (e.g., 6:00 PM on Friday). Security activations can temporarily impact performance for large tenants.

Move 3: Use Future-Dated Role Assignments to Prep for Reorgs

The Problem:
Your company is restructuring. On January 1st, 500 workers are moving to new Supervisory Organizations with new managers. Those new managers need HR Partner access for their new teams. But you can’t grant it until January 1st because the org structure hasn’t changed yet.

So you plan to log in at midnight on New Year’s Eve to manually assign 20 new HR Partner roles.

There’s a better way.

The Right Way:
Use future-dated role assignments.

How It Works:
When you assign a role using the Assign Roles task, you can specify an Effective Date. The role assignment doesn’t take effect until that date. On the effective date, Workday automatically activates the role and grants access.

Example:
On December 15th, you assign the “HR Partner” role to 20 new managers for their upcoming Supervisory Organizations. You set the Effective Date to January 1st. On January 1st at midnight, Workday automatically:

• Activates the role assignments
• Adds the new managers to the HR Partner security group
• Grants them access to view and modify worker data for their new teams

No manual intervention required. No midnight deployments. No forgotten role assignments.

How to Configure:

1. Navigate to Assign Roles
2. Select the worker (future manager)
3. Select the role (HR Partner)
4. Select the organization (Supervisory Org they’ll manage)
5. Set Effective Date to the date the org change takes effect (e.g., January 1st)
6. Submit and approve the role assignment
7. On January 1st, the role activates automatically

This keeps your security configuration aligned with org changes and eliminates manual, time-sensitive access grants.

---

Quick Security Audit Checklist

Run this audit quarterly to keep your Workday security clean and compliant:

✅ What Changed Recently in Access?

Task: Security History for Users Audit
What It Does: Shows all security changes for specific users over a date range
Why It Matters: Helps you track who gained or lost access and when

How to Use It:

1. Navigate to Security History for Users Audit
2. Enter a Worker or leave blank to see all changes
3. Set From Date and To Date (e.g., last 90 days)
4. Run the report
5. Review changes: new security group memberships, removed access, role assignments

Red Flags to Watch For:

• Users gaining access to sensitive domains (Compensation, Payroll) without proper approval
• Terminated users still appearing in active security groups
• Integration System Users (ISUs) gaining broad administrative access

✅ Where Is Access Coming From?

Review Membership Overlaps and Intersections

What to Check:

• Which security groups does a user belong to?
• Are they members of multiple groups granting overlapping access?
• Are Intersection groups configured correctly?

How to Check:

1. Navigate to View Worker
2. Select a worker
3. Go to Security Profile or Related Actions > Security > View Security Groups
4. Review all security groups the worker belongs to
5. Identify overlaps (e.g., member of both “HR Partner” and “Payroll Partner”)

Why It Matters:
Overlapping memberships can grant unintended access. For example, if a user is in both “HR Partner” (view compensation) and “Payroll Partner” (modify compensation), they may have more access than intended.

✅ Are Integrations Over-Permissioned?

Keep ISSG/ISU Permissions Minimal and Explicit

The Problem:
Integration System Users (ISUs) often get granted broad “Super User” access during implementation to “make things work.” After go-live, no one reviews or tightens the permissions. Now your integrations have access to far more data than they need, creating security and compliance risk.

The Right Way:
ISUs should have minimal, explicit permissions for only the domains and business processes they actually use.

How to Audit ISU Access:

1. Navigate to View Integration System
2. Select an Integration System User
3. Review Security Group Memberships
4. Navigate to Domain Security Policies and check which domains the ISU can access
5. Ask: “Does this integration NEED access to this domain?”

Red Flags:

• ISU has access to Worker Data: Compensation but the integration only reads name and email
• ISU has access to Worker Data: Payroll but the integration only exports headcount
• ISU has Modify permissions but the integration is read-only

The Fix:

• Create a dedicated ISSG (Integration System Security Group) for each integration
• Grant only the domains and permissions the integration needs
• Remove broad “System Administrator” or “Super User” access
• Document ISU permissions in your integration runbook

---

Common Workday Security Tasks

Here are the key tasks you’ll use to configure and maintain Workday security:

Security Group Management:

• Create Security Group (build new User-Based or Intersection groups)
• Maintain Security Group Membership (add or remove users from User-Based groups)
• View Security Group (review group membership and configuration)

Security Policy Configuration:

• Create Domain Security Policy (grant access to data domains)
• Edit Domain Security Policy (modify existing domain policies)
• View Business Process (configure business process security and approval routing)
• Activate Pending Security Policy Changes (activate all pending security changes)

Role Management:

• Assign Roles (assign Role-Based Security Group membership to workers)
• Remove Role Assignment (remove role-based access)
• View Role Assignments (see which workers have which roles)

Security Auditing:

• Security History for Users Audit (track security changes over time)
• View Security Groups (see all groups a user belongs to)
• Security Administration (search and manage all security groups and policies)

---

Final Thoughts

Workday security isn’t complicated. It’s just unforgiving.

When you understand the 3-part mental model (WHO, WHAT, WHERE), security stops being mysterious:

• Security Groups define WHO gets access
• Security Policies define WHAT they can do
• Functional Areas (Domains and Business Processes) define WHERE it applies

Use this framework to build clean, maintainable security configurations:

• Use Role-Based Security Groups for organizational access (HR Partners, Payroll Partners)
• Use User-Based Security Groups for administrators and small teams
• Use Intersection Security Groups for complex AND logic
• Grant minimal, explicit permissions through Domain and Business Process Security Policies
• Always activate changes using Activate Pending Security Policy Changes
• Audit security quarterly to prevent permission sprawl

Get security right from day one, and your Workday tenant stays clean, compliant, and easy to maintain. Get it wrong, and you’ll spend years untangling overlapping permissions and shadow access.

Start simple. Stay disciplined. Document everything.

---

Note: This article represents original content based on Workday HCM security configuration experience and publicly available Workday documentation. All examples and scenarios are written from practical implementation experience.

---