peopletechguide.com

Blog

  • Designing a Trusted Reporting Layer in Workday

    Why a “reporting layer” matters

    A trusted reporting layer in Workday is less about flashy dashboards and more about shared logic: one set of calculated fields and patterns that HR and Finance reuse across hundreds of reports, scorecards and integrations. Without this layer, each report writer re‑implements logic (tenure, FTE, headcount, comp metrics, margins), leading to conflicting numbers and low trust.​

    Calculated fields are the engine of that layer: they turn raw Workday data into analytics‑ready metrics without custom code.​

    Governance basics for calculated fields

    Before patterns, there needs to be discipline. Key governance practices:

    • Create global fields only when reusable
      • Use tenant‑wide calculated fields for metrics you know will appear in many reports (tenure, age, FTE, total comp, margin).​
      • Keep one‑off logic as report‑specific calculated fields to avoid polluting the global namespace.​
    • Name and document clearly
      • Use descriptive names like HR_Tenure_Years, FIN_Project_Gross_Margin_Pct, and store purpose, formula and owner in a simple catalog.​
    • Keep formulas as simple as possible
      • Break complex logic into smaller helper fields instead of one giant IF/CASE chain; this improves maintainability and performance.​

    This governance is what turns calculated fields from “sprawl” into a coherent reporting layer.​

    Core HR calculated field patterns

    These HR patterns appear in almost every serious tenant; making them global and standard is what builds trust.

    1. Tenure and service metrics
      • Fields like “Tenure in Years”, “Tenure Band” (0–1, 1–3, 3–5, 5+), and “Service Date for Benefits” based on hire/rehire dates and worker history.​
      • Used for attrition analysis, promotion eligibility, benefits, and career-path analytics.
    2. Headcount and FTE flags
      • Boolean fields like “Is Headcount”, “Is Active Employee”, “Is Contingent Worker”, and numeric “FTE Value” derived from standard hours and job data.​
      • These underpin headcount, FTE, and span-of-control reporting across HR and Finance.
    3. Demographic and cohort bucketing
      • Age buckets, generation labels, service bands, job‑level buckets using IF/CASE logic on age, service and job profile.​
      • These fuel diversity, equity and inclusion dashboards and workforce planning views.
    4. Compensation rollups
      • “Annualized Base Pay”, “Total Target Cash”, “Total Rewards Value” that aggregate multiple comp components with date‑aware logic.​

    Standardizing these HR fields ensures everyone slices workforce data on the same definitions.​

    Core Finance calculated field patterns

    For Finance, calculated fields often sit on journals, ledger, spend, revenue and project business objects.

    1. Normalized amount and currency
      • Fields that convert transaction or ledger amounts into a single reporting currency using rate tables, so analytics do not re‑implement conversion.​
    2. Account and Worktag groupings
      • Text fields that map detailed accounts/Worktags into reporting buckets (“Opex vs COGS vs Capex”, “Travel vs Marketing vs IT”) for P&L and cost analytics.​
    3. Margin and profitability metrics
      • Project or contract‑level gross margin %, contribution margin, and variance metrics built from revenue and cost measures.​
    4. Period‑aware flags
      • “Is Current Month”, “Is QTD”, “Is YTD” booleans based on accounting date to simplify time-bucket reporting.​

    These fields let you reuse Finance logic across GL reports, revenue dashboards, project views and even Prism datasets.​

    Reusable expression patterns that work everywhere

    Across HR and Finance, a handful of formula types show up repeatedly:

    • Date difference and banding
      • Use date difference to derive age, tenure, time-in-role, then wrap in IF/CASE logic for buckets.​
    • Lookup Related Value instead of nested IFs
      • Pull attributes (for example, region, cost bucket, leadership area) from related objects rather than hard‑coding lists.​
    • Boolean flags as building blocks
      • Create small true/false fields (is active, is restricted country, is bonus eligible) and reuse them instead of re‑expressing logic.​
    • Aggregate‑then‑derive patterns
      • Aggregate transaction-level data (sum, count, average) by worker, project, cost center, then derive ratios or scores from those aggregates.​

    These patterns keep formulas clear and reusable, which is essential for a trusted layer.​

    Performance and scalability considerations

    A reporting layer that times out is not trusted. Performance patterns:

    • Use report-level fields for one-offs
      • If logic is needed in a single heavy report, keep it report-specific to avoid cluttering tenant‑wide fields and indexes.​​
    • Evaluate at extract and avoid over-broad data sources
      • For large datasets, choose “evaluate at extract” and avoid “All Workers” or giant data sources where narrower ones exist.​
    • Refactor expensive CFs
      • Replace repeated date arithmetic or nested IF chains with pre‑computed helper fields; watch run-times and simplify hot spots.​
    • Regular clean-up and catalog reviews
      • Use reports to find unused or duplicate calculated fields and retire them on a schedule.​

    Designing for performance is as important as getting the math right if you want leaders to rely on Workday for analytics.​

    A well‑designed reporting layer in Workday is ultimately a library of governed, reusable calculated fields shared between HR and Finance. When you standardize patterns for tenure, headcount, compensation, margins, buckets and time windows—then manage them like a product—Workday stops being a collection of one‑off reports and becomes a consistent analytics platform everyone can trust.

  • Changing a hire date shouldn’t mean restarting the whole business process

    Changing a hire date shouldn’t mean restarting the whole business process

    When a Simple Hire Date Change Derails Everything

    In a lot of Workday tenants, a basic correction like moving a hire date by a few days—creates disproportionate chaos.

    The pattern is familiar:

    • A recruiter realises the start date is wrong and updates it.
    • Onboarding tasks have already been triggered based on the original date.
    • IT provisioning runs earlier than it should.
    • IT scrambles to pause, reverse, or reschedule work.
    • HR ends up cancelling and re‑launching parts of the hire just to “get things back in sync.”

    All of this friction comes from a single assumption baked into many designs: that the hire date will never change once entered. Reality, of course, is very different.

    Why Hire Date Changes Are Normal, Not Exceptions

    Hire dates move all the time:

    • Candidates negotiate notice periods or personal timelines.
    • Background checks or approvals take longer than planned.
    • Managers or HR mis-key a date in a busy moment.
    • Business needs shift and start dates must be brought forward or pushed out.

    If Workday is configured as if hire dates are frozen in stone, every correction feels dangerous. A robust design accepts that dates will move and ensures the system can handle that gracefully.

    The Real Culprit: Step Delays That Don’t Recalculate

    The underlying issue is rarely Workday’s capability. It’s how step delays are configured in the hire business process.

    A common pattern looks like this:

    • Delays are set relative to the Effective Date (for example, send onboarding communication +3 days after effective date, trigger a task −1 day before, etc.).
    • The configuration is done once, usually during implementation.
    • No one considers what should happen if that Effective Date is corrected later.

    As a result, when the hire date changes, the timing for all downstream steps stays anchored to the old date. Tasks and emails fire too early or too late, even though the hire date in the record has been updated.

    The Workday Setting That Fixes the Problem

    Workday actually includes a setting designed to handle this exact scenario.

    For each relevant step in the business process, you can use Maintain Step Delay to:

    • Set the Field that drives the delay (commonly Effective Date).
    • Enable Recalculate Delay Upon Correct so that when the driving date changes, Workday recalculates all delays based on the new value.

    In practice, that means:

    1. Open the hire business process definition.
    2. Find onboarding, provisioning, or benefits-related steps that use delays.
    3. For each, go into Maintain Step Delay.
    4. Confirm Field = Effective Date (or the appropriate date driver).
    5. Tick Recalculate Delay Upon Correct.
    6. Save and migrate this configuration through your normal change process.

    That one checkbox is often the difference between “date changes are scary” and “date changes are routine.”

    What Changes When You Recalculate Delays

    Once “Recalculate Delay Upon Correct” is enabled, the system behaves in a far more intuitive way.

    When HR updates a hire date:

    • Onboarding emails shift in line with the revised start date instead of going out on the old schedule.
    • IT provisioning tasks line up with the new Day 1, reducing early account creation or equipment deliveries.
    • Benefits and eligibility-related steps adjust so they don’t fire prematurely.
    • HR can correct dates without needing to rebuild or cancel half of the process.

    The workflow follows the reality of the hire, rather than clinging to an outdated date.

    Practical Tips for Configuring Step Delays

    A few field-tested practices can make this setup much more effective:

    • Prioritise onboarding-related steps
      These are the steps most impacted by date changes, so start by enabling recalculation there.
    • Be deliberate about business days vs calendar days
      HR communications often make more sense on business days, while some IT tasks (for example, system activations) may work well with calendar day offsets.
    • Document your delay strategy
      Capture why a step is delayed by +1, +3, or +5 days from the effective date so future admins understand the logic and don’t undo it accidentally.
    • Test corrections in non‑production first
      In a sandbox, run a sample hire through the process, correct the hire date, and watch each step. Confirm that all delayed tasks shift appropriately.
    • Apply the same pattern to other date-sensitive flows
      Terminations, leaves of absence, and probation or review milestones also experience date changes. Recalculation logic can prevent similar headaches there.

    These small pieces of discipline turn a clever configuration option into a reliable part of your operating model.

    The Payoff: Less Noise, Better Experience

    When hire date corrections no longer blow up the process, everyone benefits:

    • HR spends less time cancelling and redoing steps.
    • IT receives cleaner, better-timed requests and fewer emergency messages.
    • New hires and managers receive communications and access when they actually need them, not days early or late.
    • HRIS / Workday teams gain confidence that the system can handle real-world changes without workarounds.

    A hire date change becomes what it should be: a straightforward correction to a real-world schedule, not a mini-reimplementation.

    One configuration change, applied thoughtfully, can remove a surprising amount of friction from your Workday hire process.

  • Understanding Workday Organization Types Right

    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 hierarchySupervisory Organization
    Financial responsibility and budget ownershipCost Center
    Legal entities for payroll, tax, and benefitsCompany
    Geographic groupings (countries, regions)Region
    Matrix teams, projects, business units, or flex workCustom Organization
    Labor councils or employee representative bodiesWork 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.​

    Supervisory Orgs define reporting relationships. Cost Centers define financial responsibility.

    Sometimes they align. Often they do 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 TypeDesign Decision
    CompanyThree Companies: GlobalTech US Inc., GlobalTech UK Ltd., GlobalTech AU Pty (one per legal entity)
    Supervisory OrgFunctional hierarchy: CEO → VPs (Eng, Sales, Marketing, Finance) → Directors → Managers → ICs
    Cost CenterDepartment-based Cost Centers (aligned with GL): Engineering, Sales EMEA, Sales APAC, Marketing, Finance, IT
    RegionFour Regions: Americas, EMEA, APAC, ANZ (for geographic reporting and HR access)
    Custom OrgProduct 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.”

    They are not.

  • Workday Integrations: EIB vs. Studio vs. Core Connectors

    Your HR Director sends you an email:

    “We need to send our payroll data to ADP every two weeks. Also, we need to pull employee benefits elections from our benefits vendor monthly. And IT needs a daily feed of all new hires to provision systems automatically.”

    Three integration requirements. Three different systems. Three different data flows.

    Which Workday integration tool do you use? EIB? Studio? Core Connectors? Or maybe all three?

    This is where most Workday professionals get stuck. They know integration tools exist, but they don’t know which tool to use when. So they force-fit EIB for everything, hit limitations, and spend hours troubleshooting why their integration keeps failing.

    Here’s the reality: Workday gives you three integration tools, and each one is designed for specific scenarios. Using the wrong tool doesn’t just waste time—it creates fragile, unmaintainable integrations that break during updates and require constant manual intervention.​​

    This guide teaches you how to choose the right integration tool for every scenario. You’ll learn what each tool does, when to use it, and how to build integrations correctly with real-world examples.

    Understanding Workday Integration Architecture

    Before diving into specific tools, understand how Workday integrations work at a high level.

    The Integration Landscape

    Every Workday integration involves three components:

    1. Workday (The Source or Target)
    Your Workday tenant containing HCM, Finance, or other module data.

    2. External System (The Other End)
    Third-party applications like payroll systems, benefits vendors, time tracking tools, background check providers, or financial systems.

    3. Integration Tool (The Bridge)
    The mechanism that moves data between Workday and the external system. This is where EIB, Studio, and Core Connectors come in.

    Integration Direction

    Inbound Integration:
    Data flows INTO Workday from external systems.

    Example: Load new hire data from recruiting system into Workday

    Outbound Integration:
    Data flows OUT OF Workday to external systems.

    Example: Send employee demographic data from Workday to payroll vendor

    Bidirectional Integration:
    Data flows both ways between Workday and external systems.

    Example: Workday sends requisition to recruiting system; recruiting system sends candidate data back to Workday

    The Three Integration Tools: What They Actually Do

    Tool 1: EIB (Enterprise Interface Builder)

    What It Is:
    EIB is Workday’s no-code integration tool for simple, file-based data imports and exports. Think of it as an automated spreadsheet loader.​​

    How It Works:

    1. Define which data to extract or import
    2. Map spreadsheet columns to Workday fields
    3. Schedule the integration to run automatically
    4. Workday processes the file and loads/exports data

    File Formats Supported:

    • Excel (.xlsx)
    • CSV (.csv)
    • XML (for more complex structures)

    Key Characteristics:

    • No coding required (100% point-and-click configuration)
    • Template-based (uses predefined Workday data structures)
    • Quick to build (30 minutes to 2 hours for basic integrations)
    • Limited transformation logic (can’t do complex calculations or conditional logic)
    • File-based only (not real-time; scheduled or manual runs)

    Best For:

    • One-time data loads (go-live conversions, annual refreshes)
    • Simple recurring data exchanges (monthly benefit file, weekly payroll extract)
    • Scenarios where source system can produce Excel/CSV files
    • Quick integrations with minimal complexity

    Not Good For:

    • Real-time data synchronization
    • Complex data transformations requiring custom logic
    • Integrations requiring API calls to external systems
    • Error handling beyond basic validation

    Tool 2: Core Connectors (Cloud Connect for Integrations)

    What It Is:
    Core Connectors are pre-built, configurable integration templates for common third-party systems. Think of them as integration “starter kits” that Workday or partners have already built.​

    How It Works:

    1. Workday provides a connector template for specific vendor (e.g., ADP, Kronos, Salesforce)
    2. You configure the connector for your environment (map fields, set schedules, configure endpoints)
    3. Connector handles data transformation, API calls, and error handling automatically
    4. Integration runs in Workday Cloud (no external infrastructure needed)

    Types of Core Connectors:

    End-to-End Connectors:

    • 80-85% pre-configured for specific vendor​
    • Minimal configuration needed (mostly mapping and credentials)
    • Examples: ADP payroll connector, Kronos time tracking connector

    Workday Core Connectors:

    • 50-60% pre-configured​
    • More flexibility, more configuration required
    • Examples: Generic SFTP connector, generic web service connector

    Key Characteristics:

    • Minimal coding (configuration-based with some scripting options)
    • Vendor-specific (built for specific systems like ADP, Kronos, Salesforce)
    • Faster than building from scratch (weeks instead of months)
    • Cloud-based (runs in Workday infrastructure)
    • Maintained by Workday (updates when vendor APIs change)

    Best For:

    • Integrations with common third-party vendors (payroll, benefits, time tracking)
    • Organizations without internal integration development resources
    • Scenarios where pre-built logic matches your requirements (80%+ fit)
    • Recurring integrations that need to be reliable and low-maintenance

    Not Good For:

    • Custom internal systems without existing connectors
    • Highly customized requirements that don’t match connector logic
    • One-off data loads (overkill for simple scenarios)

    Tool 3: Workday Studio

    What It Is:
    Workday Studio is Workday’s developer-focused integration tool for building custom, complex integrations using Java and XSLT. Think of it as a full-featured development environment.​

    How It Works:

    1. Download Workday Studio (Eclipse-based IDE)
    2. Build integration using drag-and-drop components + custom code
    3. Write transformation logic in Java or XSLT
    4. Deploy integration to Workday Cloud Repository
    5. Configure and launch integration from Workday tenant

    Development Components:

    • Assemblies: Building blocks of integrations (web service calls, transformations, routing)
    • Mediation Components: Data transformation and routing logic
    • XSLT Transformations: XML data mapping and manipulation
    • Java Components: Custom business logic and calculations

    Key Characteristics:

    • Full coding control (Java, XSLT, XML)
    • Most flexible (can integrate with any system, any protocol)
    • Handles complex logic (conditional routing, looping, error handling, retries)
    • Requires development skills (Java knowledge essential)
    • Longer build time (weeks to months depending on complexity)

    Best For:

    • Complex integrations requiring custom business logic
    • Real-time API-based integrations
    • Integrations with proprietary or uncommon external systems
    • Scenarios requiring advanced error handling, retries, or conditional routing
    • High-volume data processing requiring optimization

    Not Good For:

    • Simple file-based data loads (EIB is faster)
    • Organizations without Java developers
    • Quick turnaround requirements (takes time to develop and test)
    • Scenarios where Core Connector already exists (don’t reinvent the wheel)

    Decision Framework: Which Tool Should I Use?

    Use this decision tree to choose the right integration tool:​

    Question 1: Is there a pre-built Core Connector for your target system?

    Examples: ADP, Kronos, Salesforce, SuccessFactors, LinkedIn

    Yes → Use Core Connector (80% of use cases fall here )​

    No → Go to Question 2

    Question 2: Is this a simple file-based data exchange with minimal transformation logic?

    Examples:

    • Export employee data to Excel for monthly reporting
    • Import benefit elections from CSV file
    • Load organizational changes from spreadsheet

    Yes → Use EIB (25% of use cases )​

    No → Go to Question 3

    Question 3: Do you need real-time data sync, complex logic, or custom API integration?

    Examples:

    • Real-time employee sync to custom internal portal
    • Integration requiring multi-step approval workflows
    • Complex tax calculation requiring external API calls

    Yes → Use Studio

    No → Re-evaluate your requirements (you might be overcomplicating)

    Real-World Scenarios: Which Tool to Use

    Scenario 1: Monthly Payroll Extract to ADP

    Requirement:
    Send employee demographic and compensation data from Workday to ADP payroll system every two weeks.

    Which Tool: Core Connector (ADP Connector)

    Why:

    • Workday provides pre-built ADP connector​
    • Connector handles ADP API format and authentication
    • Bi-weekly scheduling built-in
    • Error handling and retry logic included
    • Maintained by Workday (updates when ADP API changes)

    Don’t Use EIB: ADP requires specific API format, not file-based

    Don’t Use Studio: Core Connector already exists (no need to build custom)

    Scenario 2: Annual Benefits Election Load

    Requirement:
    Once per year, import benefits elections from Excel file provided by benefits broker.

    Which Tool: Inbound EIB

    Why:

    • One-time annual load (not recurring)
    • Source data is Excel file
    • Simple mapping (spreadsheet columns to Workday benefit fields)
    • No complex logic needed
    • Can build and test in 1-2 hours

    Don’t Use Core Connector: No recurring integration needed, overkill for one-time load

    Don’t Use Studio: Too complex for simple file import

    Scenario 3: Real-Time Badge System Integration

    Requirement:
    When employee is hired in Workday, automatically call internal badge system API to provision access card within 5 minutes.

    Which Tool: Studio

    Why:

    • Real-time requirement (not file-based)
    • Custom internal system (no Core Connector exists)
    • Requires API call to external system
    • Needs error handling (what if badge system is down?)
    • Needs conditional logic (different badge types based on employee location)

    Don’t Use EIB: Not file-based, needs real-time API call

    Don’t Use Core Connector: No pre-built connector for custom badge system

    Scenario 4: Weekly New Hire Report to IT

    Requirement:
    Every Monday, email IT a list of all new hires from the previous week so they can provision laptops.

    Which Tool: Outbound EIB

    Why:

    • Simple data extract (employee name, hire date, location, manager)
    • File-based output (Excel or CSV)
    • Weekly schedule
    • No transformation logic needed
    • IT prefers Excel file (they import to their ticketing system)

    Alternative: Could use Workday Report scheduled delivery (even simpler)

    Don’t Use Core Connector: No external system integration needed

    Don’t Use Studio: Overkill for simple weekly report

    Scenario 5: Bi-Directional Recruiting System Integration

    Requirement:

    • Workday sends requisitions to external recruiting system
    • Recruiting system sends candidate applications back to Workday
    • Real-time synchronization required

    Which Tool: Core Connector (if connector exists for recruiting system) OR Studio (if custom system)

    Why:

    • Bi-directional data flow
    • Real-time requirement
    • Requires API integration (not file-based)
    • Complex error handling needed

    If recruiting system is SuccessFactors or Greenhouse: Use Core Connector

    If recruiting system is custom-built: Use Studio

    Don’t Use EIB: Can’t handle real-time API calls or bidirectional flow

    Building Your First EIB Integration

    Let’s build a practical example: Outbound EIB to export active employees to Excel weekly

    Step 1: Create the EIB

    1. Log into Workday
    2. Search for Create EIB
    3. Integration Name: Active Employee Export – Weekly
    4. Direction: Outbound (data flows OUT of Workday)
    5. Data Source: Workers
    6. Click OK

    Step 2: Select Fields to Export

    Click Add in the Fields section to choose data to export:

    Field 1: Worker (Employee Name)

    Field 2: Employee ID

    Field 3: Hire Date

    Field 4: Primary Position > Job Title

    Field 5: Primary Position > Organization (Department)

    Field 6: Worker’s Manager

    Field 7: Location > Name

    Field 8: Primary Work Email

    Field 9: Worker Status (Active, Leave of Absence, Terminated)

    Step 3: Add Filter

    Click Filter tab.

    Filter Condition: Worker Status = Active

    Why: Only export active employees, exclude terminated and LOA

    Step 4: Configure Output Format

    Click Output tab.

    File Format: Excel (.xlsx)

    File Name: Active_Employees_[Date].xlsx

    Date Token: [Date] automatically inserts current date (e.g., Active_Employees_2025-12-19.xlsx)

    Sheet Name: Active Employees

    Header Row: Yes (include column headers)

    Step 5: Configure Delivery

    Click Delivery tab.

    Delivery Method: Email

    Recipients: it-team@company.com

    Email Subject: Weekly Active Employee Report – [Date]

    Email Body: “Attached is the weekly active employee export as of [Date].”

    Alternative Delivery Methods:

    • SFTP: Upload file to secure FTP server
    • Workday Report: Save as Workday report users can download
    • Cloud Storage: Upload to Box, Google Drive, OneDrive

    Step 6: Schedule the Integration

    Click Schedule tab.

    Frequency: Weekly

    Day of Week: Monday

    Time: 6:00 AM (before business hours)

    Time Zone: Your company’s time zone

    Start Date: Next Monday

    End Date: Leave blank (run indefinitely)

    Step 7: Test the Integration

    Before scheduling, test manually:

    1. Click Launch to run immediately
    2. Check your email for the Excel file
    3. Open the file and validate:
      • All columns present and labeled correctly?
      • Only active employees included?
      • Data accurate (spot-check 10 employees)?

    Common Issues:

    • No data: Check filter (is it too restrictive?)
    • Missing columns: Re-add fields in Step 2
    • File not received: Check delivery settings (correct email address?)

    Step 8: Activate and Monitor

    Once testing passes:

    1. Activate the schedule
    2. Monitor first few runs:
      • Navigate to Integration Event to see execution history
      • Check for errors or warnings
      • Validate file is delivered on time

    Monitoring Best Practices:

    • Set up email alerts for integration failures
    • Review integration event log weekly
    • Document any changes to integration logic

    Building with Core Connectors

    Let’s walk through configuring a Core Connector for ADP Payroll (conceptual example, as specific connectors vary).

    Step 1: Locate the Connector

    1. Search for Browse Integrations Catalog
    2. Filter: Type = Cloud Connect for Integrations
    3. Search: “ADP”
    4. Select: ADP Workforce Now Connector

    Step 2: Review Pre-Built Logic

    Core Connectors come pre-configured with:

    • Data Mappings: Workday fields → ADP API fields (e.g., Worker Name → Employee Name)
    • Transformation Logic: Format conversions (e.g., Date format YYYY-MM-DD → MM/DD/YYYY)
    • Error Handling: Retry logic, validation rules
    • Schedule Templates: Recommended run frequency

    Review Documentation:

    • What Workday data is sent?
    • What ADP fields are populated?
    • What customizations are available?

    Step 3: Configure Endpoint

    Endpoint: The URL and credentials for connecting to ADP.

    Configuration:

    1. Navigate to Edit Integration for ADP Connector
    2. Locate Integration Attributes section
    3. Enter:
      • ADP API URL: Provided by ADP (e.g., https://api.adp.com/v1/payroll)
      • Client ID: Your ADP API client ID
      • Client Secret: Your ADP API secret key
      • Company Code: Your ADP company identifier

    Security: Credentials stored securely in Workday (encrypted)

    Step 4: Map Custom Fields

    While connector provides default mappings, you may need to customize:

    Example Custom Mapping:

    Workday Field: Custom_Badge_Number (custom field on Worker object)

    ADP Field: EmployeeBadgeID

    Configuration:

    1. Navigate to Field Mappings section
    2. Click Add Custom Mapping
    3. Select Workday Field: Worker > Custom Fields > Badge Number
    4. Select ADP Field: EmployeeBadgeID
    5. Save

    Step 5: Configure Schedule

    Frequency: Every two weeks (to align with payroll cycle)

    Day: Friday at 5:00 PM (before payroll processing Monday morning)

    Cut-off Logic: Include only employees with changes since last run (delta processing)

    Step 6: Test in Sandbox

    Never test Core Connectors in production first.

    1. Deploy connector to Sandbox tenant
    2. Configure with ADP test/UAT environment credentials
    3. Run integration manually
    4. Validate data in ADP test environment:
      • All employees transferred?
      • Demographic data accurate?
      • Compensation data correct?
      • Custom fields mapped correctly?

    Step 7: Deploy to Production

    Once testing passes:

    1. Deploy connector to Production tenant
    2. Update credentials to Production ADP environment
    3. Run first execution manually (don’t wait for schedule)
    4. Monitor closely for first month
    5. Set up alerting for failures

    Ongoing Maintenance:

    • Workday updates connector when ADP API changes (automatic)
    • You only maintain custom mappings and credentials
    • Review connector release notes quarterly

    Building Custom Integrations with Studio

    Note: Studio requires Java development skills and Eclipse IDE familiarity. This is a high-level overview.​

    When to Use Studio

    Build with Studio when you need:​

    • Custom business logic beyond what EIB or Core Connectors support
    • Integration with proprietary internal systems
    • Complex conditional routing based on dynamic data
    • Error handling with retries and escalation workflows
    • Real-time API calls triggered by Workday events
    • Processing large datasets requiring performance optimization

    Studio Development Workflow

    Phase 1: Integration Design

    1. Download Workday Studio (Eclipse-based IDE)
    2. Create Integration Project
    3. Design Assembly Flow:
      • Web service call to external system
      • Data transformation (XSLT or Java)
      • Error handling and routing
      • Logging and monitoring

    Phase 2: Development

    1. Build Components:
      • Get Data from Workday: Use Workday web service call
      • Transform Data: XSLT for XML transformation or Java for complex logic
      • Call External API: HTTP connector to external system
      • Handle Response: Parse response, update Workday if needed
    2. Write Custom Logic (Java Example):
    java// Calculate badge access level based on employee job level
if (employee.getJobLevel().equals("Executive")) {
    badgeAccessLevel = "LEVEL_5_EXECUTIVE";
} else if (employee.getDepartment().equals("Engineering")) {
    badgeAccessLevel = "LEVEL_3_TECHNICAL";
} else {
    badgeAccessLevel = "LEVEL_1_STANDARD";
}

    Phase 3: Deployment

    1. Deploy to Workday Cloud Repository from Studio
    2. Configure in Workday Tenant:
      • Set integration permissions
      • Configure notifications
      • Set retry logic
    3. Test in Implementation/Sandbox Tenant

    Phase 4: Launch and Monitor

    1. Launch Integration (manual or scheduled)
    2. Monitor via Integration Event Log
    3. Troubleshoot errors using Studio debugging tools

    Studio Best Practices

    1. Reusable Components:
    Build modular assemblies that can be reused across integrations (e.g., “Transform Workday Worker to JSON” assembly)

    2. Error Handling:
    Always include try-catch blocks and retry logic for external API calls

    3. Logging:
    Add detailed logging at each step for troubleshooting

    4. Performance:
    Use pagination for large datasets (process 1000 records at a time)

    5. Version Control:
    Maintain Studio projects in Git for change tracking

    Integration Comparison Table

    CriteriaEIBCore ConnectorsStudio
    ComplexityLow (no code)Medium (configuration)High (coding required)
    Build TimeHours to daysDays to weeksWeeks to months
    Skills RequiredWorkday adminWorkday integration consultantJava developer + Workday knowledge
    Use Case Volume25% of integrations ​65% of integrations ​10% of integrations
    Data FormatFile-based (Excel, CSV, XML)API-based or file-basedAny (API, files, custom protocols)
    Real-Time CapabilityNo (scheduled only)Yes (for some connectors)Yes (fully customizable)
    Transformation LogicBasic (field mapping)Moderate (configurable rules)Advanced (custom code)
    Error HandlingBasic validationPre-built retry logicFully customizable
    MaintenanceLow (minimal updates needed)Low (Workday maintains)High (custom code requires ongoing support)
    CostIncluded in Workday licenseIncluded or partner feeRequires developer resources

    Common Integration Mistakes and How to Avoid Them

    Mistake 1: Using EIB for Real-Time Integration

    Problem:
    Team builds EIB to “sync” employees from Workday to internal portal. EIB runs every hour. Users complain portal is out of sync.

    Why It Fails:
    EIB is file-based and scheduled. It can’t provide real-time synchronization.

    Solution:
    Use Studio with event-driven trigger (when employee is hired or changed, immediately call portal API).

    Mistake 2: Building Custom Studio Integration When Core Connector Exists

    Problem:
    Team spends 3 months building custom Studio integration for ADP payroll. Later discovers Workday provides pre-built ADP connector.

    Impact:
    Wasted time, ongoing maintenance burden, more brittle than using supported connector.

    Solution:
    Always check Browse Integrations Catalog before building custom integration.

    Mistake 3: No Error Handling in Integrations

    Problem:
    EIB runs nightly to export payroll data. One night it fails silently (file not delivered). Payroll team doesn’t notice until payday.

    Solution:

    • Enable email notifications for integration failures
    • Set up monitoring dashboard for all integrations
    • Include retry logic (for Studio integrations)
    • Document escalation process (who to contact if integration fails?)

    Mistake 4: Not Testing in Sandbox First

    Problem:
    Team deploys Core Connector directly to Production. Connector sends incorrect data to external system. Takes days to clean up.

    Solution:
    Always test integrations in Sandbox/Implementation tenant first:

    • Validate data mappings
    • Test error scenarios (what if external system is down?)
    • Perform full end-to-end testing
    • Get user acceptance sign-off before production deployment

    Mistake 5: Hardcoding Credentials in Studio Code

    Problem:
    Developer hardcodes API credentials in Studio Java code. Code is deployed. Later, credentials need to be rotated (security requirement). Requires code change and redeployment.

    Solution:
    Use Integration Attributes to store credentials:

    • Credentials stored securely in Workday (encrypted)
    • Can be updated without code changes
    • Supports different credentials per tenant (sandbox vs. production)

    Integration Monitoring and Troubleshooting

    Monitor Integration Health

    Daily Checks:

    1. Navigate to Integration Event
    2. Filter: Status = Failed or Status = Partially Successful
    3. Review failed integrations:
      • What failed?
      • Why did it fail?
      • Does it need to be re-run?

    Weekly Checks:

    1. Run Integration Status Report (custom report showing all integrations and last successful run)
    2. Identify integrations that haven’t run in expected timeframe
    3. Review integration performance (running slower than expected?)

    Common Integration Errors

    Error 1: Authentication Failure

    Symptom: “Unable to authenticate to external system”

    Causes:

    • Credentials expired or incorrect
    • API key rotated without updating Workday
    • IP whitelisting issue (Workday IP not allowed by external system)

    Resolution:

    • Update credentials in integration configuration
    • Contact external system vendor to verify API access
    • Check firewall/IP whitelist settings

    Error 2: Data Validation Failure

    Symptom: “Record failed validation: Employee ID is required”

    Causes:

    • Missing required fields in source data
    • Data format mismatch (e.g., sending text where number expected)
    • Field length exceeded (e.g., 50 character name in 30 character field)

    Resolution:

    • Review error log to identify failing records
    • Correct source data in Workday
    • Adjust integration mapping if needed
    • Re-run integration

    Error 3: Timeout

    Symptom: “Integration timed out after 30 minutes”

    Causes:

    • Processing too much data in single run
    • External system slow to respond
    • Network latency issues

    Resolution:

    • Implement pagination (process 1000 records at a time)
    • Optimize query filters (reduce data volume)
    • Contact external system vendor about performance
    • Consider splitting into multiple smaller integrations

    Your Integration Decision Cheat Sheet

    ScenarioToolReason
    Monthly benefit election file importEIB InboundSimple file load, no complex logic
    Weekly employee export to ExcelEIB OutboundFile-based extract, basic mapping
    Payroll sync to ADPCore ConnectorPre-built connector exists
    Real-time badge provisioningStudioCustom API, real-time requirement
    Annual data conversion at go-liveEIB InboundOne-time file load
    Time tracking integration to KronosCore ConnectorPre-built connector available
    Custom tax calculation via external APIStudioComplex logic, API integration
    Daily new hire report to ITEIB OutboundSimple scheduled extract

    What You’ve Learned

    You now understand:

    ✅ The three Workday integration tools and what each one does

    ✅ When to use EIB for simple, file-based data exchanges

    ✅ When to use Core Connectors for common third-party system integrations

    ✅ When to use Studio for complex, custom integrations requiring code

    ✅ How to build an EIB integration step-by-step

    ✅ How to configure Core Connectors with proper mappings and credentials

    ✅ Integration best practices for error handling, testing, and monitoring

    ✅ Common mistakes to avoid and how to troubleshoot integration failures

    The difference between a junior and senior Workday integration consultant isn’t knowing how to build integrations, it’s knowing which tool to use when and designing integrations that are maintainable, reliable, and performant.

    Choose the simplest tool that meets your requirements. Don’t over-engineer. And always test before deploying to production.

    Note: This guide represents original content based on Workday integration experience and publicly available Workday documentation. All examples and scenarios are written from practical implementation experience.

  • Workday Financials for Non-Tech Finance

    Opening Workday Financials for the first time can feel like stepping into a new language. You see Company, Entity, Ledger, Worktag, Cost Center and wonder how it all ties back to your familiar trial balance and P&L. The good news: once you understand a few core concepts – entities, ledgers and worktags – Workday becomes a very friendly system for non-technical finance users.​

    This tour explains those building blocks using plain finance language, so you can confidently review journals, approvals and reports without needing to be a Workday expert.

    Entities: who’s doing the accounting?

    In Workday, an Entity (often surfaced as Company or Company/Entity) represents the legal or accounting unit where transactions post and financial statements are produced.​

    As a finance user, think of entities as:

    • The companies or legal entities you already know from your statutory books.
    • The units you produce balance sheets, P&Ls and trial balances for.
    • The basis for intercompany relationships and consolidation.

    Key points:

    • Every financial transaction in Workday – supplier invoice, customer invoice, expense report, journal – belongs to an Entity.​
    • Entities drive things like functional currency, fiscal calendar and consolidation rules.
    • When you see questions like “Which company is this invoice for?” in Workday, that maps to entity selection.

    If you understand which entities exist in your group today, you are already halfway to understanding the Workday structure.

    Ledgers: where transactions land

    The Ledger is the place where accounting entries are recorded and balanced. In Workday, you may see Primary Ledger, Adjustment Ledgers, and specific ledger scenarios for local or management reporting.​

    For non-technical users:

    • The Primary Ledger holds your main accounting entries for each entity.
    • Additional ledgers can be used for adjustments, local GAAP vs group GAAP, or other management views.​

    Day to day, you will see ledgers in:

    • Journals – each journal posts to a specific ledger and period.
    • Reports – you can filter or run P&Ls and balance sheets by ledger if you have multiple.

    You do not need to configure ledgers, but knowing which ledger a report uses helps you interpret if numbers are statutory, management, or adjustment-inclusive.​

    Worktags: Workday’s replacement for long account strings

    The biggest conceptual shift in Workday Financials is Worktags. Instead of long account strings (Company-Department-Account-Project…), Workday attaches multiple Worktags as labels to each transaction.​

    Worktags are:

    • Short labels that describe the “who, what, where, why” of a transaction.
    • Used for routing approvals, posting entries and reporting.​

    Common Worktags include:

    • Cost Center – which department or unit owns the cost.
    • Fund / Program / Grant / Project / Gift – funding or project dimensions (often called Driver Worktags).​
    • Spend Category / Revenue Category – what you are buying or what income you are recognizing (similar to account/object codes).​
    • Location – where the cost or revenue occurs (office, store, plant).
    • Assignee – who the cost is related to (for example, an employee for chargebacks).​

    In practice:

    • Every requisition, invoice, expense report and journal uses Worktags instead of a single long code.​
    • One Driver Worktag (like Project or Cost Center) often auto-populates other Related Worktags, making entry easier and more consistent.​

    As a non-technical finance user, your job is usually to:

    • Check that the Cost Center and Spend/Revenue Category are correct.
    • Confirm the Project/Grant/Program if relevant.
    • Make sure the Worktags match how you want to see the spend in reports.​

    How entities, ledgers and worktags meet in a transaction

    Consider a simple supplier invoice in Workday:

    • You select the Company/Entity – this determines which legal entity is booking the expense.
    • The invoice lines use Worktags such as Cost Center, Spend Category, Project and Location.
    • When the invoice is posted, Workday uses its accounting rules to create ledger entries in the correct Ledger with the right accounts and dimensions.​​

    Behind the scenes:

    • Accounting Rules map Worktag combinations (for example, Entity + Spend Category) to ledger accounts.
    • Worktags determine routing (who approves), reporting (which department sees the cost) and analytics.​

    From your perspective, you can review an invoice and quickly answer:

    • “Is this hitting the right company?” (Entity)
    • “Is it going to the right department or project?” (Cost Center / Project Worktags)
    • “Is the type of spend coded correctly?” (Spend Category)

    Once you are comfortable “reading” a Workday transaction like this, reviews and approvals become much easier.​​

    Worktags in reports: how finance actually uses them

    Worktags are not just data entry fields; they are the backbone of Workday financial reporting.​

    Typical reports you will use:

    • Trial balance and P&L by Worktag – for example, P&L by Cost Center, by Program, by Project.
    • Spend by Worktag – spend by Supplier and Spend Category, or by Project and Cost Center.
    • Budget vs actual – combining Worktags used in budgets and actuals to show variances.​

    Benefits for non-technical users:

    • You can easily slice data without needing custom cubes or extra tools.
    • Approvers can drill from a summary P&L down to individual transactions and see all Worktags on each line.​​
    • Audit and compliance checks are easier because every transaction carries clear labels.​

    If reports do not look right, it is often a Worktag issue (wrong Cost Center or Spend Category) rather than a ledger problem.

    Tips for non-technical finance users to get comfortable fast

    To become fluent in Workday Financials without becoming technical:

    • Learn your standard Worktag sets
      • For example, which Cost Centers you support, common Spend Categories, and key Projects or Grants.
      • Keep a simple cheat sheet for your area.​
    • Practice reading journals and invoices
      • Open a few recent transactions and inspect the Worktags and ledger entries.
      • Verify that they align with how you would have coded them in your old system.​​
    • Use Workday reports and drill-downs
      • Start with delivered or standard reports for trial balance, P&L and spend reports.​​
      • Use drill-down to go from high-level numbers to underlying Worktag detail.
    • Ask where Worktags are auto-populated
      • Many Worktags default from the worker, cost center or project. Understanding these defaults reduces manual corrections.​​

    You do not need to know every configuration detail; you just need to know how Entities, Ledgers and Worktags show up in your day-to-day screens and reports.

    Once those three pieces click, Workday stops feeling like a complex system and starts feeling like a flexible, label-based accounting tool that supports the way finance actually thinks about the business.

  • Building a Talent Engine in Workday

    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.

  • Understanding Workday Organizations Clearly

    One of the most common questions from new Workday users and even some project stakeholders is, “Aren’t all organizations in Workday basically the same?” On the surface, everything looks like “an org” with a name and hierarchy. But once you start configuring security, routing approvals, or building reports, the differences between Workday organization types become critical.

    Thinking of all orgs as interchangeable often leads to messy designs, confusing security, and reports that never quite reconcile. A clearer mental model of Workday organizations helps HR, Finance, and Workday admins design a tenant that is easier to use and maintain.

    What Workday Means by “Organization”

    In Workday, “organization” is a generic term for several different structures that group people, positions, or financial elements in specific ways. Each type of organization exists for a defined purpose: some drive staffing, some drive cost allocation, and others drive reporting or security.

    For example, supervisory organizations represent who manages whom, but cost centers represent where costs are tracked and reported. Both are “orgs” in Workday, yet they answer completely different questions for the business. Treating them as the same quickly causes problems in both configuration and reporting.

    Key Workday Organization Types and Their Roles

    While each tenant has its own configuration, a few core organization types show up in almost every Workday implementation. Understanding the “why” behind each type is more important than memorizing every configuration option.

    • Supervisory organizations focus on management and staffing.
      They answer: “Who manages this worker?” and “Which team does this position belong to?” These orgs shape your supervisory hierarchy and drive staffing models and approvals.
    • Cost centers focus on financial responsibility.
      They answer: “Where should this worker’s costs be tracked?” and “Which department owns this spend?” Cost centers are critical for reporting labor costs and enabling Finance visibility.
    • Company (or legal entities) focus on legal and financial structure.
      They answer: “Which legal entity employs this worker?” and “Which company is responsible for this transaction?” Companies are important for regulatory, tax, and financial reporting.
    • Regions, locations, or custom organizations often focus on grouping for reporting or process routing.
      They answer: “Which geography or business line does this worker belong to?” or “Which group should see this dashboard or approval?”

    Each type has its own configuration screens, reference IDs, and impact areas in Workday. Calling all of these simply “orgs” hides the fact that each one exists for a slightly different reason and is used in different parts of the system.

    Why It Matters to Stop Treating All Orgs as Equal

    When project teams or business users treat all organizations as interchangeable, a few predictable issues appear over time:

    • Confusing security and access.
      Security designed on the wrong org type can give the wrong users access to data, or force admins to maintain endless exceptions.
    • Approvals that don’t match the real world.
      Routing approvals on the wrong structure (e.g., cost center when you really mean manager) leads to frustration and delays.
    • Reports that never align.
      If HR reports use supervisory orgs while Finance reports rely on cost centers, and users don’t understand the difference, data disputes become a regular occurrence.

    Changing how people think about Workday organizations is often the first step to cleaning up an implementation. It is much easier to improve configuration and reporting when everyone shares a common understanding of what each org type represents.

    A Simple Mental Model for Workday Organizations

    To help non-technical stakeholders, it can be useful to translate Workday organizations into everyday language:

    • Supervisory organizations: “Teams and managers.”
    • Cost centers: “Where the money is tracked.”
    • Companies: “Legal employers or entities.”
    • Additional orgs: “Ways we group people for routing or reporting.”

    This simple language reduces jargon and makes it easier for HR and Finance leaders to participate in design decisions. When they understand the purpose behind each org type, they give better input on how approval chains, financial ownership, or reporting structures should be set up.

    Practical Tips for HR, Finance, and Admins

    If you are trying to simplify Workday for your HR and Finance teams, use these principles when talking about organizations:

    • Always name the org type explicitly.
      Instead of saying “update the org,” say “update the supervisory org” or “update the cost center.”
    • Tie each org type to business questions.
      Explain which questions are answered by supervisory orgs and which by cost centers or companies.
    • Use visuals and examples.
      Simple diagrams that show a worker with a manager, cost center, and company help users see that one person can belong to multiple organization structures at once.
    • Align training and documentation.
      Ensure your guides and training materials consistently use the same terminology and explanations; this builds confidence in your users.

    Bringing It Back to Simplifying Workday

    At its core, Workday is powerful because it lets you slice and group your workforce in many different ways. That power becomes complexity when everyone calls everything “an org” and stops distinguishing the purpose of each structure.

    By teaching your HR and Finance teams the differences between Workday organization types, you reduce confusion and empower them to make smarter decisions about configuration, reporting, and workflows. The goal is not to turn everyone into an architect, but to give them enough understanding to use Workday with clarity and confidence.

  • Discovery Boards That Executives Actually Use

    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.

    Discovery Board 1: Executive Headcount Dashboard (CHRO/CFO)

    Primary Purpose: Answer “Where is our headcount versus budget?”

    Sheet 1: Headcount at a Glance

    Metric 1: Total Headcount

    • Visualization: KPI card​
    • Shows: Current headcount with trend indicator (up/down from last month)
    • Data source: Workers (Active Status equals Active)

    Metric 2: Open Positions

    • Visualization: KPI card
    • Shows: Count of vacant positions with availability equals available
    • Data source: Positions (if Position Management enabled) or Requisitions

    Metric 3: Headcount vs Budget

    • Visualization: KPI card showing variance
    • Shows: Current headcount minus budgeted headcount, percentage variance
    • Data source: Workers + Budget data (may require Prism if budget in external system)

    Metric 4: Headcount by Department

    • Visualization: Horizontal bar chart​
    • Shows: Top 10 departments by headcount
    • Interactivity: Click to drill into department details

    Metric 5: Hiring Pipeline

    • Visualization: Waterfall chart​
    • Shows: Requisitions by status (Approved, Interviewing, Offer Extended, etc.)
    • Data source: Requisitions

    Sheet 2: Problem Areas

    Metric 6: Positions Open Over 90 Days

    • Visualization: Table
    • Shows: Position ID, Title, Department, Days Open, Recruiter
    • Data source: Positions or Requisitions with date filter

    Metric 7: Departments Over Budget

    • Visualization: Horizontal bar chart showing variance percentage
    • Shows: Departments where actual headcount exceeds budget by more than 10%

    Usage pattern: CHRO checks Sheet 1 every Monday morning before leadership meeting. CFO checks Metric 3 (Headcount vs Budget) daily during month-end close.

    Key success factor: Budget data integration. If budget lives in external system, use Prism to bring it into Workday for comparison.​

    Discovery Board 2: Turnover Analysis Dashboard (CHRO/HR Operations)

    Primary Purpose: Answer “Where are we losing people and why?”

    Sheet 1: Turnover at a Glance

    Metric 1: Monthly Turnover Rate

    • Visualization: KPI card
    • Shows: Turnover percentage for current month with comparison to previous month
    • Calculation: (Terminations this month ÷ Average headcount this month) × 100

    Metric 2: Voluntary vs Involuntary Turnover

    • Visualization: Two KPI cards side by side
    • Shows: Voluntary turnover rate and involuntary turnover rate separately
    • Critical distinction: Executives care more about voluntary turnover

    Metric 3: Turnover Trend

    • Visualization: Line chart​
    • Shows: Monthly turnover rate over last 12 months
    • Helps answer: Are we improving or declining?

    Metric 4: Turnover by Department

    • Visualization: Horizontal bar chart
    • Shows: Top 5 departments by turnover rate (not count, rate matters)
    • Sorted: Highest to lowest

    Metric 5: Turnover by Tenure

    • Visualization: Bar chart
    • Shows: Turnover distribution by tenure bands (0-6 months, 6-12 months, 1-2 years, 2-5 years, 5+ years)
    • Insight: High turnover in 0-6 months indicates onboarding problems

    Sheet 2: Termination Details

    Metric 6: Recent Terminations

    • Visualization: Table
    • Shows: Worker Name, Job, Department, Termination Date, Termination Reason, Manager
    • Filter: Last 30 days
    • Purpose: Drill-down for executives who want specifics

    Usage pattern: CHRO checks Sheet 1 weekly. HR Ops uses Sheet 2 daily for exit interview preparation.

    Key success factor: Accurate termination reason coding. If termination reasons are inconsistent or generic, the dashboard provides no actionable insight.

    Discovery Board 3: Recruiting Efficiency Dashboard (CHRO/VP Talent Acquisition)

    Primary Purpose: Answer “How effective is our recruiting process?”

    Sheet 1: Recruiting Efficiency

    Metric 1: Average Days to Fill

    • Visualization: KPI card
    • Shows: Average days from requisition approval to hire date, with trend indicator
    • Data source: Requisitions (Status equals Filled, effective date filter for recent hires)

    Metric 2: Open Requisitions

    • Visualization: KPI card
    • Shows: Count of requisitions with status equals Open
    • Context: Shows recruiting workload

    Metric 3: Hiring Pipeline by Stage

    • Visualization: Waterfall chart or horizontal bar chart​
    • Shows: Count of candidates by recruiting stage (Sourcing, Screening, Interviewing, Offer, etc.)
    • Insight: Identifies bottlenecks in recruiting process

    Metric 4: Requisitions by Age

    • Visualization: Bar chart
    • Shows: Count of open requisitions by age bands (0-30 days, 31-60 days, 61-90 days, 90+ days)
    • Insight: Identifies aging requisitions needing attention

    Metric 5: Time to Fill by Department

    • Visualization: Horizontal bar chart
    • Shows: Average days to fill by department
    • Sorted: Longest to shortest
    • Insight: Identifies departments with recruiting challenges

    Sheet 2: Problem Requisitions

    Metric 6: Requisitions Open Over 90 Days

    • Visualization: Table
    • Shows: Requisition ID, Job, Department, Hiring Manager, Days Open, Recruiter, Candidate Count
    • Purpose: Action list for recruiting leadership

    Usage pattern: VP Talent Acquisition checks Sheet 1 every Monday morning. Recruiting Ops uses Sheet 2 to prioritize aging requisitions.

    Key success factor: Accurate requisition status updates. If recruiters do not update candidate stages promptly, pipeline metrics are meaningless.

    Discovery Board 4: Compensation Analysis Dashboard (CHRO/CFO/Compensation Manager)

    Primary Purpose: Answer “Are we paying competitively and within budget?”

    Sheet 1: Compensation Overview

    Metric 1: Total Compensation Spend

    • Visualization: KPI card
    • Shows: Total annual compensation (base salary + bonuses) with budget comparison
    • Data source: Workers with current compensation

    Metric 2: Average Base Salary

    • Visualization: KPI card
    • Shows: Average base salary across organization with year-over-year comparison
    • Context: Helps track compensation inflation

    Metric 3: Compensation by Department

    • Visualization: Horizontal bar chart
    • Shows: Average compensation by department
    • Insight: Identifies compensation disparities across organization

    Metric 4: Compa-Ratio Distribution

    • Visualization: Bar chart or histogram
    • Shows: Count of workers by compa-ratio bands (Below 0.85, 0.85-0.95, 0.95-1.05, 1.05-1.15, Above 1.15)
    • Insight: Identifies workers paid below or above market range

    Metric 5: Compensation Spend vs Budget

    • Visualization: Waterfall chart showing variance​
    • Shows: Budgeted compensation, actual compensation, variance by category (base, bonus, equity)

    Sheet 2: Compensation Outliers

    Metric 6: Workers Below Market (Compa-Ratio Below 0.85)

    • Visualization: Table
    • Shows: Worker Name, Job, Department, Base Salary, Market Midpoint, Compa-Ratio
    • Purpose: Identifies retention risks

    Metric 7: Workers Above Market (Compa-Ratio Above 1.15)

    • Visualization: Table
    • Shows: Worker Name, Job, Department, Base Salary, Market Midpoint, Compa-Ratio
    • Purpose: Identifies budget optimization opportunities

    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.

    Discovery Board 5: Diversity & Inclusion Dashboard (CHRO/Chief Diversity Officer)

    Primary Purpose: Answer “How is our diversity representation changing?”

    Sheet 1: Diversity Overview

    Metric 1: Overall Diversity Representation

    • Visualization: KPI card showing percentage
    • Shows: Percentage of workforce from underrepresented groups with trend indicator
    • Definition: Clearly define what “underrepresented” means for your organization

    Metric 2: Diversity Trend

    • Visualization: Line chart​
    • Shows: Diversity representation percentage over last 24 months
    • Insight: Are we improving or declining?

    Metric 3: Diversity by Department

    • Visualization: Horizontal bar chart
    • Shows: Diversity representation percentage by department
    • Sorted: Lowest to highest (highlights departments needing attention)

    Metric 4: Diversity by Job Level

    • Visualization: Bar chart
    • Shows: Diversity representation by job level (Individual Contributor, Manager, Director, VP, Executive)
    • Insight: Pipeline representation at leadership levels

    Metric 5: Hiring Diversity

    • Visualization: KPI card
    • Shows: Percentage of new hires from underrepresented groups in last 90 days
    • Context: Leading indicator of future representation

    Sheet 2: Diversity Deep Dive

    Metric 6: Pay Equity Analysis

    • Visualization: Scatter plot​
    • Shows: Compensation by gender/ethnicity within same job profile
    • Purpose: Identify potential pay equity issues
    • Note: Use Workday’s delivered Pay Equity Discovery Board template as starting point​

    Usage pattern: Chief Diversity Officer checks Sheet 1 monthly for board reporting. CHRO checks Metric 5 (Hiring Diversity) monthly to validate recruiting effectiveness.

    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:

    1. Click your profile menu
    2. Select Drive
    3. Click Add New
    4. Select Discovery Board​

    Build Sheet 1:

    1. Name the sheet clearly: “Headcount at a Glance” (not “Sheet 1”)
    2. Add your first visualization (drag data source, choose viz type)
    3. Configure the visualization to answer Question 1 specifically
    4. Repeat for visualizations 2-5
    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:

    1. Click Share button​
    2. Add executive as viewer (not editor unless they need to modify)
    3. Consider sharing with security group if multiple executives need access
    4. 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.

  • Why Your Workday Numbers Look “Wrong”

    When Stakeholders Don’t Trust Your Workday Reports

    If you spend time in Workday reporting, you’ve probably heard some version of:

    • “This doesn’t match our spreadsheet.”
    • “Finance is showing a different total.”
    • “Can you just export it? We’ll fix it in Excel.”

    It’s easy to blame Workday when numbers don’t line up. But across different tenants, the same issues appear again and again—and they’re almost always about report design, not platform capability.​

    If your HR and Finance stakeholders regularly say the numbers “look wrong,” chances are you’re hitting one or more of these traps.

    1. You Picked the Wrong Data Source

    If the data source is wrong, everything built on top of it will be wrong too.

    Common patterns:

    • Using a data source that only includes active employees when you actually need to see all workers, including terminated or contingent workers.
    • Mixing HR and Finance data sources with different grain (for example, worker-level vs transaction-level) and then trying to reconcile totals between them.
    • Starting from a niche data source when a broader, delivered one would have been safer.​

    No amount of filters or calculated fields can fix a fundamentally mismatched source. Before building anything complex, confirm:

    • Does this source include the population you care about?
    • At what level does it store data (worker, position, event, line item)?
    • Is this the same lineage you’re comparing against elsewhere?

    If the answer is no, start over with the right source rather than patching around the wrong one.

    2. Your Filters and Prompts Are Fighting You

    Even with the right data source, filters and prompts can quietly sabotage your results.

    Typical issues:

    • Filters are applied on the wrong object; for example, filtering at a related level instead of on the primary business object.
    • Date or Effective Date isn’t prompted, so different users unknowingly compare different time windows.
    • Hidden or default filters (“Do Not Prompt at Runtime”) override what users think they’ve selected.​

    That one checkbox—whether something is prompted or not—can completely change what appears on the report.

    To debug:

    • Temporarily expose all key filters as prompts and run tests with very broad settings.
    • Check whether any underlying default filters are still restricting data, even when prompts seem open.
    • Verify that org, date, and status filters are applied where you actually expect them.

    Until filters and prompts are aligned with the intended question, stakeholders will keep seeing inconsistent results.

    3. Your Calculated Fields Are Double-Counting

    Calculated fields are powerful, but they’re also an easy way to inflate or distort totals.

    Common traps:

    • Aggregating at the wrong level when workers have multiple rows (for example, multiple positions, events, or dependents).
    • Building complex calculated fields, then reusing them everywhere without validating the logic in isolation.
    • Summing values in a matrix or pivot that already reflect aggregated or overlapping data.​

    If your math is built on noisy grain, your totals will always look suspicious.

    Safer patterns:

    • Start with a small debug report using just the fields and groups relevant to the calculation.
    • Confirm row-level behaviour: are you counting workers, events, assignments, or something else?
    • Only then roll the calculated field into your “official” reports and dashboards.

    Once you understand the grain, your numbers become much easier to defend.

    4. You’re Misusing Composite Reports

    Composite Reports have a reputation as “advanced mode,” so many teams reach for them too early.

    In reality, Composite is a specialised tool for:

    • Combining multiple report results or data sets into one “one-stop” output.
    • Handling multi-source, multi-period or multi-view scenarios that truly cannot be expressed in a single advanced report.​

    When you use Composite as your default for anything complex, you usually add:

    • More joins and relationships than you really need.
    • More prompts and filters to coordinate.
    • More performance issues and more places where numbers can drift.​

    If a single Advanced report (possibly surfaced on a dashboard) can answer the question, start there. Treat Composite as the last resort for genuinely complex needs—not as a badge of seniority.

    5. Security Is Silently Hiding Rows

    One of the most underestimated causes of “wrong” totals is security.

    Scenario:

    • An admin runs a report and sees 1,254 workers.
    • A manager runs the same report, with seemingly identical prompts, and sees 1,037.
    • Both assume the other view is wrong.

    In fact, both views might be correct—for their security.

    Because Workday enforces security at the data level, reports will naturally show different populations based on:

    • Supervisory org visibility.
    • Role-based access and domain security.
    • Field-level security and constrained data sources.​

    If you only test reports as an admin, you will miss how they behave for real users.

    Always:

    • Test key reports as different roles (HR Partner, HRBP, Manager, Finance, etc.).
    • Clearly communicate which roles a report is designed for.
    • Document whether a report is meant to be tenant-wide, region-specific, or org-specific.

    If you don’t account for security, you’ll spend hours chasing “wrong” numbers that are actually right for that user.

    A Simple Playbook to Fix “Wrong” Numbers

    When stakeholders don’t trust your reports, you don’t need a brand-new reporting strategy. You need a disciplined way to design and debug.

    Here’s a practical playbook.

    Start with the question, not the tool

    • Ask, “What decision will this report support?” before building anything.
    • Choose the simplest data source and an Advanced report that can answer that specific decision-making need.​

    Strip the report back to basics

    • Remove non-essential filters, columns, and calculated fields.
    • Run the report with broad prompts (wide date ranges, minimal org restrictions).
    • Prove that the base data set is correct first; only then add complexity.

    Test your prompts deliberately

    • Check that prompts are bound to the right underlying fields.
    • Make sure critical prompts—dates, orgs, populations—are present and, where appropriate, mandatory.
    • Look for “hidden” filters or defaults that override the user’s choices at runtime.​

    Debug calculated fields in isolation

    • Build a tiny “debug” report that exists solely to test calculated fields and groupings.
    • Compare its totals against a trusted reference (manual count, legacy report, or a smaller population).
    • Only plug complex calcs into production reports when they match reality in isolation.

    Apply this playbook consistently and two things will happen:

    1. Stakeholders will stop opening every report conversation with “These numbers look wrong.”
    2. You will become the person leaders rely on when they need numbers they can make decisions with.

    And in Workday reporting, that trust is the most valuable metric you can own.

  • Project Accounting in Workday, Step by Step

    Project Accounting

    Project accounting in Workday is not just a “Finance feature.” It is the thread that connects Projects, Worktags, Time Tracking, Expenses, Procurement and Billing into a single picture of project cost, margin and progress. When you design it intentionally, you can see exactly what each project costs, what to invoice, and how profitable it is—without extracting everything to spreadsheets.​​

    This guide walks step by step from project setup to employee expenses, using Workday terminology throughout.

    Step 1: Design your project Worktag model

    In Workday, Project itself is a Worktag, usually a Driver Worktag. When added to a transaction line, it can auto-populate related Worktags such as Cost Center, Program, or Grant via Related Worktags.​​

    Decisions to make up front:

    • What types of projects will you track?
      • Customer / billable projects (client work, external funding).
      • Internal / administrative projects (internal initiatives, overhead).
      • Capital projects (fixed asset construction, IT implementations).​
    • Which Worktags should be tied to Project?
      • Cost Center, Program, Fund/Grant, Region, maybe a Custom Worktag for Portfolio or Product Line.​​

    Design patterns:

    • Use a clear naming convention for Projects: prefix by project type or business line (e.g., “CUST‑1001 – Client A ERP”, “CAP‑2003 – HQ Renovation”).​
    • Configure Project Allowed Worktags so only valid Worktag combinations can be used with each Project (for example, only certain Cost Centers or Funds).​
    • Build project hierarchies where you need rollups (programs or portfolios) using Project Hierarchies and related structures.​

    A good Worktag design means you do not have to teach users every rule; Workday enforces a lot of it for you.

    Step 2: Create projects with the right attributes

    The Create Project process in Workday captures core data and determines how the project behaves in financials, expenses and billing.​​

    Key fields and decisions:

    • Project Type – Administrative, Customer, Capital, etc. This drives downstream behavior, including capitalization and billing options.​
    • Owning Company / Entity – which legal entity owns the project and will recognize revenue/cost.​​
    • Worktags – Cost Center, Program, Customer (for customer projects), Location, and any Custom Worktags.​​
    • Billable vs Non‑billable – indicates whether costs should be available for billing and margin analysis.​​
    • Project Plan / Tasks – optional but powerful: break the project into tasks or work packages to track cost and progress at a more detailed level.​​

    Best practices:

    • Use template projects for common patterns (for example, standard professional services engagements) to default Worktags, billing settings and tasks.​​
    • Capture Customer and Contract/Billing references at project setup for billable projects to avoid reconciling later.​
    • For capital projects, confirm how costs will later link to Assets and Capitalization processes.​

    Once created, the Project becomes the central Worktag used across time, expenses, procurement and journals.

    Step 3: Capture time and expenses against projects

    To see true project cost, you must push Time Tracking and Expenses through the project lens. Workday Projects ties into both modules.​​

    Time:

    • Configure Time Entry Templates and Time Entry Codes so workers can select a Project (and optionally Task) on their time entries.​​
    • Use Work Type Rules to classify time (e.g., billable vs non‑billable, standard vs overtime) for project cost and revenue.​​
    • Make sure time approvals align with project responsibility—line managers or project managers, depending on your operating model.​​

    Expenses:

    • Enable Project as a Worktag on Expense Reports so employees can charge travel, materials and other charges directly to projects.​
    • Configure Expense Item defaults to automatically set Spend Categories and some Worktags, leaving employees to choose only Project (and maybe a Task).​​
    • Set up expense approval hierarchies that route project‑coded expenses to the right project or cost center owner.​

    By getting time and expenses to consistently carry the Project Worktag, you build a clean cost view without manual allocation journals later.

    Step 4: Capture procurement and AP costs to projects

    Project costs often come through procurement: purchase orders, supplier invoices and sometimes journals. Workday enables project tagging across these flows.​

    Patterns:

    • On Purchase Requisitions and Purchase Orders, include Project and related Worktags on lines that are project-specific.​
    • For Supplier Invoices, either inherit the Project from the PO or allow AP to add Project Worktags directly on invoice lines where appropriate.​
    • Use Project Allowed Worktags rules to prevent invalid combinations (e.g., wrong Cost Center or Fund for that project).​

    Capital projects:

    • Ensure procurement and AP spend for capital projects are coded to the capital project and appropriate Spend Categories (e.g., Capitalizable construction or equipment categories).​
    • Later, Workday can help create Project Assets and move costs from Construction-in-Progress (CIP) to fixed assets.​

    This approach keeps all project-related spend, not just internal time and expenses, visible at project level.

    Step 5: Budgeting and tracking against plan

    Project accounting becomes truly useful when you compare actuals to budget or plan.​

    Options:

    • Use Project Budgets:
      • Create project-level budgets with the Project Worktag plus other dimensions like Cost Center and Spend Category.​
      • Submit for approval and tie them into your broader financial planning process.
    • Use Resource / Project Plans:
      • For services projects, build resource plans to estimate effort and cost by role or worker.​​

    Reporting:

    • Build reports and dashboards showing Budget vs Actual by Project, by Task, and by Worktag (e.g., by Spend Category, Cost Center, Customer).​
    • Include both labor (time, payroll allocations) and non‑labor (supplier, expenses) costs for a full project cost picture.​

    Good practice is to define who owns the project budget (Project Manager, PMO, Finance) and how often you review project financials—monthly is common for active projects.

    Step 6: Billing and revenue for customer projects

    For customer projects, project accounting feeds directly into Workday Project Billing and revenue.​​

    Key elements:

    • Billing Plans: define how and when you bill (time & materials, fixed fee, milestones, retainers).​
    • Billing Events and Invoice Generation: Workday converts billable project transactions into customer invoices according to your billing plan and rules.​​
    • Revenue Recognition: revenue schedules and rules determine when revenue is recognized for project work, potentially decoupled from billing.​

    Make sure:

    • Only appropriately tagged billable time and expenses hit billing, based on Work Types or billable flags.​​
    • Contracts, Projects and Customers are linked correctly so invoices automatically reflect the right project, PO, and tax settings.​

    This ensures your project accounting supports both cost control and the top line.

    Step 7: Governance and “project hygiene”

    Project accounting can decay over time if governance is missing. Keep it healthy with:

    • Project lifecycle rules
      • Clear criteria for moving projects from Open → Active → Closed.
      • Regular reviews to close dormant or completed projects to prevent miscoding.​
    • Worktag hygiene
      • Regular checks for transactions posted to “wrong” or generic projects requiring reclass.
      • Use reports to identify expenses and invoices without Projects where they should have one.​
    • Training and quick references
      • Provide Project and Worktag cheat sheets per business area (which Projects to use, which are closed, etc.).​
      • Train project managers to use Workday reports and dashboards, not offline trackers, for financial views.​

    Treat project accounting as a shared responsibility between Finance, PMO and delivery teams.

    When you design project accounting in Workday as an integrated process—from Project setup to Time & Expense capture, Procurement, Budgeting and Billing. You end up with a living, accurate view of project performance. Finance gets clean numbers, project managers get real insight, and leadership can see where work is truly profitable.