Workday security can either be your best ally or your biggest blocker. Done well, it protects sensitive worker data end‑to‑end while giving HR and managers everything they need to do their jobs. Done poorly, it leads to “access denied” screens, shadow spreadsheets and risky workarounds. Designing hire‑to‑retire security means aligning Role‑Based Security, Domain Security and Business Process Security with each stage of the employee lifecycle.
This playbook covers how to structure security groups and domains so you protect data without blocking HR.
Understand the Workday security building blocks
Before designing anything, get clear on the main Workday security components:
Security Groups – collections of users that share permissions. Common types:
Role‑Based Security Groups (RBSGs) – tied to roles like HR Partner, Manager, Payroll Admin.
User‑Based Security Groups – assigned directly to specific people (often admins).
Segment‑Based / Dynamic Groups – driven by attributes such as Company or Location.
Domain Security Policies – control access (view, modify, report, integration) to data in domains (for example, Worker Data: Personal, Worker Data: Compensation).
Business Process Security Policies – control who can initiate, approve, review or cancel steps in Business Processes like Hire, Change Job, Terminate.
At a high level:
Domains protect what data you can see or change.
Business Process policies protect what actions you can take.
Security Groups are who gets those rights.
Design hire‑to‑retire roles first, not screens
Start with lifecycle stages, not menu items. A typical hire‑to‑retire journey includes: Recruit → Hire → Onboard → Move/Promote → Leave/Return → Terminate → Post‑termination updates.
Map key roles across that journey:
Recruiter / Talent Partner – owns candidate and requisition data.
Payroll / Benefits / Time / Absence Admins – own their functional data and processes.
IT / Identity / Security admins – consume worker data for provisioning and access.
Then design Role‑Based Security Groups that align to these real‑world roles, not to individuals. For example:
“HR Partner – Country A”
“Recruiter – Global”
“Manager” (delivered)
“Payroll Admin – US”, “Benefits Admin – EU”
Each role should have a clear purpose and defined scope (global vs regional).
Domain security: protect the right slices of worker data
Workday ships with many domains such as Worker Data: Personal, Worker Data: Compensation, Worker Data: Benefits, Worker Data: Time Off, and more.
Good domain design practices:
Apply the principle of least privilege: give each security group only the View or Modify access actually needed.
Example: HR Partners may view and update most worker data in their region, but not global tenant‑wide comp or audit logs.
Managers see limited worker data for their direct and indirect reports, not for all workers.
Use separation of duties:
Keep Payroll Admin and Compensation Admin rights distinct where compliance demands it.
Avoid “super‑roles” that can see everything unless strictly necessary (for example, HCM Admin).
Remember reports and integrations use domains too. If a security group can view a domain, they can also see that data via reports or downstream integrations.
From a hire‑to‑retire perspective, your domain policies should answer:
What personal data can managers see at different points (e.g., emergency contacts, home address)?
What comp data can HR, managers and employees see (current, history, others’ pay)?
Who can view or update sensitive data like national IDs, bank accounts or medical details?
Business process security: keep workflows flowing
Even if domain access is correct, users can still be blocked if Business Process Security Policies are misaligned.
Key concepts:
Initiating Security Groups – who can start a process like Hire, Change Job, Propose Compensation, Terminate.
Approval / Review / FYI Steps – which security groups approve or are notified at each step.
Best practices:
Avoid having more than a handful of Initiating Security Groups per business process; too many initiators is a sign of poor design.
Keep approval chains clear and role‑based: for example, Manager → HR Partner → Compensation Partner for promotions involving pay.
Use conditions for steps that only apply in certain countries or scenarios instead of creating multiple parallel processes.
A hire‑to‑retire journey should feel seamless:
Recruiters can open and move candidates through requisitions.
HR can complete hires and changes without raising tickets for extra permissions.
Managers can initiate changes they are responsible for, like transfers or time off approvals.
If users are constantly blocked at steps, review your Business Process security alongside domains.
Lifecycle‑aligned security patterns
Security must adapt as workers move through stages. A few patterns:
Pre‑hire / Candidate
Limit access to candidate PII to Recruiters and HR; managers see only what they need for selection.
Use domains like Pre‑Hire Data and recruiting‑specific security groups.
Hire / Onboarding
Ensure HR Partners can create and update core worker data, while managers complete onboarding tasks without seeing unnecessary personal data.
Integrations (for example, to Active Directory) should read only the attributes they need from worker domains.
Active employment
Managers see team data (job, comp summary where appropriate, time / absence, performance) but not full sensitive details.
HR sees full worker profiles within their scope (region/company).
Leave / LOA
Limit access to specific leave‑related details where privacy laws require it (for example, medical details).
Absence Admins may see more than line managers.
Termination and post‑termination
Managers may lose access to full details after termination while HR retains access for compliance and audit.
IT / Identity integrations must de‑provision system access based on worker status changes.
This lifecycle view ensures you do not accidentally leave ex‑managers with access to former employees’ data or block HR from maintaining records after terminations.
Monitoring, audits and continuous tuning
Security is not “set and forget”. Regular reviews catch drift and excessive access.
Key practices:
Quarterly or semi‑annual security reviews
Review high‑privilege security groups: who is in them, what domains they can access.
Check for user‑based assignments that should be role‑based instead.
Access certification and SoD reviews
Validate that admin roles (HCM Admin, Payroll Admin, Integration System User) are restricted and still required.
Check segregation of duties, especially where finance and HR data intersect.
Logging and anomaly detection
Use Workday’s audit logs plus external security tools where appropriate to monitor unusual access patterns.
Align these reviews with changes in your org structure, compliance obligations and new module rollouts.
Keeping HR unblocked while staying secure
The goal is not maximum restriction; it is the right restriction. To keep HR productive:
Design HR Partner roles that are powerful within a scoped region or company, not globally unrestricted.
Use delegations and backup roles so vacations or absences do not stall business processes.
Train HR and managers on “what you can see and why” to reduce confusion and tickets.
When HR trusts that Workday security is intentional and consistent, they stop asking for “admin everywhere” and start using the system within designed guardrails.
Done right, hire‑to‑retire security in Workday feels invisible to end users: people simply see the right data, at the right time, for the right reasons. Under the hood, well‑designed Role‑Based Security Groups, Domain Security Policies and Business Process Security protect worker data while keeping HR and managers moving.
Last month, I was troubleshooting what seemed like a simple issue for a client.
Their HR Director needed the Monthly Turnover Analysis—a report she’d been using reliably for six months to present workforce trends to the executive team.
She couldn’t find it.
We opened the Report Writer. We searched “turnover.” We searched “termination.” We searched “attrition.”
Thirty minutes later, we’d found six different reports:
Turnover_Report_New
Turnover_Final
Employee_Turnover_v2
Monthly_Attrition_COPY
Terminations_Report_Final_FINAL
HR_Report_Dec_v3
All six did roughly the same thing—pulled termination data by department and calculated monthly rates.
None of them had clear names. None of them listed an owner. Three were duplicates with slightly different date filters. Two hadn’t been run in over 90 days.
The one she actually needed? Terminations_Report_Final_FINAL.
We only found it by opening every single report and checking the filters until we recognized the specific business logic she’d requested six months earlier.
That’s when I understood something critical: Poor report naming conventions aren’t just an annoyance. They’re a hidden productivity tax your organization pays every single day—and most leaders have no idea it’s happening.
The Hidden Cost of Bad Report Names
When your Workday tenant is filled with reports named like:
Report_Test_2
New_Report_Copy
Benefits_Final_v3
JSmith_Report_Dec2024
Custom_Report_FINAL
Employee_Data_New_v4
You’re not creating minor inconveniences. You’re creating systemic organizational drag that compounds over time.
1. Search Paralysis: The 5-Minute Tax
Users spend an average of 5-10 minutes searching for the right report instead of finding it in 10 seconds.
Let’s do the math:
50 users searching for reports each week
Average 5 minutes wasted per search
250 minutes per week = 4.2 hours
52 weeks per year = 218 hours annually
At $50/hour average loaded cost = $10,900 in wasted labor
And that’s a conservative estimate for a mid-sized organization. Enterprise organizations with hundreds of report users can easily lose 1,000+ hours annually just to search friction.
2. Duplicate Work: The Multiplication Problem
When people can’t find the report they need, they do one of three things:
Create a new report from scratch
Copy an existing report and modify it
Ask someone else to build it for them
All three options create duplicates.
Six months later, your Workday admin needs to update the compensation calculation logic to reflect a new bonus structure.
Which of the twelve “Compensation Report” variants need updating?
Compensation_Analysis
Comp_Report_Final
Employee_Compensation_v2
Salary_Data_2024
Pay_Report_New
Compensation_JSmith_Copy
Total_Comp_FINAL
Base_and_Bonus_Report
Comp_Report_COPY_v3
Employee_Pay_Analysis
Compensation_Data_Dec
Salary_Report_Final_v2
All of them? Some of them? None of them?
Without clear naming conventions and ownership tracking, you won’t know until you open each one individually.
And if you guess wrong, someone’s compensation analysis will have incorrect data—potentially leading to bad business decisions about merit increases, equity adjustments, or market competitiveness.
3. Maintenance Nightmares: The Debt That Never Gets Paid
Technical debt in software development is well understood. Configuration debt in enterprise systems is less discussed but equally destructive.
Every poorly named report is configuration debt.
When reports are named vaguely:
Nobody knows what they do without opening them
Nobody knows who owns them
Nobody knows if they’re still being used
Nobody dares delete them (what if someone needs it?)
The result? Report portfolios that grow indefinitely.
I’ve worked with organizations that have:
500+ custom reports (30% unused for over a year)
75+ reports with “Final” in the name
50+ reports with “Copy” in the name
40+ reports with creator names (who left the company years ago)
25+ reports with “Test” in the name (still in production)
Every one of these represents work that should have been consolidated, archived, or deleted—but wasn’t, because nobody could confidently assess whether it was still needed.
4. Security Risks: The Audit You Can’t Pass
Compliance and security audits require you to demonstrate who has access to what data.
In Workday, this means reviewing report security and identifying which reports access sensitive data categories like:
Compensation and salary information
Social Security Numbers or National IDs
Performance ratings
Disciplinary actions
Medical or health information
Banking and payment details
When your reports are named “Report_Final_v3” or “Custom_Report_2024,” how do you identify which ones contain sensitive data?
You can’t—not without opening every single report and reviewing the data sources, fields, and filters manually.
During an audit, you’re asked: “Provide a list of all reports that access employee salary information and identify everyone with access to run them.”
With poor naming conventions, that’s a multi-day project involving your entire Workday admin team.
With good naming conventions, it’s a 15-minute task with a filtered search.
5. Compliance Failures: The Risk Hiding in Plain Sight
Beyond audit readiness, unclear report naming creates real compliance exposure.
Scenario: Your organization operates in multiple countries with different data privacy requirements (GDPR in Europe, CCPA in California, local regulations in APAC).
You need to ensure European employee data doesn’t flow into reports accessible to US-based managers without proper data processing agreements in place.
But when your reports are named:
Employee_Report_v2
HR_Data_Final
Worker_Information_Copy
Personnel_Report_New
How do you identify which reports pull European employee data? Which reports are geography-specific vs. global?
You can’t know from the name alone.
The result? Potential data privacy violations that expose your organization to regulatory fines, legal liability, and reputational damage.
All because you didn’t have clear, enforced report naming conventions.
What Makes a Good Report Name?
A well-constructed report name answers three critical questions instantly—without requiring you to open the report:
1. What does this report show?
Not “Benefits Report” (which benefits? elections? costs? eligibility?).
But “Employee Pre-Tax Benefits Deductions YTD”.
2. Who is this report for?
Not “Payroll_Data” (for payroll processing? reconciliation? audit?).
But “Finance Monthly Payroll Reconciliation by Cost Center”.
3. Is this report still relevant?
Not “Report_Q4” (which year? which quarter? for what purpose?).
But “2024 Q4 Bonus Eligibility Analysis – Temporary”.
Good report names are:
Specific, not generic “Active Employees by Department and Location” tells you exactly what’s inside. “Employee Report” tells you almost nothing.
Readable, not cryptic “Employee HSA Eligibility for Non-Exempt Workers” is immediately clear. “EE_HSA_Elig_FLSA_NE” requires a decoder ring.
Searchable, not obscure Use the terms your users actually search for. If everyone calls it “turnover,” don’t name it “attrition” or “separations”.
Organized, not random Following a consistent structure means users learn your naming pattern once and can navigate efficiently forever.
The Framework: Building Your Naming Convention
After implementing report governance across dozens of Workday tenants, here’s the structure that works:
This four-part structure provides clarity, organization, and scalability. Let’s break down each component.
Part 1: Prefix (Optional but Powerful)
Prefixes help you instantly identify report type, ownership, or geographic scope.
When to Use Prefixes
Global Organizations If you operate in multiple countries or regions, geographic prefixes prevent confusion about data scope:
US = United States only
UK = United Kingdom only
APAC = Asia-Pacific region
EMEA = Europe, Middle East, Africa
GLOBAL = All geographies
Example: US-HR-Compensation-Annual Merit Increases by Job Profile
This immediately signals that the report contains only US employee data—critical for data privacy compliance and preventing inappropriate cross-border data access.
Large Teams with Distributed Report Creation If multiple departments create their own reports, functional prefixes establish ownership:
HR = Human Resources owned
FIN = Finance owned
IT = Information Technology owned
OPS = Operations owned
Example: FIN-Payroll-Monthly Tax Withholding by State-Scheduled
This clarifies that Finance owns this report, meaning Finance is responsible for maintenance, security, and updates.
Custom vs. Standard Report Identification If you want to distinguish custom reports from Workday-delivered standard reports:
CR = Custom Report
STD = Standard (Workday-delivered, modified)
Example: CR-Benefits-HSA Election Changes Current Year
This signals that it’s a fully custom build, not a modified standard report, which impacts how you approach updates during Workday releases.
Temporary Report Flagging For reports with limited lifespans:
TEMP = Temporary (delete after specific event/date)
Example: TEMP-HR-2024 Annual Review Campaign Status
This prevents your tenant from becoming a graveyard of one-time reports nobody dares delete.
How to Structure Multi-Part Prefixes
If you need multiple prefix elements, use consistent ordering:
Keep prefixes short (2-6 characters each) and separate with hyphens for visual clarity.
Part 2: Functional Area (Required)
The business domain or process this report supports.
This is the most important search term users will look for. “I need a compensation report” or “I need a recruiting report” is how people think.
Standard Functional Areas
Human Resources:
Compensation
Benefits
Recruiting / Talent Acquisition
Onboarding
Performance Management
Succession Planning
Learning & Development
Employee Relations
Workforce Planning
Time Tracking / Time & Attendance
Absence Management
Offboarding / Terminations
Finance:
Payroll
Accounts Payable
Accounts Receivable
General Ledger
Budgeting
Financial Planning
Expense Management
Revenue Recognition
Asset Management
Operations:
Procurement
Supplier Management
Inventory
Project Accounting
IT & Security:
Security Audit
Access Management
Integration Monitoring
System Administration
Choose terms that match how your organization talks about these functions. If everyone calls it “Talent Acquisition,” don’t use “Recruiting” in your report names.
Why Functional Area Comes Second (After Prefix)
When users search for reports, they search by function first, then narrow down by specific purpose.
Data Type: Active Employees Qualifier: With Dependents Grouping: By Benefits Eligibility Status Time Period: Current Result: “Active Employees with Dependents by Benefits Eligibility Status”
Data Type: Open Requisitions Qualifier: Aging Over 60 Days Grouping: By Department and Hiring Manager Time Period: As of Today Result: “Open Requisitions Aging Over 60 Days by Department and Hiring Manager”
Data Type: Performance Ratings Qualifier: Ratings of 4 or Higher Grouping: By Manager and Job Profile Time Period: 2024 Annual Review Cycle Result: “Performance Ratings 4+ by Manager and Job Profile – 2024 Annual Review”
Be specific enough that a new user unfamiliar with your reports can understand exactly what’s inside without opening it.
Part 4: Suffix (Optional but Recommended)
Indicates status, time period, or special handling.
Suffixes provide critical context about how the report should be used or handled.
Common Suffix Types
Status Indicators:
Temporary = Delete after specific date/event
DRAFT = Under development, not for production use
ARCHIVED = Historical, no longer maintained
DEPRECATED = Being phased out, use alternative report
Delivery Method:
Scheduled = Automated delivery on recurring schedule
On-Demand = User-initiated only
Subscription = Users can subscribe for automatic delivery
Audience Indicators:
Executive = Restricted to executive leadership
Manager Self-Service = Available to all people managers
Public = Available to all employees
Time Period:
2024 Q4 = Time-specific report
Annual = Used once per year for annual process
Historical = Historical analysis, not current data
Suffix Examples in Context
CR-HR-2024 Annual Review Campaign Status-Temporary Signals this report tracks a specific 2024 campaign and should be deleted after the campaign concludes.
CR-Payroll-Bi-Weekly Payroll Register by Cost Center-Scheduled Indicates this report runs automatically on a schedule, so users should expect to receive it without requesting.
CR-Compensation-Executive Compensation Summary-Executive Clarifies this report contains sensitive data restricted to executive access only.
CR-Benefits-Medical Plan Costs 2020-2023-Historical Shows this is a historical analysis report, not current-year data, preventing users from making decisions based on outdated information.
Real-World Transformation Examples
Let’s look at how actual problematic report names transform using this framework.
Example 1: Compensation Report
Before: Report_Final_v3
Problems:
What does this report show? Unknown
Who is it for? Unknown
What does “Final” mean? Final version? Final calculation? Final year?
What’s “v3”? Version 3? Is there a v4?
After: CR-US-Compensation-Base Salary Changes YTD by Job Profile
Benefits:
Immediately clear it’s a custom report (CR)
Geographic scope defined (US)
Functional area identified (Compensation)
Specific content described (Base Salary Changes)
Time period specified (YTD)
Breakdown clarified (by Job Profile)
Example 2: Benefits Report
Before: Compensation_JSmith_Copy
Problems:
Is this compensation or benefits? (Probably benefits despite the name)
Why is JSmith’s name in the report? (JSmith left the company 18 months ago)
It’s a copy… of what? Why?
What does it actually show?
After: CR-Benefits-Active Employee Medical Elections by Plan and Coverage Tier
Benefits:
Functional area correctly identified (Benefits)
Population specified (Active Employees)
Benefit type clarified (Medical)
Data type defined (Elections, not costs or eligibility)
Breakdown described (by Plan and Coverage Tier)
No personal names (ownership tracked in metadata, not report name)
Example 3: Turnover Report
Before: Benefits_New_Dec
Problems:
This name suggests it’s about benefits, but it’s actually a turnover report
What does “New” mean? New hires? New report? New calculation?
“Dec” could mean December… but which year? 2022? 2023? 2024?
After: HR-Recruiting-Monthly Voluntary Terminations by Department-Scheduled
Benefits:
Functional area correctly identified (Recruiting, not Benefits)
Frequency specified (Monthly)
Type clarified (Voluntary Terminations only)
Breakdown defined (by Department)
Delivery method indicated (Scheduled, so users know to expect it automatically)
Example 4: Payroll Report
Before: Turnover_FINAL
Problems:
Extremely generic name
“FINAL” suggests there were other versions… where are they?
No indication of content, time period, or purpose
After: CR-Payroll-Bi-Weekly Payroll Register by Cost Center and Worker Type
Benefits:
Functional area identified (Payroll)
Frequency clear (Bi-Weekly, aligning with payroll schedule)
Report type specified (Payroll Register)
Two-dimensional breakdown (Cost Center AND Worker Type)
Searchable by people looking for “payroll register” or “cost center”
Example 5: HR Analytics Report
Before: HR_Report_Dec_v3
Problems:
“HR_Report” could be anything HR-related (compensation? headcount? performance?)
“Dec” = December… of which year?
“v3” = Is there a v4? Is this the current version?
After: CR-HR-Headcount by Department Location and Employment Type-2024 Q4
CR-US-HR-Compensation-Analysis-by-Job-Profile-2024 (too many hyphens blur section boundaries)
CR US HR Compensation Analysis by Job Profile 2024 (no clear section separation)
Rule 4: Standardize Prefix Length for Visual Alignment
If you’re using prefixes, keep them consistent length so report names align visually in search results.
Good Visual Alignment:
CR-HR-Compensation Analysis by Job Profile CR-HR-Benefits Elections by Coverage Type CR-HR-Performance Ratings by Manager CR-FN-Payroll Register by Cost Center CR-FN-Budget Variance by Department CR-FN-Expense Analysis by Category
The consistent “CR-XX-” prefix creates visual alignment, making it easier to scan and group related reports.
Poor Visual Alignment:
C-HR-Compensation Analysis by Job Profile CUSTOM-HR-Benefits Elections by Coverage Type CR-HR-Performance Ratings by Manager CUSTOMRPT-FN-Payroll Register by Cost Center FIN-Budget Variance by Department CR-FINANCE-Expense Analysis by Category
Inconsistent prefix lengths create visual noise and make scanning harder.
Rule 5: Mark Temporary Reports Explicitly
If a report won’t be evergreen, add “Temporary” or “TEMP” to the name and document the deletion date.
Examples:
CR-HR-2024 Annual Review Campaign Status-Temporary (delete after Feb 28, 2025)
TEMP-Finance-Q4 2024 Bonus Processing-Delete After Jan 15, 2025
CR-IT-Migration Validation Report-Temporary (delete after go-live)
This accomplishes three things:
Prevents zombie reports: Everyone knows this report has a limited lifespan
Enables confident deletion: When the date arrives, admins can delete without fear
Reduces clutter: Temporary reports don’t pollute your permanent report catalog
Pro Tip: Set a calendar reminder for the deletion date, or use Workday’s business process to request report deletion automatically.
Rule 6: Never Use Version Numbers in Report Names
Avoid “v2,” “v3,” “Final,” “New,” or any version indicators in report names.
Why?
Workday automatically tracks report change history. You can view previous versions, compare changes, and restore prior versions directly from Report Writer.
Version numbers in names create confusion:
Is “Report v3” the current version, or is there a v4 somewhere?
If you update “Report v3,” do you rename it “Report v4”?
What happens to users who bookmarked “Report v2”?
Instead of versioning in names, use Workday’s built-in version control:
Make changes to the existing report
Workday automatically creates a version history
Users always get the current version when they run the report
Admins can review change history and see who made what changes when
Exception: If you genuinely need multiple versions to coexist (e.g., different calculation methodologies for comparison), differentiate by purpose, not version number:
CR-Compensation-Total Compensation Including Equity Value
CR-Compensation-Total Compensation Excluding Equity Value
Rule 7: Avoid Vague Terms That Add No Information
Generic words like “Report,” “Data,” “New,” “Final,” or “Custom” typically add zero value.
Replace vague terms with specific details:
❌ Benefits Report → ✅ Employee Medical Plan Elections by Coverage Tier ❌ Payroll Data → ✅ Bi-Weekly Payroll Register by Cost Center ❌ Turnover Report → ✅ Voluntary Terminations Last 12 Months by Department ❌ New Headcount Report → ✅ Active Employees by Department Location and Worker Type ❌ Final Compensation Report → ✅ Annual Merit Increase Recommendations by Job Profile
Every word in your report name should add meaning.
The Deletion Test
If you can remove a word from your report name without losing information, delete it.
“Custom Benefits Report Final” → Delete “Custom” (all reports in this category are custom) → Delete “Report” (obviously it’s a report) → Delete “Final” (meaningless modifier) → What remains? “Benefits”… which tells you almost nothing.
Start over: “Employee Medical Dental and Vision Elections Current Year” – every word adds information.
Governance: Making Naming Conventions Stick
A documented naming convention is worthless if nobody follows it. Enforcement requires governance.
1. Create a Report Naming Standards Document
Document your naming convention in a formal standards guide accessible to anyone who creates reports.
Your standards document should include:
Required Structure and Format
The 4-part naming template with descriptions
Separator usage rules
Title case requirements
Character limits (if any)
Approved Prefixes and Their Meanings
Complete list of allowed prefixes
When to use each prefix
How to request new prefixes
Functional Area List
Standardized functional area names
Mapping to organizational departments
Who owns each functional area
Suffix Guidelines
When to use suffixes
Approved suffix terms
Special handling for temporary reports
Examples (Good and Bad)
10+ real examples of well-named reports
10+ examples of poorly named reports with explanations of what’s wrong
Before/after transformations
Process for Requesting Exceptions
When exceptions might be warranted
Who approves exceptions
How to document approved exceptions
Make this document accessible via:
Workday tenant home page
Report Writer help resources
New hire onboarding materials
Report writer training curriculum
Review and update this document annually to ensure it stays current with organizational changes.
2. Establish a Report Approval Workflow
Don’t allow anyone to create custom reports without review.
Approval workflow should include these checkpoints:
Business Owner Sign-Off
Confirms genuine business need (prevents duplicate reports)
Verifies report doesn’t already exist
Commits to ongoing ownership and maintenance
Defines report lifecycle (evergreen vs. temporary)
Data Steward Review
Confirms appropriate data sources
Validates security domain configuration
Ensures data privacy compliance
Reviews field selection for sensitivity
Workday Admin Validation
Confirms naming convention compliance
Checks for performance optimization
Reviews calculated field necessity
Validates against existing report portfolio
Final Approval Authority
Workday Center of Excellence lead
IT Governance Board
HR Operations Director
Reporting Manager (depending on organization size)
Workflow Example:
Requestor submits report request with business justification
Business owner reviews and approves need
Data steward confirms data appropriateness
Workday admin builds report following naming standards
Business owner tests report and confirms accuracy
Admin assigns security and publishes report
Report added to governance catalog with owner, purpose, and review date
Large organizations should implement a Change Control Board or Reporting Center of Excellence to manage this process centrally.
3. Assign Report Owners
Every custom report needs a designated owner responsible for its lifecycle.
Report Owner Responsibilities:
Periodic Review (at least annually)
Confirm report is still needed
Verify data sources are still appropriate
Test report accuracy after Workday releases
Update business logic when processes change
Maintenance
Apply updates when business rules change
Modify filters when organizational structure changes
Update field selections when new data becomes available
Respond to user questions and issues
Compliance Certification
Confirm security domains are still appropriate
Verify data privacy compliance
Validate audit trail requirements
Review field-level security settings
Deletion Responsibility
Proactively delete report when no longer needed
Archive historical data if required before deletion
Communicate deletion to stakeholders
Document deletion rationale
How to Track Ownership:
In Workday Report Metadata:
Use the Description field to document owner name and contact
Include ownership in report tags
Reference owner in scheduled delivery settings
In External Governance System:
Maintain report catalog in SharePoint, Confluence, or similar
Link reports to organizational roles (not individuals)
Track ownership transitions when people change roles
Example Description Field:
Report Owner: Director of HR Operations (Jane Smith) Purpose: Monthly voluntary turnover analysis for executive leadership Review Frequency: Quarterly Last Review Date: Dec 15, 2024 Next Review Date: March 15, 2025 Scheduled for Deletion: No (evergreen report)
4. Audit Existing Reports Quarterly
Set up a recurring governance task to review your report portfolio.
Quarterly Audit Checklist:
Identify Unused Reports
Pull reports not run in 90+ days
Contact owners to confirm still needed
Mark for deletion if no longer required
Archive if historical reference needed
Flag Naming Convention Violations
Search for reports with “test,” “copy,” “final,” “new” in names
Search for reports with version numbers (v2, v3, etc.)
Search for reports with personal names (JSmith, MJones, etc.)
Prioritize high-use reports for renaming
Find Duplicate Reports
Group reports by functional area
Review similar names for potential duplicates
Open suspected duplicates and compare data sources, fields, and filters
Consolidate when duplicates confirmed
Review Reports Without Clear Owners
Identify reports where owner has left organization
Identify reports created by generic admin accounts
Assign new owners or mark for deletion
Assess Security Compliance
Review reports accessing sensitive data (compensation, SSN, performance)
Validate security domain assignments
Confirm appropriate access levels
Document any compliance gaps for remediation
Most organizations discover 30-40% of custom reports are unused during their first audit.
That’s not a failure—it’s an opportunity to reduce clutter, improve performance, and focus maintenance efforts on reports that actually create value.
5. Train Every Report Writer
Make naming convention training mandatory for anyone with report creation permissions.
Cost of poor naming (wasted time, duplicates, compliance risks)
Benefits of consistent naming
Organizational commitment to governance
Module 2: Your Organization’s Naming Structure (30 minutes)
The 4-part framework with examples
Approved prefixes and when to use them
Functional area standardization
Suffix guidelines
Title case and separator rules
Module 3: How to Search for Existing Reports (20 minutes)
Search strategies to find reports before creating new ones
Using filters and categories
Reading report names to understand content
When to copy existing vs. create new
Module 4: Report Request and Approval Process (15 minutes)
How to submit report requests
Approval workflow stages
Expected turnaround time
Ownership responsibilities
Module 5: Hands-On Practice (30 minutes)
Rename 10 poorly named reports
Create report names from business requirements
Identify naming convention violations
Search for and evaluate existing reports
Deliver training:
During new hire onboarding (for anyone who will create reports)
During Workday release cycles (as a refresher)
When granting report creation permissions
Annually as a governance refresher
Create a Quick Reference Guide (1-page PDF) with:
Naming template
Common prefixes and suffixes
Good vs. bad examples
Link to full standards document
Make this available in Report Writer as a help resource.
Migration Strategy: Fixing Your Existing Report Mess
You can’t rename 500 reports overnight. Attempting to do so will create chaos, broken links, and angry users who can’t find their reports.
Here’s a phased approach that minimizes disruption:
Phase 1: Document Current State (Week 1)
Task 1.1: Export Complete Report Inventory
Export all custom reports with names, owners, last run date, and run count
Include report type (Simple, Advanced, Matrix, Composite)
Capture security domain assignments
Document scheduled delivery settings
Task 1.2: Analyze Usage Patterns
Sort by last run date
Sort by run count (last 90 days)
Identify reports run weekly or more frequently
Identify reports not run in 90+ days
Identify reports not run in 180+ days
Task 1.3: Flag Problematic Names
Reports containing “test,” “copy,” “final,” “new”
Reports with version numbers (v2, v3, etc.)
Reports with personal names (JSmith, MJones, etc.)
Reports with vague names (“Report_1”, “Employee_Data”, “Custom_Report”)
Reports with generic functional names only (“Benefits”, “Compensation”, “Payroll”)
Task 1.4: Identify Duplicates
Group by functional area and look for similar names
Compare data sources and fields for suspected duplicates
Flag duplicate clusters for consolidation
Deliverable: Spreadsheet with complete report inventory, usage data, and problem flags
Phase 2: Prioritize High-Impact Reports (Week 2)
Not all reports are equally important. Focus your initial efforts on high-visibility, high-impact reports.
Priority 1: Executive and Board Reports
Reports used by C-suite or board of directors
Reports for external compliance or regulatory filing
Reports that feed into investor communications
Why first: These reports have the highest organizational visibility and compliance risk
Priority 2: Scheduled and Shared Reports
Reports with automated delivery schedules
Reports shared across multiple departments
Reports embedded in business processes
Why second: These reports have the most dependencies and users who need to be notified of name changes
Priority 3: High-Frequency Reports
Reports run daily or weekly
Reports used by large user populations
Reports critical to operational processes
Why third: These reports impact the most users most frequently
Priority 4: Department-Specific Reports
Reports used by single departments
Reports run monthly or less frequently
Reports with small user populations
Why fourth: Lower impact; can be renamed in later phases
Priority 5: Ad-Hoc and Temporary Reports
Reports created for one-time analyses
Reports not run in 90+ days
Reports marked as temporary
Why last: May be candidates for deletion instead of renaming
Deliverable: Prioritized list of reports grouped into 4-5 renaming batches
Phase 3: Rename in Batches (Weeks 3-8)
Rename reports in waves, communicating each batch before making changes.
Batch 1: Executive and Compliance Reports (Week 3)
20-30 reports maximum
Highest importance and visibility
Communicate changes to executive assistants and direct users 1 week before
Rename reports
Update any bookmarks, links, or documentation
Send confirmation after renaming with old → new name mapping
Batch 2: Scheduled and Shared Reports (Week 4-5)
40-60 reports maximum
Update scheduled delivery settings with new names
Communicate to distribution lists 1 week before
Rename reports
Monitor first scheduled run to ensure delivery works
Send confirmation with name mapping
Batch 3: High-Frequency Reports (Week 6-7)
50-80 reports maximum
Communicate to functional area leads 1 week before
Rename reports
Update training materials and help documentation
Send confirmation with name mapping
Batch 4: Department-Specific Reports (Week 8)
100-150 reports maximum
Communicate to department admins and power users
Rename reports
Send confirmation with name mapping
Communication Template:
Subject: Workday Report Names Changing on [Date] – Action Required
We are improving Workday report organization by implementing clear, consistent naming conventions.
On [Date], the following reports will be renamed:
OLD NAME → NEW NAME --------------------------------------- Report_Final_v3 → CR-US-Compensation-Base Salary Changes YTD by Job Profile Benefits_Report_Copy → CR-Benefits-Active Employee Medical Elections by Plan Turnover_Data → HR-Recruiting-Monthly Voluntary Terminations by Department
What This Means for You: • Report content and data are unchanged • Search for the NEW NAME after [Date] • Update any saved links or bookmarks • Report security and delivery schedules remain the same
Why We're Making This Change: [Brief explanation of naming convention benefits]
Questions? Contact [Workday Admin Team]
Phase 4: Delete Unused Reports (Week 9)
Reports not run in 180+ days are strong candidates for deletion.
Before Deleting:
Contact Report Owners
Email owners of unused reports
Confirm report is no longer needed
Offer to archive data if needed for historical reference
Check for Annual or Cyclical Use
Some reports are only used during annual processes (year-end, annual reviews, open enrollment)
Check if last run date aligns with annual cycle
If annual, add suffix “Annual” and retain
Export Report Definitions
Save report XML definitions before deleting
Store in secure location (SharePoint, network drive)
Document deletion in governance log
Communicate Pending Deletions
Send notification 2 weeks before deletion
Include report name, last run date, and reason for deletion
Provide escalation path if someone still needs the report
Delete in Batches
Delete 20-30 reports at a time
Monitor for complaints or restoration requests
Document deletions in governance log
Deletion Communication Template:
Subject: Unused Workday Reports Scheduled for Deletion on [Date]
The following Workday reports have not been run in over 180 days and are scheduled for deletion on [Date]:
REPORT NAME | LAST RUN DATE | OWNER --------------------------------------- Employee_Report_v2 | March 15, 2024 | Jane Smith Benefits_Old_Copy | January 8, 2024 | Unassigned Turnover_Test_3 | April 22, 2024 | John Doe (no longer with company)
If you still need any of these reports: 1. Reply to this email by [Date - 1 week] 2. Provide business justification for keeping the report 3. Confirm you will be the ongoing owner
Reports will be archived before deletion and can be restored if needed within 30 days.
Questions? Contact [Workday Admin Team]
Phase 5: Implement Governance (Week 10+)
With your report portfolio cleaned up, implement ongoing governance to prevent regression.
Launch:
Report approval workflow for new reports
Naming standards document published
Report owner assignment process
Quarterly audit schedule
Training program for new report writers
Measure Success:
% of reports following naming conventions (target: 95%+)
Average time to find reports (target: <30 seconds)
of duplicate reports created (target: <5% of new reports)
% of reports with assigned owners (target: 100%)
% of reports run in last 90 days (target: 70%+)
Continuous Improvement:
Review naming standards annually
Solicit feedback from report users
Update standards based on organizational changes
Celebrate successes (reduced search time, fewer duplicates)
The Template: Your Naming Convention Cheat Sheet
Copy this structure and customize for your organization:
CR-Learning-Compliance Training Completion Status by Course
CR-Learning-Overdue Learning Assignments by Manager
CR-Learning-Learning Hours by Job Family-2024 Q4
Workforce Planning:
CR-HR-Active Employees by Department Location and Worker Type
CR-HR-Headcount by Cost Center-Monthly-Scheduled
CR-HR-New Hires Last 90 Days by Hire Reason
Security & Audit:
CR-IT-Security Group Membership by Worker-Monthly-Scheduled
CR-IT-Inactive Users with System Access-Security Audit
CR-IT-Security Policy Changes Last 30 Days
What This Means for Your Organization
Poor report naming conventions create real business costs:
Wasted time searching
Duplicate work
Maintenance complexity
Security risks
Compliance exposure
Good report naming conventions create real business value:
Users find reports in seconds
Zero duplicate work
Simple maintenance
Clear security boundaries
Audit readiness
Start your transformation today:
Week 1: Export your current report inventory and assess the damage Week 2: Define your naming standard using this framework Week 3: Rename your top 20 most-used reports Week 4: Implement approval workflow for new reports Week 5: Train your report writers Week 6: Delete unused reports Week 7+: Quarterly audits and continuous improvement
The result?
Your Workday tenant becomes organized, maintainable, and scalable. Your users stop wasting time searching and start spending time analyzing. Your admins stop maintaining zombie reports and start building value-adding functionality. And you’ll never see “Report_Final_v3” again.
What’s the worst report name you’ve encountered in your Workday tenant? Share it in the comments Let’s learn from each other’s pain (and maybe have a laugh). 😄
“I need headcount by department, broken down by location and job level, with month-over-month trends and turnover rates.”
You stare at the request. Should you build an Advanced Report? A Matrix Report? A Composite Report? Or maybe three separate reports?
This is where most Workday professionals get stuck. They know how to build reports technically, but they don’t know which report type to use when. So they default to Advanced Reports for everything, then spend hours manipulating data in Excel to get the view they actually need.
Here’s the truth: choosing the wrong report type doesn’t just waste time. It creates slow, unmaintainable reports that confuse users and break during updates.
This guide teaches you how to choose the right report type for every scenario. You’ll learn what each report type does, when to use it, and how to build it correctly with real-world examples.
The Three Report Types: What They Actually Do
Advanced Reports: The List Builder
What It Is: An Advanced Report displays data from a single business object as a list of rows. Think of it as a detailed table where each row represents one record.
Structure:
One row per record (employee, position, transaction, event)
Multiple columns showing different fields
Can include filters, prompts, sorting, and grouping
Can include subtotals and aggregations
Visual Example:
Employee Name
Hire Date
Department
Location
Job Title
Annual Salary
Sarah Johnson
2022-03-15
Engineering
San Francisco
Senior Engineer
$125,000
Mike Chen
2023-01-10
Sales
New York
Account Executive
$95,000
Emily Davis
2021-06-20
HR
Chicago
HR Business Partner
$105,000
Best For:
Employee lists (active headcount, new hires, terminations)
Transaction logs (compensation changes, job changes, time off)
Detailed records for audits, integrations, or EIB loads
Reports that answer: “Show me all [records] where [criteria]”
Not Good For:
Pivoting data across multiple dimensions
Showing trends over time periods
Combining data from multiple business objects
Matrix Reports: The Pivot Table
What It Is: A Matrix Report summarizes numeric data across rows and columns. It’s Workday’s version of an Excel pivot table or crosstab.
Structure:
Rows define one dimension (e.g., Department)
Columns define another dimension (e.g., Location or Time Period)
Cells show aggregated metrics (count, sum, average)
Interactive drilling (click to see detail records)
Visual Example:
Headcount by Department and Location
Department
San Francisco
New York
Chicago
Total
Engineering
45
12
8
65
Sales
10
38
15
63
HR
5
8
12
25
Total
60
58
35
153
Best For:
Summarizing data across two dimensions
Headcount analysis (by org, location, job level)
Trend analysis over time (monthly, quarterly, yearly)
Financial rollups (cost by department and account)
Reports that answer: “Show me [metric] broken down by [dimension 1] and [dimension 2]”
Not Good For:
Showing raw transaction details
Combining multiple unrelated metrics
Reports with more than two grouping dimensions
Composite Reports: The Dashboard Builder
What It Is: A Composite Report combines multiple Matrix Reports into a single unified report. It’s how you build executive dashboards and scorecards.
Structure:
Multiple sub-reports (each is a Matrix Report)
Each sub-report can have different data sources
Aligned by common dimension (department, location, time period)
Metrics calculated across sub-reports at the composite level
Visual Example:
HR Scorecard by Department
Sub-Report 1: Headcount Trend
Department
Jan 2025
Feb 2025
Mar 2025
Engineering
60
63
65
Sales
58
61
63
Sub-Report 2: New Hires
Department
Jan 2025
Feb 2025
Mar 2025
Engineering
5
4
3
Sales
3
5
4
Sub-Report 3: Terminations
Department
Jan 2025
Feb 2025
Mar 2025
Engineering
2
1
1
Sales
0
2
2
Composite Calculation: Turnover Rate
Department
Jan 2025
Feb 2025
Mar 2025
Engineering
3.3%
1.6%
1.5%
Sales
0%
3.3%
3.2%
Best For:
Executive dashboards (HR scorecard, Finance KPIs)
Multi-metric analysis aligned by common dimension
Combining HCM + Finance data
Reports that answer: “Show me 4-5 related metrics side-by-side”
Not Good For:
Simple lists or single-metric analysis
Ad-hoc analysis (too complex for quick requests)
Reports without a common aligning dimension
Decision Framework: Which Report Type Should I Use?
Use this flowchart to decide:
Question 1: Do I need multiple related metrics from different data sources?
Yes → Use Composite Report
No → Go to Question 2
Question 2: Do I need to aggregate/summarize data across dimensions?
Yes → Use Matrix Report
No → Go to Question 3
Question 3: Do I need a detailed list of records?
Yes → Use Advanced Report
Real-World Scenario Examples
Scenario 1: “Show me all employees who were hired in the last 90 days”
Report Type: Advanced Report
Why: You need a list of individual employee records. No aggregation needed.
Data Source: Workers
Columns: Employee Name, Employee ID, Hire Date, Department, Manager, Location
Filter: Hire Date is within the last 90 days
Scenario 2: “Show me headcount by department and location”
Report Type: Matrix Report
Why: You need to aggregate (count employees) across two dimensions (department and location).
Data Source: Workers
Rows: Department (grouping)
Columns: Location (grouping)
Measure: Count of Workers
Scenario 3: “Show me monthly headcount, new hires, terminations, and turnover rate by department”
Report Type: Composite Report
Why: You need multiple related metrics (4 different calculations) aligned by common dimensions (department and month).
Sub-Report 1 (Matrix): Headcount by Department and Month
Sub-Report 2 (Matrix): New Hires by Department and Month
Sub-Report 3 (Matrix): Terminations by Department and Month
✅ The three core Workday report types and when to use each
✅ How to build Advanced Reports for detailed lists and transaction logs
✅ How to build Matrix Reports for aggregations, pivots, and trends
✅ How to build Composite Reports for multi-metric dashboards
✅ How to use Calculated Fields for custom formulas and logic
✅ Performance optimization techniques to keep reports fast
✅ Common mistakes to avoid and best practices to follow
The difference between a junior and senior Workday professional isn’t knowing how to build reports—it’s knowing which report type to build for each business need.
Choose wisely. Build efficiently. Deliver insights, not just data.
Here’s a confession from every Workday implementation:
Week 1, someone asks: “How should we structure our organizations?”
Week 3, someone says: “Let’s just copy our current org chart.”
Week 8, someone realizes: “Wait, this doesn’t work the way we thought.”
Week 20, someone admits: “We need to redesign the entire organization structure.”
I’ve watched this pattern repeat across dozens of Workday implementations. Teams rush to build organization hierarchies without understanding how they actually work in Workday. They treat Supervisory Orgs like departments, Cost Centers like teams, and wonder why security breaks, approvals route incorrectly, and reports pull the wrong data.
The truth is this: your organization hierarchy is the structural foundation of your entire Workday tenant. Get it right from day one, and Workday runs smoothly. Get it wrong, and you’ll spend months fixing downstream consequences.
This guide walks you through building Workday organization hierarchies from scratch. We’ll cover Supervisory Organizations, Cost Centers, superior org logic, manager assignments, and the design decisions that separate clean implementations from messy ones.
Let’s build it right the first time.
Why Organization Hierarchy Matters in Workday
Organizations in Workday are not just labels or groupings. They are active system objects that control critical functionality across your entire tenant.
Your organization hierarchy determines:
Security and Data Access:
Which HR Partners can see which workers
Which Payroll Partners can process payroll for which teams
Which managers inherit role-based permissions
How domain security scopes access by organization
Business Process Routing:
Where hiring approvals go
Who approves compensation changes
How time off requests route to managers
Which stakeholders review terminations
Reporting and Analytics:
How you slice headcount by department, location, or business unit
How Finance reports costs by Cost Center
How HR tracks diversity metrics by organization
How leadership views organizational spans of control
Financial Postings:
Where worker costs land in the General Ledger
How budget vs. actuals roll up by Cost Center
Which organizations own spend and expenses
Get your organization hierarchy wrong, and all of these break. Security fails. Approvals route incorrectly. Reports pull bad data. Finance can’t reconcile costs.
The time to fix organization design is before you load workers, not after.
Understanding Workday Organization Types
Before we build anything, let’s clarify what we’re building. Workday provides several organization types, but two are critical for most implementations:
Supervisory Organizations
What They Are: Supervisory Organizations (Sup Orgs) define your reporting structure. They group workers who report to the same manager and form a hierarchical tree that mirrors your organizational chart.
What They Control:
Worker reporting relationships (who reports to whom)
Business process routing (hiring, promotions, terminations, comp changes)
Role-based security (HR Partner, Payroll Partner roles are assigned at the Supervisory Org level)
Approval chains (time off, expenses, requisitions route through the Supervisory Org hierarchy)
Manager self-service access (managers can see and manage their team)
Key Point: If your Supervisory Org tree is wrong, everything downstream breaks. Approvals route to the wrong manager. Security grants access to the wrong workers. Reports show incorrect reporting lines.
Cost Centers
What They Are: Cost Centers represent financial responsibility. They are the organizational unit that owns the budget, tracks spend, and posts to the General Ledger.
What They Control:
Budgeting and forecasting (Cost Centers are the primary dimension for budget allocation)
Spend analytics (requisitions, expenses, journal entries route to Cost Center managers)
General Ledger posting (worker costs post to the GL based on Cost Center assignment)
Financial reporting (Finance reports actuals vs. budget by Cost Center hierarchy)
Key Point: Cost Centers tell Finance who owns the numbers. Supervisory Orgs show reporting lines. Cost Centers show financial lines. These are often (but not always) the same.
The Foundation: Superior Organization Logic
Every organization hierarchy in Workday is built using superior organization relationships. This is the single most important concept to understand before you create a single organization.
How Superior Org Logic Works
In Workday, organizations don’t exist in isolation. Every organization (except the top-level organization) has a superior organization above it in the hierarchy.
Think of it like a family tree:
Parent Org (superior)
Child Org (subordinate to the parent)
Grandchild Org (subordinate to the child, which is subordinate to the parent)
When you create an organization, you define its superior organization. Workday automatically builds the hierarchy tree based on these relationships.
Example:
textCEO Organization (top-level, no superior)
├── Sales Organization (superior: CEO Organization)
│ ├── Sales North America (superior: Sales Organization)
│ └── Sales EMEA (superior: Sales Organization)
├── Engineering Organization (superior: CEO Organization)
│ ├── Engineering Product (superior: Engineering Organization)
│ └── Engineering Platform (superior: Engineering Organization)
└── Finance Organization (superior: CEO Organization)
Each organization points to its superior. Workday builds the tree automatically.
Why Superior Org Logic Matters
Superior org relationships control:
Hierarchy roll-ups: Reports can roll up headcount, costs, and data by superior org
Security inheritance: Role-based security can inherit down the org tree
Approval routing: Some business processes route approvals up the superior org chain
Reporting structures: Organizational charts and workforce planning tools use superior org logic
If you assign the wrong superior org, the hierarchy breaks. Workers appear in the wrong branch of the tree. Reports pull incorrect data. Security grants access to the wrong teams.
Step-by-Step: Building Your First Supervisory Organization Hierarchy
Let’s walk through building a Supervisory Organization hierarchy from scratch. We’ll use a realistic example: a mid-sized company with 500 employees across Sales, Engineering, Finance, and HR.
Step 1: Design the Hierarchy on Paper First
Before you touch Workday, map out your organization structure on paper (or a spreadsheet). Answer these questions:
What are your top-level organizations?
CEO
Sales
Engineering
Finance
HR
Operations
What are the subordinate organizations under each?
Sales: Sales North America, Sales EMEA, Sales APAC
Engineering: Engineering Product, Engineering Platform, Engineering Data
Continue building down the hierarchy for Manager-level orgs.
Example: Create Sales – NA East:
Navigate to Create Supervisory Organization
Fill in:
Organization Name: Sales – NA East
Organization Code: ORG-SALES-NA-EAST
Organization Type: Supervisory
Superior Organization: Sales – North America (NOT Sales Organization)
Manager: James Wilson (Sales Manager East)
Click OK
Continue until your full hierarchy is built.
Step 6: Validate the Hierarchy Tree
After creating all organizations, validate that the hierarchy is correct.
Navigate to:
Search for View Supervisory Organization
Select CEO Organization
Click Organization Chart or View Hierarchy
Workday displays your full org tree visually.
Check for:
All organizations appear in the correct superior/subordinate relationships
No orphaned orgs (orgs that don’t appear anywhere in the tree)
Managers are assigned correctly
Naming conventions are consistent
Common Issues:
Org appears in the wrong branch: You assigned the wrong superior org. Edit the org and correct the superior.
Org doesn’t appear at all: You forgot to assign a superior (unless it’s the top-level org). Edit and add superior.
Circular reference error: Org A is superior to Org B, Org B is superior to Org C, Org C is superior to Org A. Fix by breaking the circular reference.
Step-by-Step: Building Your Cost Center Hierarchy
Cost Centers work the same way as Supervisory Organizations, but they represent financial responsibility instead of reporting lines.
Step 1: Design the Cost Center Structure
Work with Finance to design the Cost Center hierarchy. It should align with:
Your Chart of Accounts structure
Budget ownership and responsibility
How Finance wants to report actuals vs. budget
Example Cost Center Structure:
textCorporate Cost Center (top-level)
├── Sales Cost Center
│ ├── Sales NA Cost Center
│ ├── Sales EMEA Cost Center
│ └── Sales APAC Cost Center
├── Engineering Cost Center
│ ├── Engineering Product Cost Center
│ └── Engineering Platform Cost Center
├── Finance Cost Center
└── HR Cost Center
Key Decision: Do Cost Centers mirror Supervisory Orgs exactly? Or do they differ?
Same structure: Easier to maintain, simpler for users to understand
Different structure: More flexible for Finance reporting, but adds complexity
Step 2: Create Cost Centers
The process is identical to creating Supervisory Organizations, but you use Create Cost Center task instead.
Create Top-Level Cost Center:
Search for Create Cost Center
Fill in:
Cost Center Name: Corporate Cost Center
Cost Center Code: CC-CORP
Organization Type: Cost Center
Superior Organization: Leave blank (top-level)
Manager: CFO or Finance Director
Effective Date: Go-live date
Click OK
Create Subordinate Cost Centers: Repeat for each Cost Center, assigning the correct superior Cost Center.
Step 3: Assign Cost Centers to Workers
Once Cost Centers are created, assign them to workers.
Option 1: Assign Default Cost Center at Supervisory Org Level
Navigate to Edit Supervisory Organization
Set Default Cost Center for the org
All workers in that Supervisory Org inherit the Cost Center automatically
Option 2: Assign Cost Center Individually
Navigate to Change Job for a worker
Assign Cost Center on the Job Details page
This overrides the default Cost Center from Supervisory Org
Critical Design Decisions
Decision 1: Where Does the Manager Sit?
This is the most common org hierarchy mistake:
Should the manager sit INSIDE the org they manage, or in the SUPERIOR org?
The Right Answer: Managers should sit in the superior organization of the org they manage, NOT inside it.
Example:
CORRECT:
textSales Organization (Tom Johnson, VP Sales)
├── Sales - North America (Sarah Lee, Director Sales NA)
│ ├── James Wilson (Sales Manager, reports to Sarah)
│ ├── Emily Davis (Sales Rep, reports to James)
│ └── Mark Thompson (Sales Rep, reports to James)
Tom Johnson sits in CEO Organization (superior to Sales Organization). Sarah Lee sits in Sales Organization (superior to Sales – North America). James Wilson sits in Sales – North America (manages reps in his own org).
INCORRECT:
textSales Organization (Tom Johnson sits HERE, manages Sales Org)
├── Sales - North America (Sarah Lee sits HERE, manages Sales NA)
Why This Matters:
Security inheritance works correctly when managers sit in superior orgs
Approval routing flows up the chain properly
Role-based access grants managers permission to see subordinate orgs
Prevents weird permission overlaps and conflicts
Decision 2: How Deep Should the Hierarchy Go?
Recommended Depth: 3-5 levels maximum
Why:
Deep hierarchies (7+ levels) slow approvals
Every approval step adds delay and complexity
Reporting becomes harder to navigate
Security configuration gets messy
If You Have More Than 5 Levels:
Flatten the hierarchy by combining levels
Use Custom Organizations for matrix relationships instead of adding Supervisory Org levels
Consider whether every level truly represents a distinct manager with approval authority
Decision 3: Should Individual Contributors Have Their Own Orgs?
Option 1: ICs Report Directly to Manager’s Org
Manager’s org contains both the manager and their direct reports
Simpler structure, fewer orgs to maintain
Works well for small teams (manager + 3-10 ICs)
Option 2: ICs Have Their Own Subordinate Org
Manager sits in superior org, ICs sit in subordinate org
More granular reporting and security scoping
Works well for large teams (manager + 20+ ICs) or when you need to segment by sub-team
Most Common Approach: Option 1 for small teams, Option 2 for large teams.
Decision 4: Naming Conventions
Use clear, consistent naming conventions for all organizations:
Good Examples:
Sales – North America
Engineering – Product
Finance – Accounting
HR – Talent Acquisition
Bad Examples:
NA Sales Team (inconsistent format)
Eng Prod (abbreviations aren’t clear)
Accounting Dept (mixing “Finance” and “Dept”)
Best Practices:
Start with function or department name
Add geography, sub-function, or team type after a separator (dash or comma)
Avoid abbreviations unless universally understood
Keep names concise (under 50 characters)
Use title case for readability
Assigning Workers to Organizations
Once your org hierarchy is built, you need to assign workers to organizations.
For New Hires
When you hire a new worker, you assign their Supervisory Organization and Cost Center on the Hire Employee task:
Navigate to Hire Employee
Fill in worker details
In Job Details section:
Supervisory Organization: Select the org the worker reports to
Cost Center: Select the Cost Center for financial tracking
Manager: Workday assigns the manager automatically based on Supervisory Org
Submit and approve
For Existing Workers
When you need to move a worker to a new organization, use Change Job:
Navigate to Change Job
Select the worker
In Organizations section:
Update Supervisory Organization (if reporting line changes)
Update Cost Center (if financial responsibility changes)
Set Effective Date
Submit for approval
Common Mistakes and How to Avoid Them
Mistake 1: Building Orgs Based on Locations or Departments Instead of Reporting Lines
The Problem: Teams create Supervisory Orgs for “Seattle Office” or “Marketing Department” without thinking about who reports to whom.
What Happens: Workers in the same office report to different managers, but they’re all in the same Supervisory Org. Approvals route incorrectly. Security breaks.
The Fix: Supervisory Orgs follow reporting relationships. If workers in Seattle report to different managers, they should be in different Supervisory Orgs. Use Locations for geography and Custom Orgs for departments that cross reporting lines.
Mistake 2: Creating Organizations After Loading Workers
The Problem: Team loads 500 workers into Workday, then realizes they need to create organizations. Now they have to mass-update 500 worker records to assign orgs.
What Happens: Mass updates through Change Job trigger 500 approval workflows. Data quality suffers. Rework takes weeks.
The Fix: Build your organization hierarchy before you load workers. Orgs should exist in Workday before the first worker is hired or migrated.
Mistake 3: Not Planning for Future Growth
The Problem: You build a hierarchy for today’s 500 employees. Company grows to 2,000 employees. Hierarchy doesn’t scale. You need to restructure.
What Happens: Mass org reassignments. Business process disruptions. Reports break. Security needs reconfiguration.
The Fix: Design your hierarchy for scale. Leave room for new regions, new departments, new functions. Build flexibility into the structure from day one.
Mistake 4: Inconsistent Superior Org Assignments
The Problem: Sales – North America reports to Sales Organization. Sales – EMEA accidentally reports to CEO Organization (skipping Sales Organization).
What Happens: Hierarchy tree looks broken. Roll-up reports are incorrect. Tom Johnson (VP Sales) can’t see EMEA team data because they don’t roll up to his org.
The Fix: Validate superior org assignments carefully. Use View Supervisory Organization Hierarchy to visually check the tree structure before go-live.
Build orgs BEFORE loading workers (avoid mass updates later)
Validate the hierarchy tree before go-live (check superior relationships)
Get your organization hierarchy right from day one, and everything else in Workday works smoothly. Security flows correctly. Approvals route properly. Reports pull accurate data. Finance can reconcile costs.
Get it wrong, and you’ll spend months untangling org assignments, fixing security, and rebuilding hierarchies.
Start simple. Plan for scale. Document everything.
Every Workday implementation team faces the same question in Week 1: “How should we structure our organizations?”
And almost every time, someone says: “They’re all basically the same, right? Just different names for groups of people.”
Wrong.
Choosing the wrong organization type is one of the fastest ways to create security gaps, break approval workflows, and turn reporting into a nightmare. Workday organizations are not interchangeable. Each type serves a specific functional purpose, drives distinct system behaviors, and impacts everything from business processes to financial postings.
If you design your organization structure incorrectly from day one, you will spend months—or years—fixing the downstream consequences.
This guide explains exactly what each Workday organization type does, when to use it, and how to avoid the most common mistakes that break Workday designs.
Why Organization Design Matters in Workday
Organizations in Workday are not just labels. They are the structural foundation of your entire tenant.
Organizations control:
Security domains – Who can see and edit which worker data
Business process routing – Where approvals go and who signs off
Reporting hierarchies – How you analyze workforce data
Financial postings – Where costs land in the General Ledger
Role-based access – Which managers inherit permissions down the hierarchy
Get your organization design right early, and Workday runs smoothly. Get it wrong, and you will face:
Broken approval chains that route to the wrong manager
Security domains that expose sensitive data or lock out HR
Reports that pull incorrect headcount or cost data
GL postings that land in the wrong cost center or company
Rework that requires mass updates, org redesigns, and business process changes
The time to fix organization design is before go-live, not after.
The Core Workday Organization Types
Workday delivers several organization types out of the box. Each one has a distinct purpose, distinct configuration tasks, and distinct domain security.
Let’s break down the big three—and why they are not interchangeable.
1. Supervisory Organizations: The Backbone of Your Workday Experience
What They Are: Supervisory Organizations (Sup Orgs) define your reporting structure. They group workers who report to the same manager and form a hierarchical tree that mirrors your organizational chart.
What They Control: Supervisory Orgs are the most powerful organization type in Workday HCM because they drive:
Worker reporting relationships – Who reports to whom
Business process routing – Hiring, promotions, terminations, job changes, and compensation all route through the Supervisory Org hierarchy
Role-based security – Roles like “HR Partner” or “Manager” are assigned at the Supervisory Org level and inherit down the tree by default
Approval chains – Time off, expenses, and other transactions route to the manager of the worker’s Supervisory Org
Advanced Compensation workflows – Comp planning, merit increases, and bonus allocation follow the Supervisory Org structure
Why This Matters: If your Supervisory Org tree is wrong, everything downstream breaks.
Example: A worker sits in the wrong Supervisory Org. Their time-off request routes to a manager in another department. That manager has no context, delays approval, and the worker misses their flight.
That is not a process problem. That is an organization design problem.
Key Design Rules:
Managers should sit in the superior organization of the org they manage, not inside it
Every Supervisory Org must have one assigned manager
Use Supervisory Org subtypes (e.g., “Corporate,” “Field,” “Shared Services”) to segment different parts of the business without creating separate trees
Default Cost Center can be assigned at the Supervisory Org level to streamline financial defaults
Common Mistakes:
Creating too many levels (7+ layers) that slow approvals and complicate security
Assigning managers to positions inside the org they manage, which creates inheritance conflicts
Using Supervisory Orgs to track project teams or matrix relationships (use Custom Orgs instead)
2. Cost Centers: Your Financial Source of Truth
What They Are: Cost Centers represent financial responsibility. They are the organizational unit that owns the budget, tracks spend, and posts to the General Ledger.
What They Control:
Budgeting and forecasting – Cost Centers are the primary dimension for budget allocation in Workday
Spend analytics – Purchase requisitions, expense reports, and journal entries route to Cost Center managers for financial approval
General Ledger posting – Worker costs (salary, benefits, taxes) post to the GL based on the worker’s Cost Center assignment
Financial reporting – Finance teams report actuals vs. budget by Cost Center hierarchy
Why This Matters: Cost Centers tell Finance who owns the numbers.
Supervisory Orgs show the reporting line. Cost Centers show the financial line.
These are often—but not always—the same.
Example: A worker reports to a manager in the Sales Supervisory Org but is funded by the Marketing budget. Their Supervisory Org is Sales. Their Cost Center is Marketing. Workday tracks both, and reports accordingly.
Key Design Rules:
Assign one primary Cost Center per worker (Workday supports split costing, but keep it simple at first)
Cost Center hierarchy should mirror your chart of accounts structure
Cost Center managers approve financial transactions (requisitions, expenses, journals) while Supervisory Org managers approve HR transactions (time off, job changes)
Use Cost Center View security to control which Finance users can see which cost data
Common Mistakes:
Conflating Supervisory Orgs and Cost Centers (“They’re the same thing, right?”)
Not assigning a Cost Center manager, which breaks expense and requisition approvals
Creating Cost Centers at too granular a level, which clutters GL reporting
3. Companies: Legal Entities That Drive Financial Structures
What They Are: Companies represent your legal entities. In Workday, a Company is the top-level organization for Financials, Payroll, and Benefits.
What They Control:
Legal entity assignment – Every worker must be assigned to a Company
Payroll processing – Payroll runs by Company
Benefits eligibility – Benefit plans are configured by Company
Chart of Accounts – The General Ledger is structured by Company, and Company is the first dimension in every GL posting
Tax and compliance – Legal reporting (W-2s, statutory filings, labor law compliance) is Company-specific
Why This Matters: If you operate in multiple countries or have multiple legal entities (e.g., a holding company with subsidiaries), you must configure each as a separate Company in Workday.
Key Design Rules:
One Company per legal entity
Company hierarchy can roll up to a parent for consolidated reporting
Do not create “fake” Companies for reporting convenience—use Custom Orgs or Regions instead
Ensure workers are assigned to the correct Company for tax and payroll purposes
Common Mistakes:
Using “Company” as a proxy for “division” or “business unit” (use Supervisory Orgs or Custom Orgs instead)
Not aligning Company structure with your legal entity structure, which breaks tax and statutory compliance
4. Regions: Geographic Groupings
What They Are: Regions group workers, locations, and organizations by geography.
What They Control:
Geographic reporting – Headcount, costs, and workforce analytics by region
Regional compliance – Policies, business processes, and benefits that vary by geography
Location-based security – Regional HR partners can be granted access to workers in their assigned region
Regional management layers – Some organizations use Region hierarchies to create geographic leadership structures (e.g., EMEA Director, APAC VP)
Why This Matters: If you operate globally, Regions help you segment workers, track regional performance, and assign region-specific HR support without creating duplicate Supervisory Org trees.
Example: A global company has one Supervisory Org hierarchy for reporting lines but uses Regions to group workers into North America, EMEA, APAC, and LATAM for regional HR team assignments and compliance tracking.
Key Design Rules:
Use Regions for geography, not for business units or functions
Region assignment can inherit from Location, or be assigned manually
Keep Region hierarchies simple (2-3 levels maximum)
Use Regions in security policies to grant HR partners access to workers in their geography
Common Mistakes:
Creating Regions for non-geographic groupings (e.g., “Remote Workers” as a Region)
Overcomplicating Region hierarchies with too many sub-levels
Not using Regions at all, then manually maintaining geographic access lists
5. Custom Organizations: Flexibility for Everything Else
What They Are: Custom Organizations are user-defined organizations that capture any business dimension not covered by Supervisory Orgs, Cost Centers, Companies, or Regions.
What They Control: Custom Orgs are the Swiss Army knife of Workday organizations. Use them to track:
Matrix reporting relationships – A worker reports to one manager (Supervisory Org) but also works for a project manager (Custom Org: Project Team)
Product lines, business units, or divisions – Groupings that cross Supervisory Org boundaries
Project teams – Temporary or permanent project assignments that need their own hierarchy
Centers of Excellence, shared services, or practice groups – Functional groupings that span multiple Supervisory Orgs
Gigs or flex work – Track workers assigned to short-term initiatives or temporary teams
Work Councils or employee representative bodies – Labor governance structures required in certain countries
Why This Matters: Most businesses are not purely hierarchical. You have matrix relationships, cross-functional teams, project-based work, and shared resources.
Custom Orgs let you track all of that without polluting your Supervisory Org tree.
Example: A product manager reports to the VP of Product (Supervisory Org) but is assigned to the “Mobile App Relaunch” project team (Custom Org). Workday tracks both relationships. The project lead can run reports on their team, but approvals and security still flow through the Supervisory Org.
Key Design Rules:
Use Custom Orgs for reporting and analysis, not for routing or security (unless absolutely necessary)
Create Custom Org Types (e.g., “Project Team,” “Practice Group,” “Business Unit”) to keep them organized
Custom Orgs can be single-level or hierarchical—use hierarchies when you need roll-up reporting
Workers can belong to multiple Custom Orgs simultaneously
Avoid using Custom Orgs to fix broken Supervisory Org designs—fix the Supervisory Org instead
Common Mistakes:
Using Custom Orgs for approval routing (this gets complicated fast)
Creating too many Custom Org Types, which clutters reporting
Assigning workers to Custom Orgs without a clear business use case or reporting need
Other Organization Types You Should Know
Work Councils
Represent employee representative bodies, works councils, or labor governance structures required in certain countries (especially in Europe). Use Work Councils when you need to track which workers are represented by which council for compliance, reporting, or business process routing.
Matrix Organizations
A legacy organization type used to track dual reporting relationships. In modern Workday implementations, Custom Organizations are preferred because they offer more flexibility and cleaner reporting.
Pay Groups
Not technically an organization, but often confused with one. Pay Groups define payroll frequency (weekly, biweekly, monthly) and are assigned to workers to control payroll processing schedules.
Project Organizations
Used in Workday Projects (part of Financials). If you track billable projects, Project Orgs define the project hierarchy for time tracking, billing, and project reporting.
How to Choose the Right Organization Type
Here is the simple decision tree most Workday practitioners use:
If you need to track…
Use this organization type
Reporting lines and manager hierarchy
Supervisory Organization
Financial responsibility and budget ownership
Cost Center
Legal entities for payroll, tax, and benefits
Company
Geographic groupings (countries, regions)
Region
Matrix teams, projects, business units, or flex work
Custom Organization
Labor councils or employee representative bodies
Work Council
Golden Rule: Use the right org for the right purpose. Do not force one organization type to do the job of another.
Why Most Workday Designs Fail at Organization Structure
Here are the three most common failures I see in Workday organization design:
1. Conflating Supervisory Orgs and Cost Centers
Teams assume these are the same thing. They are not.
Example: A sales operations analyst reports to the Head of Sales Operations (Supervisory Org) but is funded by the Marketing budget (Cost Center). If you force Supervisory Orgs and Cost Centers to be identical, you lose the ability to track this split.
Fix: Design Supervisory Orgs for reporting lines. Design Cost Centers for financial ownership. Let Workday track both.
2. Designing Organizations After Go-Live
Organizations are not configuration. They are foundational data.
You cannot “add them later” without mass updates, org reassignments, and business process changes.
Fix: Lock down organization design in Week 1 of your implementation. Test it against your business processes, security model, and reporting requirements before you load workers.
3. Using Custom Orgs as a Bandaid for Broken Supervisory Org Design
If your Supervisory Org tree does not reflect reality, the answer is not to create a Custom Org to “fix” it.
The answer is to fix the Supervisory Org.
Fix: Use Custom Orgs for matrix relationships, project teams, and cross-functional groupings—not as workarounds for bad Supervisory Org design.
Workday Organization Design Best Practices
1. Design for Scale, Not for Today
Your organization structure will change. Plan for growth, mergers, acquisitions, and reorganizations from day one.
2. Keep Supervisory Org Hierarchies Shallow
Avoid 7+ levels of management. Deep hierarchies slow approvals, complicate security, and frustrate managers.
3. Align Cost Centers with Your Chart of Accounts
Finance should own Cost Center design. Cost Centers must map cleanly to your GL structure.
4. Use Custom Orgs Sparingly
Every Custom Org Type you create adds complexity to reporting and maintenance. Only create them when you have a clear business use case.
5. Test Organization Design Against Security and Business Processes
Before go-live, validate:
Does security inheritance work the way you expect?
Do approvals route to the right managers?
Can Finance run budget vs. actuals by Cost Center?
Can HR pull headcount reports by Supervisory Org?
6. Document Your Organization Strategy
Write down the purpose of each organization type, who owns updates, and how workers get assigned. This becomes your operating manual for post-go-live org maintenance.
Real-World Example: Designing Organizations for a Global Company
Let’s walk through a realistic scenario.
Company: GlobalTech, a 5,000-employee software company with offices in the US, UK, Germany, India, and Australia.
Business Requirements:
Workers report to functional managers (Engineering, Sales, Marketing, Finance)
Costs are tracked by department and region
The company has three legal entities (US Inc., UK Ltd., Australia Pty)
Product teams are cross-functional and span multiple departments
Regional HR teams need access to workers in their geography
Organization Design:
Org Type
Design Decision
Company
Three Companies: GlobalTech US Inc., GlobalTech UK Ltd., GlobalTech AU Pty (one per legal entity)
Department-based Cost Centers (aligned with GL): Engineering, Sales EMEA, Sales APAC, Marketing, Finance, IT
Region
Four Regions: Americas, EMEA, APAC, ANZ (for geographic reporting and HR access)
Custom Org
Product Teams (Custom Org Type) with one Custom Org per product line (Mobile, Cloud, Enterprise, Data) for cross-functional project tracking
Why This Works:
Supervisory Orgs define clear reporting lines and drive approvals
Cost Centers align with Finance’s budget structure
Companies align with legal entities for payroll and tax
Regions enable geographic reporting and HR access
Custom Orgs track product team assignments without disrupting the Supervisory Org tree
Final Thoughts: Get Organizations Right the First Time
Organizations are the foundation of your Workday tenant.
Get them right, and Workday runs smoothly. Security works. Approvals route correctly. Reports pull accurate data. Finance trusts the numbers.
Get them wrong, and you spend months fixing broken processes, reassigning workers, and redesigning hierarchies.
The time to design organizations is before go-live, not after.
Use Supervisory Orgs for reporting lines and workflow routing. Use Cost Centers for financial ownership. Use Companies for legal entities. Use Regions for geography. Use Custom Orgs for everything else.
And never, ever assume that all organizations are “basically the same.”
Most tenants turn on Workday Talent & Performance but never turn it into a real talent engine. Performance reviews are treated as a compliance exercise, goals live in slides instead of Workday Goals, and Succession Plans exist for a handful of senior roles only. A true talent engine uses Performance, Goals and Succession Planning to drive internal mobility: moving people into new roles, closing skill gaps and filling critical positions from within.
This guide walks through how to design Workday so those three pieces actually work together.
Start with an internal mobility strategy
Before configuring anything, be clear about your internal mobility goals:
What percentage of roles should be filled internally vs externally?
Which roles are “critical” and must always have at least one ready successor?
How do you want employees to discover internal opportunities: Internal Job Board, Talent Marketplace, manager nominations?
Workday can support this with Talent Management, Succession Plans, Talent Pools and Internal Job Postings, but the configuration should follow your strategy, not the other way around.
Goals: turning strategy into worker-level commitments
In Workday, Goals (sometimes called Performance Goals or Development Goals) connect company strategy to individual work. If goals are vague or never updated, your talent engine has nothing to run on.
Key design practices for Goals:
Use Organization Goals at the top level and cascade them down to teams and workers using tasks like Manage Organization Goals and Add Goal to Employee.
Encourage a small set of meaningful goals per worker (3–5) rather than long checklists no one reads.
Distinguish between Performance Goals (what to deliver this year) and Development Goals (skills and experiences to build over time).
Strong goals enable:
Clear conversations in Check-Ins and Performance Reviews.
Better calibration discussions in Talent Reviews.
A more accurate view of who is ready for bigger roles because goals track stretch assignments and development outcomes.
Performance: continuous, not just annual
Workday Performance Management supports continuous feedback as well as formal review cycles. A static, once-a-year review is not enough to power internal mobility.
Good performance design typically includes:
Check-Ins: informal but trackable conversations where managers and employees align on priorities, progress on goals and development needs.
Formal Review Templates: standardized review forms per population (e.g., Professional, Manager, Executive) with a mix of ratings, comments and goal assessments.
Feedback: peer or cross-functional feedback requests to capture performance beyond the direct manager view.
Configuration tips:
Keep rating scales simple and well-defined; too many rating options reduce calibration quality.
Align competencies and behaviors with your leadership model or career framework.
Make sure reviews link directly to Goals so managers see goals in-context during evaluations.
When performance is managed continuously and consistently, you get reliable data on who consistently delivers, not just who writes good self-reviews.
Succession: building real internal pipelines
Workday Succession Planning lets you build Succession Plans for key roles and Succession Pools for broader pipelines. This is where your talent engine turns into a visible internal pipeline.
Design principles for Succession:
Identify critical roles first: positions where vacancy risk is high or impact is severe (e.g., key leaders, scarce technical experts).
For each critical role, create a Succession Plan tied to the Job Profile rather than just the current incumbent so plans survive turnover.
Use Succession Pools when you want a bench for a set of roles (e.g., “Future Plant Managers”, “Future Finance Controllers”).
Within each plan, track:
Ready Now / Ready in X Years status.
Risk of loss and impact of loss, where your framework supports it.
Development actions needed for each successor (assignments, training, mentoring).
Succession should not be a secret spreadsheet. When it lives in Workday, HR and leaders can see where pipelines are strong or thin and act before vacancies hit.
Connecting Performance, Goals and Succession
The real power comes when Goals, Performance and Succession are connected rather than treated as separate modules.
Examples of integration:
Use Performance Ratings and Goal achievement as inputs to your Talent Review or Succession Readiness assessments.
Pull in Career Interests, Skills and Development Goals from worker profiles when evaluating potential successors.
Use succession discussions to feed back into Development Goals: if someone is “Ready in 2 years”, capture the experiences they need and actively track them.
From a configuration standpoint, this means:
Ensuring your Performance Review templates capture ratings and qualitative data that can be reused in Talent Reviews.
Making Succession Plans easily accessible in Talent Review dashboards and in leader views.
Confirming security so that HR and leaders have the right access to succession data without exposing it to everyone.
When these modules share data and are used in a single talent review rhythm, leadership starts to trust Workday as the source of truth for talent decisions.
Making internal mobility visible and easy
A talent engine is only real if people actually move. Workday supports Internal Job Postings, talent marketplaces and internal search to make opportunities visible.
Key ideas:
Always post roles internally on your Internal Career Site unless there is a legal or strategic reason not to.
Encourage managers to search for internal candidates using skills, experience and performance history in Workday before going to external channels.
Use Talent Reviews to proactively identify people who should be approached for upcoming roles rather than waiting for them to apply.
Internal mobility also depends on culture, not just configuration. But when Workday makes internal roles easy to find and leaders see clear data on internal talent, the system nudges behavior in the right direction.
Governance, cadence and adoption
Finally, treat your talent engine like a recurring cycle, not a one-off project.
Governance practices:
Define a talent calendar: when goals are set and refreshed, when performance reviews run, when Talent Reviews happen, when Succession Plans are updated.
Maintain design documentation: how Goals, Performance, Succession and Internal Mobility are configured in Workday and which reports leaders should use.
Track key metrics: internal fill rate, time-to-fill for critical roles, bench strength per critical role, promotion rates of ready successors.
Adoption tips:
Make manager training concrete: show them how to update goals, run check-ins, complete reviews and nominate successors in the UI.
Keep configurations as simple as possible while still meeting needs; complexity kills adoption.
Get HR Business Partners comfortable with Talent Review dashboards so they coach leaders using data from Workday, not offline trackers.
When Performance, Goals and Succession are designed to work together in Workday, internal mobility stops being a slogan and becomes the default way your organization fills roles. You end up with a living, data-backed view of your talent pipeline – and Workday becomes the engine that keeps it moving.
I built my first Workday Discovery Board with genuine excitement.
It had everything: KPI cards showing headcount trends, a beautiful waterfall chart displaying hiring pipeline, color-coded heat maps showing turnover by department, and interactive drill-downs into every metric.
I spent three days perfecting it. The visualizations were stunning. The data was accurate. The interactivity was smooth.
I shared it with the CFO.
She opened it once. Never looked at it again.
Two weeks later, I found her reviewing a spreadsheet someone had exported from a basic Workday report. The spreadsheet had pivot tables and ugly charts, but she used it every Monday morning.
That is when I learned the hard lesson: Beautiful dashboards mean nothing if executives do not actually use them.
Over the past five years, I have built Discovery Boards across dozens of Workday tenants. I have watched executives ignore gorgeous dashboards while repeatedly asking for the same basic reports via email.
But I have also seen Discovery Boards become indispensable tools that executives check daily before their first meeting.
The difference is not the visualization quality or the data complexity. The difference is understanding what executives actually need versus what we think they need.
This guide will show you how to build Discovery Boards that executives actually use, based on real implementations where adoption exceeded 80%.
Why Most Discovery Boards Fail
Before we discuss what works, understand why most Discovery Boards fail.
The Three Failure Patterns
Failure Pattern 1: The Dashboard Museum
You build a comprehensive Discovery Board with 15 sheets, 47 visualizations, and every possible metric the executive might need.
The executive opens it once, gets overwhelmed by the sheer volume of information, and never returns.
They go back to asking their assistant to pull specific numbers via email because it is faster than hunting through your 15-sheet dashboard.
Failure Pattern 2: The Beautiful But Useless Dashboard
You create stunning visualizations with perfect color schemes, elegant transitions, and impressive interactivity.
The executive looks at it and says: “This is beautiful. But I still cannot answer my question: Which departments are over budget on contractor spend?”
Your dashboard shows aggregate metrics and trends. It does not answer their specific decision-making questions.
Failure Pattern 3: The Stale Data Problem
You build a Discovery Board that requires manual data refresh or uses data sources that update weekly.
The executive checks it Monday morning to prepare for their leadership meeting. The data is from last Thursday. They make a comment based on your dashboard. Someone corrects them with more recent data.
They never trust your dashboard again.
The Root Cause
All three failures stem from the same problem: You built the dashboard for yourself, not for the executive.
You built what you thought was impressive. What demonstrated your Workday skills. What showcased Discovery Board capabilities.
You did not build what the executive actually needs to make decisions on Tuesday morning.
Understanding What Executives Actually Need
Executives do not need dashboards. They need answers to specific recurring questions.
The Five Executive Question Types
Every executive question falls into one of five categories:
Question Type 1: Status Check (“Where are we right now?”)
Examples:
What is our current headcount?
How many open positions do we have?
What is our month-to-date spending versus budget?
What they need: One number. Current state. Updated in real-time or near real-time.
What they do NOT need: Historical trends, departmental breakdowns, year-over-year comparisons (unless they specifically ask).
Question Type 2: Trend Detection (“Are we moving in the right direction?”)
Examples:
Is turnover increasing or decreasing?
Are we filling positions faster or slower than last quarter?
Is our compensation spend trending toward budget or exceeding it?
What they need: Simple directional indicator (up, down, flat). Trend line over relevant time period (usually last 3-6 months).
What they do NOT need: Statistical significance tests, detailed breakdowns, multiple trend lines on the same chart.
Question Type 3: Problem Identification (“Where are the issues?”)
Examples:
Which departments have the highest turnover?
Which roles are hardest to fill?
Where are we overspending on contractors?
What they need: Ranked list. Top 5 or top 10. Clear identification of where to focus attention.
What they do NOT need: Complete list of all departments, roles, or cost centers. They want to know the problems, not the successes.
Question Type 4: Comparison (“How do we compare?”)
Examples:
Which department has the highest span of control?
How does Q4 hiring compare to Q3?
Which business unit is most efficient on cost per hire?
What they need: Side-by-side comparison. Clear winner/loser identification. Context for whether the difference matters.
What they do NOT need: Every possible comparison. Just the comparisons that drive decisions.
Question Type 5: Deep Dive (“Tell me more about this specific thing”)
Examples:
Show me everyone who terminated in Engineering last quarter.
Break down contractor spend by hiring manager.
What is driving the turnover spike in the Dallas office?
What they need: Drill-down capability from summary to detail. Ability to filter and explore.
What they do NOT need: This level of detail on the main dashboard. This is where interactive drill-through becomes valuable.
The Executive Attention Span Reality
Executives spend an average of 90 seconds on a dashboard before moving to their next task.
If your Discovery Board cannot answer their primary question in 90 seconds, they will not use it.
This means:
One primary insight per sheet (not 10 vizzes per sheet)
Three to five sheets maximum (not 15 sheets)
Clear hierarchy of information (most important at top left)
Minimal scrolling (fits on one screen without vertical scroll)
The Discovery Board Framework That Actually Works
Here is the framework that consistently achieves 80% or higher executive adoption.
The One-Page, Five-Number Rule
Your Discovery Board should answer five specific questions on one visible page (no scrolling required).
Not five categories of questions. Five actual questions the executive asks repeatedly.
Example: CHRO Discovery Board
Question 1: What is our current headcount? Visualization: KPI card showing total headcount with trend indicator
Question 2: Are we filling positions faster or slower? Visualization: KPI card showing average days to fill with month-over-month comparison
Question 3: Which departments have the highest turnover? Visualization: Horizontal bar chart showing top 5 departments by turnover rate
Question 4: How is our diversity representation trending? Visualization: Line chart showing diversity percentage over last 12 months
Question 5: Where are we overspending on contractors? Visualization: Heat map showing contractor spend by department with budget comparison
Five numbers. One page. Answers the five questions the CHRO asks every Monday morning.
The Three-Sheet Maximum
If you need more than five metrics, use sheets (tabs) to organize by decision type, not by data category.
Sheet 1: “At a Glance”
Five most important metrics
What the executive checks first thing Monday morning
KPI cards and simple bar charts only
Sheet 2: “Problem Areas”
Metrics highlighting issues requiring attention
Top 5 departments with highest turnover
Positions open longer than 90 days
Budget variances exceeding 10%
Sheet 3: “Details” (Optional)
Drill-down capability for executives who want to explore
Interactive filters for department, location, time period
Detailed tables with worker-level data
Most executives never go past Sheet 1. That is fine. Sheet 1 solves 90% of their needs.
The Data Source Strategy
Discovery Boards only support indexed data sources.
This is actually good news. It forces you to use performant data sources that load quickly.
High-Performance Data Sources for Executive Dashboards:
Workers (indexed, fast)
Positions (indexed if Position Management enabled)
Organizations (indexed, fast)
Compensation (indexed for current compensation)
Recruiting (indexed for active requisitions)
Data Sources to Avoid:
Worker History (not indexed, slow for large datasets)
All Benefit Elections (not indexed unless using current elections filter)
Custom data sources without indexing
If your executive needs historical trend data, use Workday Prism Analytics for pre-aggregated data instead of pulling raw historical transactions in Discovery Boards.
The Refresh Strategy
Executives need current data, not yesterday’s data.
Real-time data sources: Workers, Positions, Organizations update in real-time in Discovery Boards. These are safe for executive dashboards.
Daily refresh data sources: Compensation, recruiting data may have slight delays. Document this clearly: “Data refreshed daily at 2 AM.”
Manual refresh data sources: If you are using Prism Analytics or custom data sources, document the refresh schedule prominently: “Turnover data refreshed weekly on Mondays.”
If the executive makes a decision based on stale data and gets corrected in a meeting, they will never trust your dashboard again.
The Mobile-First Design
Executives check dashboards on their phones more often than on their laptops.
This means:
Visualizations must be readable on mobile screens
KPI cards work better than complex charts
Horizontal bar charts work better than vertical bar charts (easier to read on narrow screens)
Avoid tiny fonts and detailed tables
Test your Discovery Board on a mobile device before sharing with executives. If you cannot read it easily on your phone, they will not use it.
The Five Discovery Boards Executives Actually Use
Based on implementations with 80% or higher adoption, here are five Discovery Board templates that consistently succeed.
Key success factor: Accurate termination reason coding. If termination reasons are inconsistent or generic, the dashboard provides no actionable insight.
Usage pattern: CFO checks Metric 1 and Metric 5 weekly during budget cycles. CHRO checks Metric 4 monthly for equity analysis.
Key success factor: Accurate job profile to compensation grade mappings. If jobs are not properly mapped to compensation grades, compa-ratio is meaningless.
Key success factor: Data quality and privacy. Diversity data must be accurate and voluntarily provided. Dashboard must comply with privacy regulations in your regions.
Building Your Discovery Board: Step-by-Step
Here is the practical implementation process.
Step 1: Identify the Five Questions (30 minutes)
Schedule a 30-minute meeting with the executive.
Ask: “What are the five questions you find yourself asking repeatedly about [headcount/turnover/recruiting/compensation]?”
Do not ask: “What metrics do you want to see?”
Do not ask: “What would you like on a dashboard?”
Ask about questions. Get specific questions. Write them down verbatim.
If the executive says: “I want to know about turnover,” that is not specific enough.
Probe: “When you think about turnover, what specific question are you trying to answer? Is it ‘Which departments have the highest turnover?’ or ‘Is turnover increasing or decreasing?’ or something else?”
Get five specific questions. Write them down. Confirm understanding.
Step 2: Design on Paper First (15 minutes)
Do not open Workday yet.
On paper or whiteboard, sketch how you would answer each of the five questions.
For each question, choose the simplest visualization that answers it:
Status check question: KPI card
Trend question: Line chart
Problem identification question: Bar chart (sorted, top 5 or top 10)
Comparison question: Bar chart or table
Deep dive question: Table with filters
Arrange the five visualizations on your paper. Most important (Question 1) goes top left. Least important (Question 5) goes bottom right.
Show this sketch to the executive. Get confirmation before building anything.
Step 3: Build in Workday Drive (60-90 minutes)
Access Discovery Boards through Workday Drive.
Create new Discovery Board:
Click your profile menu
Select Drive
Click Add New
Select Discovery Board
Build Sheet 1:
Name the sheet clearly: “Headcount at a Glance” (not “Sheet 1”)
Add your first visualization (drag data source, choose viz type)
Configure the visualization to answer Question 1 specifically
Repeat for visualizations 2-5
Arrange visualizations to fit on one screen (no scrolling)
Visualization best practices:
Use KPI cards for single numbers
Use horizontal bar charts for rankings
Use line charts for trends over time
Enable drill-by and show details for interactivity
Configure data labels for clarity
Performance considerations:
Limit to 10 vizzes per sheet
Use indexed data sources only
Avoid complex calculations in visualizations
Test load time (should load in under 5 seconds)
Step 4: Configure Security and Sharing
Discovery Boards use Workday Drive sharing model.
Share with executives:
Click Share button
Add executive as viewer (not editor unless they need to modify)
Consider sharing with security group if multiple executives need access
Discovery Boards respect Workday security model for data access
Important: Test security by viewing as the executive’s persona. Ensure they see the data you intend them to see.
Step 5: Test with Executive (15 minutes)
Schedule a brief screen share with the executive.
Walk through the Discovery Board. For each visualization, explicitly state which question it answers.
Ask: “Does this answer your question [restate their original question]?”
If yes, move to next visualization.
If no, ask: “What is missing?” or “What would make this more useful?”
Take notes. Make adjustments.
Step 6: Document and Train (30 minutes)
Create a one-page guide:
How to access the Discovery Board (link to Drive location)
What each visualization shows
When data is refreshed
Who to contact with questions
Send this guide with your initial share of the Discovery Board.
Step 7: Monitor Adoption (Ongoing)
Track whether the executive actually uses the Discovery Board:
Check view count in Drive (shows how often it is accessed)
Ask for feedback after two weeks: “Are you finding the dashboard useful?”
Watch for whether the executive still asks for the same data via email (if yes, the dashboard is not meeting their needs)
If adoption is low, schedule a follow-up to understand why.
Common Mistakes and How to Fix Them
Mistake 1: Too Many Visualizations
Symptom: Executive opens dashboard, looks overwhelmed, closes it.
Fix: Remove visualizations. You need fewer metrics, not more. Start with three visualizations. Add more only if executive explicitly requests them.
Mistake 2: Wrong Visualization Type
Symptom: Executive says “I cannot tell what this is showing me.”
Fix: Simplify visualization type. KPI cards and bar charts are almost always better than scatter plots, bubble charts, or complex combo charts.
Mistake 3: No Clear Question Answered
Symptom: Executive says “This is interesting, but I still need to [pull report/ask assistant for data].”
Fix: Your dashboard is not answering their actual question. Go back to Step 1. Re-identify the specific question. Rebuild visualization to answer that question directly.
Mistake 4: Data Does Not Match Other Reports
Symptom: Executive says “This shows 523 workers, but the HR report shows 541. Which is right?”
Fix: Document data source and filters explicitly. Add text box on dashboard explaining: “Active workers as of [date], excluding contractors and leave of absence.” Ensure definition matches other reports.
Mistake 5: Stale Data
Symptom: Executive makes comment based on dashboard. Gets corrected with newer data in meeting. Stops using dashboard.
Fix: Document refresh schedule prominently. If data is not real-time, consider whether Discovery Board is right tool or if scheduled report would be better.
When NOT to Use Discovery Boards
Discovery Boards are not always the right solution.
Use traditional reports instead when:
Executive needs data exported to Excel for manipulation
Executive needs detailed worker-level data (hundreds of rows)
Executive needs data that requires complex calculations not supported in Discovery Boards
Data security requirements are complex (Discovery Boards inherit Workday security but have limited customization)
Use Workday Prism Analytics instead when:
Data comes from multiple systems (Workday + external data)
Historical trend analysis requires years of data
Advanced analytics or predictive modeling needed
Data volumes exceed Discovery Board performance capabilities
Measuring Success
Track these metrics to evaluate Discovery Board adoption:
Adoption metrics:
View count per week (from Drive analytics)
Number of executives actively using (viewed in last 7 days)
Reduction in ad-hoc report requests on same topics
Value metrics:
Time saved on manual reporting (hours per week)
Executive satisfaction survey (1-10 scale: “Does this dashboard help you make better decisions?”)
Decision-making speed (time from question to answer reduced)
Target benchmarks:
80% of intended executives view dashboard weekly
60% reduction in ad-hoc report requests on dashboard topics
Executive satisfaction score 8 or higher (out of 10)
Conclusion: Less Is More
The best Discovery Boards are not the most comprehensive. They are not the most visually impressive. They are not the ones that showcase every Discovery Board feature.
The best Discovery Boards answer five specific questions on one page in 90 seconds.
Start small. Five metrics. One page. One specific executive.
Get that working. Get adoption above 80%. Get the executive checking it every Monday morning.
Then build the next one.
Your goal is not to build impressive dashboards. Your goal is to build dashboards that get used.
Tell Me Your Experience
What Discovery Boards have you built that executives actually use? What made them successful?
What Discovery Boards did you build that nobody uses? What went wrong?
Share your experiences in the comments. We learn best from each other’s real-world successes and failures.
When compensation goes wrong in Workday, it is rarely because a single Compensation Plan is misconfigured. It is usually because the entire compensation architecture – Compensation Grades, Grade Profiles, Plans, Packages, Eligibility Rules and Comp Events – was never designed as a single system that HR and Finance both understand. A clean compensation architecture lets you run merit cycles, promotions and market adjustments without manual grids and side spreadsheets.
This guide walks through how to design Plans, Grades and Events so they “click” for HR and Total Rewards but still reconcile cleanly for Finance and Payroll.
Start with job architecture and pay philosophy
Before touching Compensation Plans, check whether your Job Architecture and pay philosophy are clear:
Do you have defined Job Families and Job Profiles for major role groups (HR, Finance, IT, Sales)?
Has Total Rewards defined consistent pay ranges per level, region and job family?
Does Finance understand how headcount cost is modeled (by Grade, Cost Center, Country, etc.)?
If Job Profiles and Compensation Grades are not aligned, Workday will faithfully execute a broken design. Start with a simple baseline:
Each Job Profile should map to a Compensation Grade.
Each Grade should have clear pay ranges, maintained through Grade Profiles by region or other dimensions.
This alignment is the backbone of everything else.
Understand the key building blocks
In Workday, your core compensation components look like this:
Compensation Element: The technical building block that connects to payroll (e.g., Base Salary, Annual Bonus, Car Allowance).
Compensation Plan: The business-facing component of pay (Salary Plan, Bonus Plan, Allowance Plan, Equity Plan).
Compensation Grade: The level or band that defines typical pay ranges for a set of roles.
Compensation Grade Profile: Variations of a Grade by Location, Job Family, or other factors (e.g., Grade 8 – India, Grade 8 – US).
Compensation Package: A bundle of plans and rules that typically applies to a worker group (for example, “Corporate Salaried Package”).
From a practitioner perspective, think:
Elements talk to payroll, Plans talk to HR and managers, Grades talk to Total Rewards, and Packages make this manageable at scale.
Designing Grades and Grade Profiles that work
Compensation Grades ensure equity and structure. Grade Profiles make that structure flexible for regions, jobs and currencies.
Good practices for Grades:
Keep the number of grades manageable (for example, 10–15 for corporate populations rather than dozens per function).
Align grades with clear career levels (Analyst, Senior, Manager, Director, etc.).
Use consistent naming like “G07 – Senior Professional” instead of function-specific names.
Good practices for Grade Profiles:
Use profiles to handle localization – different ranges by country or region for the same grade.
Store min / mid / max and currency on Grade Profiles so HR and managers see guidance during compensation reviews.
Avoid unnecessary profiles where ranges are identical; each profile is a maintenance cost.
HR appreciates Grades and Grade Profiles when they can quickly answer “Is this offer within range?” while Finance appreciates them when pay decisions stay within controlled bands.
Structuring Compensation Plans for clarity
Compensation Plans are where HR, managers and Workday admins spend most of their time. Typical plan types:
Salary Plan (base salary or hourly pay).
Bonus / Incentive Plan (annual bonus, sales incentive).
Allowance Plan (car allowance, mobile allowance, housing).
Equity Plan (RSUs, stock options) in some tenants.
When designing Plans:
Keep one Salary Plan per pay frequency and broad group (for example, one annual plan for salaried employees, one hourly plan for hourly workers).
Separate variable pay into clean plans: “Annual Bonus – Corporate”, “Sales Incentive – Region A”, etc.
Attach the right Compensation Elements to each plan so payroll knows where to post the amounts.
From a usability perspective, managers should see only the plans that apply to the worker. That is handled through Eligibility Rules.
Eligibility Rules and Packages: who gets what
You do not want to assign individual plans directly to every worker. Instead, use Compensation Packages plus Eligibility Rules to keep the structure maintainable.
Design patterns:
Create packages like “Corporate Salaried Package”, “Hourly Operations Package”, “Sales Package”. Each package bundles base, bonus and relevant allowances.
Use Eligibility Rules based on Job Profile, Grade, Worker Type, Company and Location to determine who belongs in which package.
Avoid overlapping eligibility where multiple packages or plans could apply simultaneously, unless that is intentional.
This is also where HR and Finance alignment matters:
HR defines who should be eligible for which pay components.
Finance checks cost impact by grade and package before you finalize rules.
When packages and eligibility are clean, adding a new allowance or tweaking a bonus plan becomes a config update, not a worker-by-worker project.
Making Compensation Events actually make sense
Most real activity happens through staffing events and compensation review events:
Hire, Change Job, Transfer, International Assignment.
Annual Compensation Review / Merit events.
Workday ties Compensation Plans to these events through configuration and Business Processes.
Key tips:
On Hire and Change Job, use Default Compensation from Position, Job Profile, Grade and Package so the right plans and ranges auto-populate.
Design your Compensation Review Process so managers see the relevant guidance: current grade, range, compa-ratio, budget, prior increases.
Prevent “off-cycle chaos” by defining which events can adjust which plans: promotions vs market adjustments vs corrections.
HR wants events that are intuitive in the UI. Finance wants events that can be reconciled to budgets and forecasts. You serve both by ensuring each event uses the same underlying architecture: Grades, Grade Profiles, Plans and Packages.
Reporting that HR and Finance both trust
A strong compensation architecture only pays off if reporting is clear:
HR needs reports like “Pay by Grade and Gender”, “Compa-ratio by Country”, “Bonus Payout vs Target”.
Finance needs “Total Base and Variable Cost by Cost Center and Grade”, “Budget vs Actual for Bonus Plans”.
Design for reporting by:
Always linking Plans to Grade / Grade Profile where appropriate.
Using consistent Compensation Elements so Finance can map Workday outputs to GL accounts.
Building a small set of standard compensation reports that HR, Finance and Total Rewards agree to use.
If stakeholders run different extracts with different logic, they will not agree on “total compensation cost”. Clean architecture plus standard reports avoids that.
Testing, governance and evolution
Compensation is highly sensitive, so treat design like a product:
Test common scenarios: new hire, lateral move with no pay change, promotion with grade change, market adjustment within grade, merit cycle with budget caps.
Validate how changes appear in Worker History, Compensation History and payroll outputs.
Involve HR, Finance and at least one business leader in reviewing the outputs of a test compensation cycle.
Governance ideas:
Maintain a Compensation Architecture Guide that explains Grades, Profiles, Plans, Packages and Governance rules.
Control who can create new Plans or Eligibility Rules; treat them as design artifacts, not quick fixes.
Review compensation configuration annually alongside your pay structure and market data updates.
When Compensation Architecture is designed properly, you stop firefighting mid-cycle issues and start using Workday as a strategic tool for pay decisions. HR sees clear ranges and clean events, Finance sees predictable costs, and employees see a pay structure that feels fair and consistent.
Walking into your Workday tenant to create your first calculated field can feel overwhelming. Where do you start? What security do you need? How does the Formula Assistant actually work? This comprehensive guide walks you through exactlyhow calculated fields are configured, tested, and deployed in a real Workday tenant—from security setup to production activation.
Unlike generic tutorials that show pseudocode, this guide demonstrates the actual Workday tenant interface, real task names, exact navigation paths, security domain configurations, and step-by-step Formula Assistant usage. You’ll learn how Workday administrators actually implement calculated fields in production environments, including security considerations, testing protocols, and maintenance workflows.
Understanding Your Workday Tenant Environment
Before creating calculated fields, understand how your Workday tenant is organized and secured.
Tenant Types and Configuration Environment
Most organizations have multiple Workday tenants:
Implementation Tenant (Sandbox)
Used for configuration, testing, and training
No real employee data (or anonymized data)
Where you build and test all calculated fields first
Typical naming: [CompanyName]_Implementation or [CompanyName]2
Production Tenant
Live system with real employee data
Where employees and managers work daily
Only deploy tested, approved calculated fields here
Typical naming: [CompanyName] or [CompanyName]_Production
Preview Tenant (if applicable)
Optional tenant for testing Workday updates
Gets new Workday features 3-4 weeks early
Used to test calculated fields against upcoming releases
CRITICAL RULE: Always create and test calculated fields in your Implementation/Sandbox tenant first, never directly in Production.
Security Domains: The Foundation of Calculated Field Access
Workday uses security domains to control who can create, edit, view, and use calculated fields.
Custom Field Management Domain
To create system-wide calculated fields, you need access to the Custom Field Management security domain.
What this domain allows:
Create new calculated fields
Edit existing calculated fields
Delete calculated fields
Activate/deactivate calculated fields
View all calculated fields in the tenant
Who should have this access:
Workday Administrators
Senior HCM Implementers
Report Writers (sometimes, depending on organization policy)
Best practice: Limit Custom Field Management domain access to 3-5 key administrators to avoid duplicate fields and maintain consistency.
Create calculated fields that only exist within a single custom report
Useful for one-off calculations not needed system-wide
Doesn’t clutter the global calculated field library
Who typically has this:
Report Writers
Report Administrators
Business analysts creating custom reports
Derived Security: How Calculated Fields Inherit Permissions
Here’s a critical concept many Workday users miss: calculated fields inherit security from their source fields.
Example scenario: You create a calculated field that uses Base Salary (secured to Compensation domain) and Performance Rating (secured to Talent domain).
Who can see calculated field values? Only users who have access to BOTH the Compensation domain AND Talent domain. If a user only has Compensation access, the calculated field returns blank.
Viewing calculated field security:
Open the calculated field in Workday
Click Related Actions → Calculated Field → View Security Groups
Workday displays:
Underlying secured fields
Security domains for each field
Which security groups can access the calculated field
This derived security model ensures calculated fields can’t bypass existing data access controls.
Step-by-Step: Creating a Calculated Field in Your Tenant
Let’s walk through creating an actual calculated field using the real Workday interface.
Real-World Example: Employee Tenure in Months
Business Requirement: Calculate employee tenure in months from hire date to current date for benefits vesting and service awards.
Phase 1: Accessing the Create Calculated Field Task
Method 1: Global Search (Most Common)
Click in the Workday search bar at the top of any page
Type: create calculated
As you type, Workday displays matching tasks
Click on: Create Calculated Field
Pro tip: You can type just the first 3 letters of each word: cre cal and Workday will find the task.
Method 2: Task Navigation (Legacy Method)
Click the Workday menu icon (upper left)
Navigate: System → Custom Fields → Create Calculated Field
Method 3: From Maintain Calculated Fields Report
Search for: Maintain Calculated Fields
Run the report (shows all existing calculated fields)
Scroll to bottom of report
Click: Add New button
The Maintain Calculated Fields report is your control center for managing all calculated fields in your tenant. Bookmark this report for easy access.
Phase 2: The Create Calculated Field Configuration Screen
When you open the Create Calculated Field task, Workday displays the configuration screen with several sections:
Main Configuration Sections:
Field Name – Where you name your calculated field
Business Object – Determines where the field lives (Worker, Position, etc.)
Function – The calculation type you’ll use
Calculation Tab – Where you build your formula
Display Options – How the field appears in reports
Security – View derived security
Phase 3: Configuring the Field Name and Business Object
Field Name Configuration
In the Field Name field, enter:
CF_Worker_Tenure_Months
Workday naming best practices:
Prefix with “CF_” – Makes calculated fields easy to identify in field pickers
Include business object – CF_Worker, CF_Position, CF_Organization
Describe the calculation – Tenure_Months, Total_Compensation, Eligibility_Flag
No spaces – Use underscores: CF_Employee_Tenure not CF Employee Tenure
Max 40 characters – Keep names concise
Examples of good names:
CF_Worker_Tenure_Months ✓
CF_Position_Over_Budget_Flag ✓
CF_Manager_Span_of_Control ✓
CF_Total_Compensation_Currency ✓
Examples of poor names:
Tenure ✗ (no prefix, not descriptive)
CF Employee Tenure Calculation 2024 ✗ (spaces, too long, dated)
My_Custom_Field_1 ✗ (not descriptive)
Business Object Selection
Click the Business Object lookup field. Workday displays a picker with all available business objects.
Most common business objects for HR calculated fields:
Job – Job profile calculations (job family groupings)
For our tenure example, select:Worker
CRITICAL: Business object selection cannot be changed after creation. If you select the wrong object, you must delete and recreate the calculated field.
Add Business Description
Scroll down to the Business Description field.
Enter a comprehensive description:
Calculates employee tenure in complete months from original hire date to current date. Used for benefits vesting calculations, service award eligibility, and retention reporting. Returns blank if hire date is null. Updated real-time on every report execution.
What to include in descriptions:
Purpose – What business need does this solve?
Calculation logic – How does it work?
Source fields – What data does it use?
Usage – Where is this used (reports, business processes, integrations)?
Edge cases – How does it handle missing data?
Maintenance notes – Special considerations
Good documentation prevents duplicate calculated fields and helps future administrators understand intent.
Phase 4: Using the Formula Assistant
Now comes the critical part: building your formula using Workday’s Formula Assistant.
Opening the Formula Assistant
Click the Calculation tab at the top of the screen
Look for the Function field
Click the magnifying glass icon next to Function
This opens the Formula Assistant interface
The Formula Assistant is Workday’s graphical formula builder—you don’t write code, you configure formulas through dropdown menus and field pickers.
Selecting Your Function
The Formula Assistant displays Workday’s function library organized by category:
Function Categories:
Date – Date calculations and formatting
Text – String manipulation
Arithmetic – Mathematical operations
Condition – IF/THEN logic
Boolean – True/False conditions
Lookup – Related object traversal
Aggregation – Sum, Count, Average
For tenure calculation:
Scroll to the Date category
Click to expand Date functions
Select: Date Difference
Click OK or Select
Configuring Function Parameters
After selecting Date Difference, the Formula Assistant displays three parameter fields:
Parameter 1: Start Date
This is where you select the beginning date for the calculation
Click the field picker icon (magnifying glass)
A hierarchical field browser opens showing Worker business object fields
Navigate to: Worker → Employment Data → Hire Date
Click to select Hire Date
The Formula Assistant populates: Worker.Hire_Date
Parameter 2: End Date
This is the end date for the calculation
Click the field picker icon
Instead of selecting a field, click Add Function
Select function: Current Date
This function has no parameters—it just returns today’s date
Retirement Match (Worker > Retirement > Annual Company Match)
Step 2: Create the Calculated Field
Search: Create Calculated Field
Field Name:CF_Worker_Total_Compensation_Annual
Business Object: Worker
Business Description:
Calculates total annual compensation including base salary, target bonus, equity value, employer benefits cost, and retirement match. Used in Total Rewards statements and compensation analysis reports. Values displayed in employee's local currency.
Step 3: Build the Formula
Open Formula Assistant
Since we’re adding multiple values, we’ll use arithmetic operators
Formula structure:
In Workday, you build addition formulas by stacking operators:
Select Arithmetic function category → Add
Parameter configuration:
Value 1: Worker > Compensation > Base Salary
Value 2: Worker > Compensation > Target Bonus Amount
Now we need to add more values. Add another Add function as a nested function:
Step 2: Create the Eligibility Boolean Calculated Field
Search: Create Calculated Field
Field Name:CF_Worker_Benefits_Eligible_Flag
Business Object: Worker
Function: True/False Condition
Step 3: Build Complex Conditional Logic
In Formula Assistant, select: True_False_Condition
Build the logic in layers:
Layer 1: Check Employment Status is Active
Employment_Status = "Active"
Layer 2: Check Age OR Tenure OR Executive qualification
Use Condition functions with OR logic:
(CF_Worker_Age_Years >= 26)
OR
(CF_Worker_Tenure_Months >= 12)
OR
(Job_Level = "Executive")
Layer 3: Exclude Temporary Workers
NOT (Employee_Type = "Temporary")
Complete formula combining all layers:
True_False_Condition(
(Employment_Status = "Active")
AND
(
(CF_Worker_Age_Years >= 26)
OR
(CF_Worker_Tenure_Months >= 12)
OR
(Job_Level = "Executive")
)
AND
NOT (Employee_Type = "Temporary")
)
How to build this in Formula Assistant:
Select True_False_Condition function
In the logical expression parameter, click Add Condition
Build first condition: Employment_Status = “Active”
Click AND operator button
Click Add Group to create nested OR conditions
Inside the group, add three conditions with OR between them
Outside the group, add another AND operator
Add final NOT condition for temporary status
The Formula Assistant displays this as a visual logic tree:
Result: Benefits enrollment now automatically includes/excludes employees based on the calculated field logic. Manual review eliminated, saving 20 HR hours per month.
Advanced Tenant Configuration
Working with the Calculation Tab
The Calculation tab in the calculated field configuration screen provides advanced options:
Available Options:
Function – Select your calculation function
Return Blank When Function in Error – Error handling
Field Type Override – Force specific return type
Decimal Places – For numeric/currency fields
Use Grouping Separators – Add commas to large numbers
Display Options Configuration
The Display tab controls how the calculated field appears in reports:
Display Settings:
Display Name – What users see in field pickers (can differ from technical name)
Description – Tooltip text when users hover over field
Category – Organize related calculated fields together
Prompt-able – Allow use as report prompt
Best practice: Use descriptive display names for business users:
Technical Name: CF_Worker_Tenure_Months
Display Name: Employee Tenure (Months)
Managing Calculated Field Versions
When you need to update a production calculated field:
Safe Update Process:
Don’t edit the production field directly
In your sandbox tenant, create: CF_Worker_Tenure_Months_v2
Build and test the new logic
Create a test report comparing v1 and v2 results
Validate differences are expected
In production, edit the original calculated field
Update the formula to match v2
Save changes
Monitor reports for 48 hours
Why this approach?
Maintains history of the original formula
Allows side-by-side comparison
Reduces risk of breaking existing reports
Provides rollback option if issues arise
Performance Optimization in Your Tenant
Calculated fields can impact report performance.
Performance Testing Methodology
Create a test report with your calculated field
Run against full production data volume (e.g., all 10,000 employees)
Record execution time
If over 60 seconds, investigate optimization
Common Performance Issues
Issue 1: Complex Nested Conditions
Problem: 7+ levels of nested IF statements
Solution: Break into multiple simpler calculated fields
Issue 2: Expensive Aggregations
Problem: Counting or summing across thousands of related records
Solution: Use incremental aggregation or pre-calculate in nightly job
Issue 3: Multiple Related Object Lookups
Problem: Traversing 5+ object relationships
Solution: Flatten data structure or create intermediate calculated fields
Monitoring Performance in Production
Use the Maintain Calculated Fields report to monitor:
This makes calculated fields easier to find in the Maintain Calculated Fields report.
Troubleshooting Common Tenant Issues
Issue: Calculated Field Doesn’t Appear in Reports
Symptoms: After creating calculated field, it’s not visible in report column picker.
Diagnosis Steps:
Check if calculated field is Active
Search: Maintain Calculated Fields
Find your field
Verify Active column shows ✓
Verify correct Business Object
Report must be based on same business object as calculated field
Check Security
Do you have access to underlying fields?
View Security Groups to verify
Resolution:
If inactive: Activate the calculated field
If wrong business object: Recreate on correct object
If security issue: Add to appropriate security group
Issue: Calculated Field Returns Blank Unexpectedly
Symptoms: Calculated field shows blank when you expect a value.
Diagnosis Steps:
Check “Return Blank When Function in Error” setting
Temporarily disable to see actual error
Test with specific worker who shows blank
Verify source fields have values for that worker
Check for null value handling in formula
Resolution:
Add null checks with Condition functions
Verify field pickers selected correct fields
Test formula logic with diverse data
Issue: Report Performance Degrades After Adding Calculated Field
Symptoms: Report that previously ran in 15 seconds now takes 3+ minutes.
Diagnosis Steps:
Run report without calculated field
Compare execution times
Review calculated field complexity
Check for aggregations or multiple lookups
Resolution:
Simplify formula
Break into multiple calculated fields
Use indexed fields as sources
Consider batch calculation alternative
Migration from Sandbox to Production
Pre-Migration Checklist
Before migrating calculated fields to production:
✓ Testing Complete:
☐ Unit testing with diverse workers passed
☐ Report testing validated accuracy
☐ UAT approval received from business users
☐ Performance testing shows acceptable runtime
✓ Documentation:
☐ Business description complete
☐ Usage documented (which reports, processes)
☐ Known limitations noted
☐ Test results documented
✓ Security:
☐ Derived security reviewed
☐ Access tested with different roles
☐ Sensitive data handling verified
✓ Deployment Plan:
☐ Change window scheduled
☐ Stakeholders notified
☐ Rollback plan prepared
☐ Post-deployment monitoring planned
Migration Process
Step 1: Document Sandbox Configuration
Open calculated field in sandbox
Take screenshots of all configuration tabs
Copy formula text
Document parameter values
Export PDF of configuration
Step 2: Create in Production Tenant
Login to production tenant
Search: Create Calculated Field
Recreate exact configuration from sandbox
Copy formula from documentation
Save (inactive)
Step 3: Production Testing
Test with 10-20 production workers
Compare results to sandbox expected values
Verify no errors
Check performance with production data volume
Step 4: Activate
Activate calculated field
Test immediately in a simple report
Monitor system performance for 30 minutes
Check for error logs
Step 5: Post-Deployment Communication
Email report writers that new field is available
Update internal documentation
Add to calculated field catalog
Schedule follow-up review in 2 weeks
Best Practices for Tenant Management
Quarterly Calculated Field Audit
Every 90 days, review all calculated fields:
Run Maintain Calculated Fields report
Sort by Reference Count
Identify unused fields (Reference Count = 0)
Review if still needed or can be deactivated
Update descriptions for clarity
Test critical high-usage fields
Calculated Field Library Documentation
Maintain an internal knowledge base:
Document for each calculated field:
Business purpose and use cases
Formula logic explanation
Example calculations
Known limitations
Reports and processes that use it
Owner and SME contacts
Change history
Training for Report Writers
Conduct quarterly training sessions:
Training Topics:
How to find calculated fields in column pickers
Understanding calculated field naming conventions
When to request new calculated fields
Testing calculated fields in reports
Troubleshooting blank values
Conclusion
Implementing calculated fields in your Workday tenant requires understanding not just formulas, but the complete configuration ecosystem. From security domain setup to Formula Assistant navigation, from testing protocols to production deployment, each step ensures reliable, performant calculated fields that solve real business problems.
Start with simple calculations like tenure to learn the tenant interface, then progressively build more complex conditional logic and multi-field calculations. Always test thoroughly in your sandbox environment, document comprehensively, and follow organizational governance standards.
The Maintain Calculated Fields report is your control center—bookmark it, review it regularly, and use it to audit your calculated field library quarterly. With proper tenant management practices, calculated fields become a strategic asset that eliminates manual work, ensures data consistency, and enables self-service analytics across your organization.
Now you’re ready to login to your Workday tenant and start building production-ready calculated fields that transform your HR operations.
In Workday, payroll is only as clean as the HR data feeding it. Workday Payroll takes worker, compensation, time, absence and benefits data from HCM and transforms it into earnings, deductions and net pay. When the upstream setup is weak, payroll teams compensate with manual overrides and off-system calculations. When the core HR configuration is strong, payroll becomes a predictable engine HR and Finance trust.
This guide walks through how HR data really drives payroll in Workday – focusing on Earnings, Deductions, Pay Components, Pay Groups and the critical setup decisions to get right.
How HCM data flows into Workday Payroll
Workday is designed so that HCM and Payroll share a single worker record and data core. The key inputs include:
Personal and job data: worker status, Company, Location, Worker Type, Job Profile, Position, Cost Center, Worktags.
Time and absence data: Time Tracking entries and Absence Management (Time Off and Leave).
Benefits data: enrollments that drive benefit deductions.
Workday Payroll uses this information to determine which Earnings and Deductions apply, how much to calculate, and which Pay Group and Payroll Schedule to use. Think of HCM as defining “who the worker is and how they should be paid”, and Payroll as executing “what to pay and when”.
Earnings and Deductions: the building blocks
At the heart of Workday Payroll are Earnings, Deductions and Taxes, often surfaced as Pay Components in configuration.
Deductions: benefits contributions, garnishments, voluntary deductions, other statutory items depending on country.
Taxes: country-specific and jurisdiction-level taxes, often with their own setup and rules.
Critical points for a practitioner:
Each Compensation Element in HCM should map clearly to one or more Earning components in Payroll (for example, Base Salary → Regular Earnings).
Benefits configuration must drive the right Deduction components for each plan, based on enrollment and eligibility.
Time and absence must be mapped to earnings correctly (e.g., Regular vs Overtime vs Unpaid) so hours convert to pay consistently.
When these mappings are fuzzy, payroll results may technically run, but Finance will not trust the breakdown.
Pay Groups: organizing who gets paid when
Pay Groups are how Workday organises workers for payroll processing. They determine shared rules such as pay frequency, pay period, and which configuration applies to that segment of employees.
Typical Pay Group patterns:
Separate groups by pay frequency: Monthly, Biweekly, Weekly.
Separate by country or legal entity when statutory rules differ.
Sometimes separate by worker type (e.g., “US Hourly”, “US Salaried”, “India Salaried”).
Key design considerations:
Build Pay Group assignment rules that use HCM data – such as Company, Worker Type, Location – so workers default into the correct Pay Group automatically.
Align Pay Group schedules with Time Tracking and Absence periods to avoid misaligned cut-offs and partial data.
Keep the number of Pay Groups manageable. Too many groups makes processing and troubleshooting complex.
From a practitioner viewpoint, Pay Groups are where HR and Payroll alignment is most visible: HR defines populations; Payroll defines when and how often each should be paid.
Critical HR setup decisions that impact payroll
Several HR configuration choices directly influence payroll accuracy:
Compensation structure
Clean Compensation Plans and Grades ensure predictable base pay calculations.
Consistent use of Compensation Elements allows each plan to map to the correct earning type.
Worker data quality
Correct Company, Cost Center, Location and Supervisory Organization ensure proper tax, GL posting and security.
Accurate FTE, Work Schedule and Hire / Termination Dates drive proration and eligibility.
Time and absence integration
Time Entry Codes must be mapped to the right earnings (Regular, Overtime, Holiday Pay, etc.).
Time Off and Leave types must indicate whether they are paid, unpaid, or partially paid, and how they feed payroll.
Benefits enrollment
Effective-dated enrollment data must be aligned with payroll periods to avoid missing or double deductions.
HR teams sometimes see these as “downstream” issues, but in Workday they are part of core HCM design.
Payroll processing framework: where everything comes together
Workday’s Payroll Processing Framework uses Period Schedules, Run Categories, Calculation Rules and Pay Calendars to drive each payroll cycle.
At a high level:
Period Schedules define the start and end dates of each pay period.
Run Categories distinguish regular runs, off-cycle runs, bonus-only runs, etc.
Pay Calendars tie Pay Groups to period schedules and payment dates.
HR data feeds into each run according to:
Which workers belong to the Pay Group and are Active in that period.
What changes occurred within the period (hires, terminations, job changes, comp changes).
What time and absence data is approved before cut-off.
If HR processes are not aligned with payroll cut-offs (for example, job changes approved after payroll has already started), you see late or retro adjustments in pay results.
Integrating Workday HCM with third‑party payroll
Many organizations use Workday HCM with an external payroll engine. In these cases, HR data still drives payroll, but via integrations.
Key integration concepts:
Use Workday Cloud Connect for Third-Party Payroll or partner solutions to send worker, time, absence and comp data to payroll vendors.
Design stable outbound files or APIs that include unique worker IDs, pay components, and effective-dated changes.
Ensure inbound results (pay results, payslips, tax data) are loaded back into Workday for reporting and employee self-service.
The same HR decisions still matter; the difference is that errors surface in external payroll results rather than Workday Payroll.
Governance, testing and working like one team
To make HR data truly drive payroll in a controlled way, treat configuration as a shared responsibility:
Establish a regular HR–Payroll design forum for reviewing changes to compensation, time, absence or benefits that impact payroll.
Test end-to-end scenarios: hire mid-period, job change with grade change, retro compensation adjustment, long leave, and cross-period transfers.
Build core reports for reconciliation: “Payroll Input vs HCM Changes”, “Earnings and Deductions by Pay Group”, “Retro Differences by Period”.
HR does not need to be payroll experts, but HRIS and HR leaders should understand how Earnings, Deductions, Pay Groups and HCM configuration link to every payslip.
When HR data is clean and designed with payroll in mind, Workday becomes a single, reliable system of record for people and pay. Payroll teams stop patching bad inputs, Finance gains a clear view of labor cost, and employees simply get paid correctly and on time.
