Building Workday for scale means designing from day one for thousands of workers across dozens of countries, millions of transactions, and hundreds of integrations and reports—not retrofitting later when performance crumbles. Multi-country, high-volume tenants fail when they scale linearly: each new country adds complexity, each new integration slows the system, and each new report duplicates logic. The organizations that succeed standardize globally, optimize relentlessly and govern tightly from the start.
This guide walks through proven strategies for building scalable Workday tenants that perform well across geographies and volumes.
Principle 1: Design a global Foundation Data Model (FDM) from the start
The FDM—Companies, Worktags, hierarchies and org structures—is the backbone of scalability. A poorly designed FDM becomes a constraint; a well-designed one enables growth without rework.
Best practices for global FDM:
Anticipate growth in the design
Plan for companies, locations and org structures you do not have yet but expect within 2–3 years.
Avoid hard-coding assumptions (e.g., “we only have US payroll”) that limit expansion.
Standardize Worktags globally with regional flexibility
Use consistent global Worktags (Cost Center, Project, Region, Business Unit) while allowing country-specific values where needed (e.g., local statutory reporting dimensions).
Keep Worktag hierarchies simple so they scale without becoming unmaintainable.
Single vs multi-tenant considerations
For most global organizations, a single tenant with multiple companies and countries is optimal for consolidation, reporting and shared services.
Only consider multi-tenant if legal, compliance or operational autonomy requirements truly demand separation.
A scalable FDM supports adding new countries, acquisitions and business units without redesigning the core.
Principle 2: Standardize globally, localize only where required
The most common scalability mistake is building unique configurations per country instead of a global core with local extensions.
Global standardization patterns:
Core business processes
Standardize hire, terminate, comp change, requisition and journal processes globally.
Add country-specific steps or validations only where labor law, compliance or tax requires it (e.g., works council approvals in Germany, statutory notifications in France).
Security model
Build a global role model (HR Partner, Recruiter, Payroll Admin, Finance Analyst) and assign consistently across countries.
Create global templates for headcount, turnover, cost and performance reports; allow filtering by country/region rather than building separate reports.
Localization where needed:
Country-specific payroll rules, tax codes, benefits plans and statutory reporting.
Local language support for workers and managers (multi-language UI, translated content).
The rule: default to global, prove the need for local.
Principle 3: Optimize reports for performance at scale
In high-volume tenants, poorly designed reports become unusable: timeouts, slow load times and incorrect results.
Performance strategies:
Narrow data sources
Avoid “All Workers” or “All Active and Terminated” when you can scope to specific orgs, countries or time ranges.
Use prompts to let users filter (e.g., by Company, Region, Date Range) instead of loading everything.
Limit calculated fields in large reports
Heavy calculated fields evaluating across millions of rows kill performance.
Move complex logic to report-level fields or pre-compute via scheduled processes.
Leverage Workday Prism for heavy analytics
For complex, high-volume analytics (multi-year trends, cross-module analysis), use Workday Prism Analytics to stage data outside transactional reports.
Standard report templates
Create a library of reusable, optimized report templates for common needs (headcount, turnover, cost) rather than letting each region build from scratch.
Report performance is a top complaint in scaled tenants; proactive optimization prevents it.
Principle 4: Build integrations for scale and resilience
In multi-country tenants, integrations multiply: local payroll systems, regional time vendors, country-specific benefits providers. Poor integration architecture becomes a bottleneck.
Scalable integration patterns:
Standardized templates with regional extensions
Develop core integration templates (e.g., “Payroll Outbound”, “Time Inbound”) and extend them per country rather than building unique integrations per region.
Use parameters and conditional logic to handle country-specific variations within a single integration framework.
CI/CD and integration lifecycle management
Adopt continuous integration/continuous deployment (CI/CD) pipelines for Workday Studio and middleware integrations to improve reliability and speed.
Version control integration code and configurations so rollbacks are possible.
Centralized monitoring and alerting
Use a single monitoring dashboard for all integrations (global and regional) to catch failures quickly.
Define clear escalation paths and SLAs for critical integrations (payroll, banking, time).
Event-driven vs batch strategies
For high-frequency, low-latency needs (real-time provisioning), use event-driven integrations.
For high-volume, periodic loads (payroll results, time imports), use optimized batch with delta logic to reduce data transfer.
Scalable integration architecture prevents the “we have 50 slightly different payroll integrations” problem.
Principle 5: Governance for multi-country complexity
Without governance, multi-country tenants descend into chaos: each region demands custom configs, security drifts, and no one knows what is standard vs exception.
Governance structures for scale:
Global Center of Excellence (CoE)
Establish a centralized Workday CoE responsible for standards, architecture decisions and tenant health.
Include regional representatives to balance global consistency with local needs.
Clear decision rights
Define which decisions are centralized (FDM, security model, core BPs, integrations) vs decentralized (local BP steps, country-specific fields).
Use a RACI model to avoid ambiguity.
Change control and configuration management
Require impact analysis and approval for changes affecting multiple countries or core design.
Maintain a configuration baseline and track deviations per country.
Regional rollout strategy
Deploy Workday in waves (e.g., pilot country → region → global) to learn and refine before full scale.
Use lessons from early rollouts to improve templates and processes for later countries.
Governance prevents “every country is special” syndrome.
Principle 6: Plan capacity and test at scale
High-volume tenants must validate that Workday can handle peak loads: open enrollment for 100K employees, year-end comp cycles, quarterly merit processes.
Testing for scale:
Load and volume testing
Simulate realistic peak scenarios: thousands of concurrent users, mass data imports, heavy report usage.
Identify bottlenecks (slow BPs, timeouts, integration failures) before production.
Multi-country regression testing
When changes are made, test across representative countries to ensure nothing breaks in localized configuration
Performance benchmarking
Establish baseline performance metrics (report load times, BP completion rates) and monitor trends as volume grows.
Testing at scale is expensive but essential; production is not the place to discover capacity limits.
Principle 7: Leverage Workday’s scalability features
Workday is architected for scale, but you must use its features intentionally:
Multi-country payroll and Cloud Connect
Use Workday’s certified global payroll partners and Cloud Connect integrations to avoid reinventing payroll interfaces per country.
Workday Success Plans and health checks
For large enterprises, Workday offers Accelerate Plus and technical account management to proactively optimize tenant performance.
Release adoption
Workday delivers improvements with every release; adopt new features that simplify or replace custom solutions.
Scalability is not just smart design, it is also leveraging the platform’s continuous innovation.
Building Workday for scale is ultimately about designing globally, optimizing continuously and governing tightly. When FDM, processes, reports and integrations are architected for thousands of workers and dozens of countries from day one, growth becomes an opportunity instead of a crisis.
If you manage Workday integrations for a global organization, you have probably encountered this frustrating scenario:
A worker in Melbourne is terminated on May 14. HR completes the termination in Workday. The worker’s last day passes. But their account in Microsoft Entra ID (formerly Azure AD) stays active until May 15—nearly 17 hours later.
Security escalates. Compliance asks questions. And you explain: “It’s the ISU timezone issue.”
For years, this was the reality of Workday-to-Entra ID integrations. Workday’s Integration Service Units (ISUs) run in Pacific Time, which means termination attributes were only fetched after midnight PT—creating significant delays for Asia-Pacific users.
Microsoft recently fixed this with a 24-hour termination look-ahead feature in the Entra ID Workday connector. This simple change eliminates nearly a full day of delay for APAC terminations, improves compliance, and reduces orphaned account risk.
This guide explains the problem, the solution, and how to configure Workday-Entra ID integrations for global organizations.
The Problem: ISU Timezone Delays in Workday Integrations
How Workday ISU Runs in Pacific Time
Workday Integration Service Units (ISUs) are system users that execute integrations, scheduled reports, and outbound data feeds. Every ISU operates in Pacific Time (PT)—specifically, PST in winter and PDT in summer.
This is not configurable. You cannot change the ISU timezone to match your tenant timezone or your user’s geography.
Why does this matter?
When you configure a Workday-to-Entra ID provisioning integration, the connector queries Workday for worker data—including termination attributes like:
StatusTerminationDate – The effective termination date
StatusTerminationLastDayOfWork – The worker’s last physical day of work
These attributes determine when Entra ID should disable the user account and trigger offboarding workflows.
But here’s the catch: the integration only fetches updated termination data after midnight Pacific Time.
For users in Asia-Pacific, that creates a significant delay.
Real-World Impact: Termination Delays by Region
Let’s walk through a real example.
Scenario: A worker in Melbourne, Australia (UTC +10) is terminated on May 14, 2025. Their StatusTerminationDate in Workday is set to 2025-05-14.
Expected Behavior: The user’s Entra ID account should be disabled on May 14, Melbourne time.
Actual Behavior (Before the Fix): The Workday ISU runs in Pacific Time. Midnight PT is 5:00 PM AEST on May 15 (17 hours later).
That means the termination attribute does not appear in the Entra ID provisioning feed until May 15, 5:00 PM Melbourne time.
The worker’s account stays active for nearly a full extra day—long after their last day of work.
Timezone Delays by Region
Here are the delays before Microsoft’s fix:
Region
Timezone
Hours Ahead of PT
Delay Impact
India (IST)
UTC +5:30
~13.5 hours
Termination attributes appear ~1:30 PM IST the next day
Australia (AEST)
UTC +10
~17 hours
Termination attributes appear ~5 PM AEST the next day
Singapore (SGT)
UTC +8
~15 hours
Termination attributes appear ~3 PM SGT the next day
Japan (JST)
UTC +9
~16 hours
Termination attributes appear ~4 PM JST the next day
For a global organization with thousands of workers in APAC, this creates:
Security risk – Terminated users retain system access after their last day
Compliance issues – Off-boarding SLAs are missed
Audit failures – Access reviews show terminated users as “active”
Operational friction – IT teams manually disable accounts to close the gap
The Solution: Microsoft’s 24-Hour Termination Look-Ahead
What Microsoft Changed
Microsoft added a 24-hour look-ahead query to the Workday connector in Microsoft Entra ID.
Instead of waiting until after midnight PT to fetch termination data, the connector now queries Workday for terminations that will occur within the next 24 hours, starting from the current moment in Pacific Time.
This means termination attributes appear in Entra ID provisioning feeds as soon as the termination day starts in PT—effectively bringing Asia-Pacific terminations forward by almost a full day.
How the Look-Ahead Works
Here’s the technical flow:
Before the Fix:
Worker is terminated in Workday with StatusTerminationDate = 2025-05-14
Entra ID provisioning job runs every 40 minutes (default schedule)
Each sync queries Workday for workers where StatusTerminationDate ≤ Current Date in PT
If current PT date is still May 13, the worker does not appear in the feed
After midnight PT (now May 14 in PT), the next sync picks up the termination
For APAC users, this happens 13-17 hours after May 14 started in their local timezone
After the Fix (with 24-Hour Look-Ahead Enabled):
Worker is terminated in Workday with StatusTerminationDate = 2025-05-14
Entra ID provisioning job queries Workday for workers where StatusTerminationDate falls within Current PT Date + 24 hours
As soon as PT reaches May 13 at midnight (which is already May 14 in APAC), the termination appears in the feed
User account is disabled in Entra ID on May 14 in APAC local time
Improved Timelines by Region
With the 24-hour look-ahead enabled, termination attributes now appear:
Region
Timezone
Attribute Appears By
Improvement
India (IST)
UTC +5:30
May 14, ~1:30 PM IST
Same day termination ✅
Australia (AEST)
UTC +10
May 14, ~5 PM AEST
Same day termination ✅
Singapore (SGT)
UTC +8
May 14, ~3 PM SGT
Same day termination ✅
Japan (JST)
UTC +9
May 14, ~4 PM JST
Same day termination ✅
For most APAC users, accounts are now disabled within hours of their local termination date, instead of the next day.
How to Enable Termination Look-Ahead in Entra ID
Step 1: Navigate to the Workday Provisioning App
Sign in to the Microsoft Entra Admin Center as at least a Lifecycle Workflows Administrator
Navigate to Identity > Applications > Enterprise Applications
Search for your Workday to Entra ID provisioning app
Step 2: Enable the Termination Look-Ahead Feature
Select Provisioning from the left menu
Under Settings, find Termination Look-Ahead (or similar feature toggle)
Enable the 24-hour look-ahead query option
Save the configuration
Note: This feature may be enabled by default for newly configured Workday provisioning apps created after October 2025.
Step 3: Configure Attribute Mappings for Termination
Ensure your attribute mappings include termination-related fields:
Key Workday Attributes:
StatusTerminationDate → Maps to employeeLeaveDateTime in Entra ID
StatusTerminationLastDayOfWork → Can be used for lifecycle workflow triggers
StatusActive → Maps to accountEnabled (set to False when terminated)
Recommended Mapping:
Source Attribute:StatusTerminationDate
Target Attribute:employeeLeaveDateTime
Mapping Type: Direct
Apply this mapping: Always
Step 4: Configure Lifecycle Workflows for Termination
Microsoft Entra ID Governance includes Lifecycle Workflows that automate offboarding tasks based on termination data.
Common Leaver Workflow Tasks:
Disable user account on last day
Remove all license assignments
Remove user from all groups
Cancel pending access package requests
Send email to manager before/on/after last day
Delete user account X days after termination
How to Configure:
Navigate to Identity Governance > Lifecycle Workflows
Select Real-time employee termination template
Configure execution conditions based on employeeLeaveDateTime
3. Better Compliance with Regional Off-Boarding SLAs
Many organizations have strict off-boarding SLAs:
Disable accounts on the last day of work
Revoke access within 4 hours of termination
Complete offboarding tasks within 24 hours
When ISU timezone delays push terminations to the next day, these SLAs fail.
The look-ahead feature restores compliance.
4. Seamless Experience for Lifecycle Workflows
Lifecycle workflows depend on accurate, timely termination data.
If employeeLeaveDateTime is delayed by 17 hours, workflows that should trigger “on last day” instead trigger the next day.
The look-ahead ensures workflows execute when they should, not when ISU timezone allows.
Best Practices for Workday-Entra ID Termination Integrations
1. Enable the 24-Hour Look-Ahead
If you operate globally, enable this feature immediately.
2. Map StatusTerminationDate to employeeLeaveDateTime
This is the canonical termination field in Entra ID and the trigger for lifecycle workflows.
3. Test Terminations Across Timezones
Before go-live, test terminations for workers in:
US (PT/ET)
EMEA (GMT/CET)
APAC (IST/AEST/JST)
Validate that accounts disable on the correct day in each region.
4. Use Lifecycle Workflows for Automation
Do not rely on manual disablement. Configure lifecycle workflows to:
Disable accounts automatically on last day
Remove licenses and group memberships
Notify managers and IT teams
5. Monitor Provisioning Logs for Delays
Entra ID provisioning logs show when termination attributes are detected and when accounts are disabled.
If you see delays exceeding expected thresholds, investigate:
Is the look-ahead feature enabled?
Are attribute mappings correct?
Is the provisioning job running on schedule?
6. Document Timezone Behavior for Stakeholders
HR and Security teams need to understand that:
Workday ISU runs in Pacific Time
Terminations for APAC users may not disable immediately at midnight local time
The look-ahead feature minimizes—but does not eliminate—timezone delays
Set realistic SLAs (e.g., “accounts disabled within 12 hours of local termination date”).
Other ISU Timezone Considerations
The termination look-ahead solves one problem, but ISU timezone behavior affects other integrations too.
Scheduled Reports and RaaS
If you run scheduled reports (RaaS) via ISU, they execute in Pacific Time.
Example: A report scheduled for “8:00 AM daily” runs at 8:00 AM PT, not your tenant timezone or user timezone.
Workaround: Use calculated fields to adjust timestamps or schedule reports relative to PT.
DateTime Fields in Integrations
DateTime objects returned by ISU-executed integrations always display Pacific Time.
If you need UTC or another timezone, create calculated fields in Workday to convert timestamps before they reach the integration.
Business Process Notifications
Business process notifications triggered by integrations (e.g., “worker terminated”) use Pacific Time for timestamps.
Users may see “Completed On: May 13, 11:00 PM PT” when the action actually occurred May 14, 2:00 PM AEST.
Fix: Educate users that ISU-driven timestamps reflect PT, not local time.
Final Thoughts: A Simple Fix with Big Impact
The Microsoft Entra ID 24-hour termination look-ahead is a simple timezone fix that delivers massive operational value for global organizations.
Before this feature:
APAC users stayed active 13-17 hours after termination
IT teams manually disabled accounts to close security gaps
Compliance SLAs failed for same-day offboarding
After this feature:
Terminations appear on the correct day for APAC users
Lifecycle workflows trigger when they should
Orphaned account risk drops significantly
If you manage Workday-Entra ID integrations for a global workforce, enable the termination look-ahead, configure lifecycle workflows, and test terminations across timezones.
A small configuration change. A big leap for global IAM operations.