Tag: workday org design

  • The Hidden Workday Org Design Problem

    Most Workday Problems Start in the Org Chart

    When something breaks in Workday, blame usually lands on:

    • Security roles
    • Business process steps
    • “Workday being complicated”

    But in many tenants, those symptoms trace back to a deeper source: the Supervisory Organization model.

    Supervisory Orgs define who reports to whom, how staffing is structured, and how many downstream behaviours—approvals, security, reporting—play out.​
    If the org design is messy, everything built on top of it has to work harder.

    One of the most common—and least discussed—design mistakes is how managers are assigned Supervisory Orgs.


    The Misconception: “Multiple Orgs per Manager Is Normal”

    A pattern shows up repeatedly:

    “This manager has multiple areas, so let’s give them multiple Supervisory Orgs.”

    It sounds logical. On paper, it seems to reflect reality: they lead multiple teams, cost centres, or functions, so each gets its own Supervisory Org.

    In practice, overusing this approach creates chaos:

    • The same manager appears as the superior in several Supervisory Orgs by default.
    • Business processes must handle multiple org contexts for the same person.
    • Security and reporting become harder to reason about.​

    Multiple Supervisory Orgs per manager should be the exception, not the standard pattern.


    When Multiple Supervisory Orgs Make Sense

    There are legitimate, defensible reasons to give a single manager more than one Supervisory Org. For example:

    • Different staffing models under the same leader, such as one area using position management and another using job management.
    • Workers spread across countries or companies where legal or regulatory routing needs distinct org structures.
    • Sensitive teams that require isolated security, such as investigations, HR, or special projects.
    • Temporary legacy structures during a merger, acquisition, or phased reorganisation.​

    In these cases, the complexity buys you something concrete: compliance, clear separation, or a safer transition path.

    Outside of scenarios like these, duplicating Supervisory Orgs for the same manager tends to create more problems than it solves.


    How Extra Supervisory Orgs Increase Complexity Everywhere

    Each additional Supervisory Org under the same manager doesn’t just add one more box on the org chart. It adds:

    • More business process variations
      Steps, conditions, and routing logic often need to be adjusted per org. That multiplies design and testing effort.
    • More approval routing surprises
      Approvals based on org can behave differently across orgs that share a manager, leading to “Why did this transaction route differently this time?” questions.
    • More org-based security overhead
      Security groups tied to orgs have to be maintained for each extra Supervisory Org, and granting or revoking access becomes more error-prone.
    • More rework during restructures
      When teams move, you must adjust multiple orgs, security mappings, and business processes instead of a single structure.
    • More confusion in spans of control and headcount
      Managers may appear to have overlapping teams in different orgs, making reporting and analytics harder to interpret.

    This complexity compounds quickly as your organisation grows. A few “extra” Supervisory Orgs now can become dozens of additional touchpoints to manage later.


    A Better Default: One Manager, One Supervisory Org

    Top Workday consulting practices often follow a simple rule of thumb:

    One manager → one primary Supervisory Org.

    This default keeps the core structure clean:

    • The manager’s team is clearly represented in one place.
    • Approval routing and business processes can be designed around a single “home” org.
    • Span-of-control reporting and headcount views are easier to interpret and maintain.​

    When complexity exists in reality—and it always will—Workday has other tools to handle it without multiplying Supervisory Orgs.


    Use the Right Tools for Complexity Instead

    Instead of creating extra Supervisory Orgs for every nuance, lean on other Workday components designed for those needs:

    • Matrix Organizations
      Use these for dotted-line reporting, project teams, or cross-functional responsibilities. They let you model secondary relationships without changing the primary Supervisory Org.​
    • Custom Organizations
      Group workers by function, programs, segments, or other attributes that cut across the hierarchy. This is ideal for analytics and eligibility without changing reporting lines.
    • Position attributes
      Location, cost center, company, and similar attributes can drive eligibility, security, and reporting without needing separate Supervisory Orgs for every combination.​
    • Org Studio (and similar tools)
      Use Workday’s reorganisation tools to plan and execute structural changes in a controlled way, instead of layering new orgs on top of old ones indefinitely.​

    These tools handle real-world complexity while keeping the Supervisory Org model as simple and clean as possible.


    The Real Payoff of a Clean Supervisory Org Model

    A streamlined Supervisory Org design does more than produce a pretty org chart. It has tangible operational benefits:

    • Fewer HR defects
      Transactions follow predictable routing and encounter fewer confusing exceptions.
    • Faster approvals
      Approval chains are easier to design and maintain when they don’t depend on a patchwork of overlapping Supervisory Orgs.
    • More stable security
      Role assignments and org-based access are simpler to manage and test.
    • Scalable growth
      As the organisation grows, adding new teams or leaders doesn’t require untangling a complex web of orgs.

    If your tenant feels noisy too many approval surprises, too many “cannot see worker” issues, too many custom variations your Supervisory Org design is one of the first places to investigate.

    The magic is rarely in adding more structure. It’s in removing the structures you never needed in the first place.

  • Designing Your Workday HCM Foundation

    Designing Your Workday HCM Foundation

    Designing your Workday HCM foundation is one of the most important decisions you will ever make in a tenant. Once you go live with supervisory orgs, positions, job profiles and cost centers, reversing bad design is painful, political and expensive. A clean foundation, on the other hand, makes every downstream process easier: hiring, transfers, security, reporting, integrations and even future modules like Time Tracking or Learning.​

    Start with a clear operating model

    Before touching configuration, clarify how the business actually operates. In Workday terms, this means understanding who manages whom, how cost is tracked, how HR wants to report headcount and how finance wants to see labor cost. You will use those answers to decide the shape of supervisory orgs, whether you go position or job management, and which worktags (like cost centers) become mandatory.​

    Workday supervisory organizations represent management relationships and operational structure, not legal entities. Companies and entities represent legal and accounting structure, while cost centers and other worktags represent how cost is tracked and reported. Separating these concepts early prevents you from overloading supervisory orgs with finance responsibilities they were never designed to carry.​

    Designing supervisory orgs that do not collapse

    A common mistake is to copy the HR org chart directly into Workday as dozens or hundreds of tiny supervisory orgs. That usually creates reporting complexity, security noise and constant maintenance whenever someone changes manager. A better pattern is to design supervisory orgs around stable management units: departments, teams or business units that change less frequently than individual manager assignments.​

    When designing supervisory orgs, ask:

    • Can this org survive manager changes without needing to be restructured every week?
    • Does this level of granularity help reporting and security, or just create clutter?
    • Is there a clear business purpose for this org beyond “we have a manager”?

    Aim for a hierarchy that can support real-world approvals, headcount reporting and security boundaries, but is still simple enough that new HRIS analysts can navigate it confidently.

    Positions vs jobs: choose consciously

    Workday supports position management and job management, and the choice is foundational. Position management is best when you need rigorous headcount control, budget-to-position matching and clear tracking of vacancies. Job management is lighter and works well in fluid environments where individual seats are less important than overall staffing levels.​

    For position management, design patterns include:

    • Use positions anywhere headcount is tightly controlled, such as regulated functions or centralized operations.
    • Give positions meaningful, consistent titles that align with job profiles and not personal names.
    • Avoid creating “temporary” positions for one-off cases; these often become long-term clutter.

    For job management, ensure you still have clear job profiles with compensation grades and worktags so that reporting and security do not depend on free-text job titles.​

    Job profiles as your talent backbone

    Job profiles are the backbone of how Workday sees roles, qualifications, compensation and, in some tenants, learning and talent. Poorly designed job profiles lead to reporting chaos: dozens of variations for the same role, unclear grade mappings and confusing job histories for workers.​

    Strong job profile design usually includes:

    • A consistent naming pattern (e.g., “Analyst, HR Operations” instead of many variations).
    • Clear classification into job families and job profiles that align with how HR and talent teams think about roles.
    • Linkage to compensation grades and grade profiles so that pay ranges are consistent across markets.

    When job profiles are clean, you can deploy performance, learning and career frameworks more easily, because everything hangs off a small number of well-maintained roles rather than hundreds of one-off titles.​

    Cost centers and worktags: think like finance

    Cost centers and other worktags are how finance sees the world in Workday Financials, and even in HCM-only tenants they drive a lot of reporting. HR often underestimates how important it is to design cost centers that match finance’s management reporting rather than HR’s internal labels.​

    Good practices include:

    • Keep cost centers relatively stable and align them to budget owners or P&L responsibility.
    • Avoid duplicating cost centers just to represent small team differences; use supervisory orgs, locations or custom organizations for that.
    • Ensure default cost centers are set correctly at the position, worker or org level so payroll and financial postings are accurate without manual fixes.

    When cost centers and worktags are clean, you can produce reliable reports like headcount by cost center, labor cost by business unit and budget versus actual staff cost with minimal reconciliation.​

    Putting it all together in real processes

    The real test of your HCM foundation is not whether it looks neat in the configuration pages, but whether everyday processes run smoothly. When HR creates a new position, it should be obvious which supervisory org to use, which job profile to select and which cost center should default. When a manager initiates a transfer, the path through supervisory orgs and cost centers should be clear, and reporting should show the move without gaps or duplicates.​

    Think through core processes end to end:

    • Hire to retire: are orgs, positions and cost centers stable across promotions, transfers and international moves?​
    • Security: can you grant HR partners and managers access based on supervisory orgs and cost centers without dozens of exceptions?​
    • Reporting: can HR and finance quickly answer questions about headcount, vacancies and cost without manual spreadsheets?​

    When these scenarios work, you know the foundation is serving the business rather than the other way around.

    Design for the next three years, not three months

    Finally, design your Workday HCM foundation with a three-year horizon. Most organizations will go through reorganizations, new business lines and possibly new geographies in that time. Build supervisory org structures, position rules, job profiles and cost center hierarchies that can absorb that change without needing a full rebuild.​

    Document your design principles and decisions, not just your configuration. Future HRIS analysts, Workday consultants and auditors should be able to understand why the tenant looks the way it does. That documentation is part of the foundation, just as much as the orgs and positions themselves.​

    A strong Workday HCM foundation does not happen by accident. It is the result of deliberate choices about how to represent your organization, control headcount, classify roles and track cost. When you get those basics right, everything from security to payroll to analytics becomes simpler, more reliable and much easier to scale.

  • Fixing Broken Org Structures in Workday

    Broken org structures in Workday are one of the most painful problems to fix because they touch everything: security, reporting, business processes, time tracking and approvals. When supervisory orgs are too granular, too flat or misaligned with how the business actually runs, every downstream process becomes harder. The good news: Workday provides flexible tools—Supervisory OrganizationsMatrix Organizations and Custom Organization Hierarchies—to model complex structures. The challenge is using them intentionally, not accidentally.​

    This guide walks through practical patterns for designing, fixing and maintaining org structures that work.

    Understand the three org types in Workday

    Workday supports three main organization constructs, each with different purposes:​

    • Supervisory Organizations (Sup Orgs)
      • The foundational org structure representing direct manager-employee relationships.​
      • Drives security (manager self-service roles), business processes (approvals, hires), and primary reporting lines.​
    • Matrix Organizations
      • Freestanding orgs that capture secondary reporting relationships (dotted-line managers, project leads, functional heads).​
      • Enable workers to have multiple managers with different responsibilities (for example, functional manager + project manager).​
    • Custom Organization Hierarchies
      • Flexible groupings for analytics, cost roll-ups or special views (for example, geographic regions, product lines, client portfolios).​
      • Used primarily for reporting and cost allocation, not transactional security or approvals.​

    The key is to use Supervisory Orgs for primary hierarchy and transactionsMatrix Orgs for secondary relationships, and Custom Hierarchies for analytics—not mixing them up.​

    Common supervisory org design mistakes (and how to fix them)

    Many tenants struggle with supervisory org design because they either overcomplicate it or oversimplify it.​

    Pitfall 1: Too many layers and micro-orgs

    • Creating a supervisory org for every team, product or project leads to hundreds of orgs with minimal membership.​
    • Impact: Security role assignment becomes unmanageable, reporting is cluttered, and reorgs are painful.
    • Fix: Use a 1:1 manager-to-sup-org model where each direct people manager has one supervisory org containing their direct reports. Keep it simple and aligned with actual management lines.​

    Pitfall 2: Too flat or generic

    • Creating one giant supervisory org (for example, “All Employees”) or only two levels (CEO → everyone).​
    • Impact: Managers cannot see their teams in self-service, approvals do not route correctly, and security becomes all-or-nothing.​
    • Fix: Build a clear hierarchy reflecting actual management structure (for example, CEO → VPs → Directors → Managers → Individual Contributors).​

    Pitfall 3: Mixing positions and jobs inconsistently

    • Using Position Management in some orgs and Job Management in others without a clear strategy.​
    • Impact: Hiring, budgeting and position control become confusing and inconsistent.
    • Fix: Pick one staffing model per business unit or tenant and document the reasoning; avoid mixing unless there is a compelling business case.​

    Pitfall 4: Not using reorganization events

    • Making ad-hoc changes to supervisory orgs without coordinated reorg events.​
    • Impact: Reporting breaks, analytics show jumbled histories, and downstream systems receive inconsistent data.
    • Fix: Use Workday’s Reorganize Supervisory Organization event to group all related changes (manager moves, org merges, renaming) with a single effective date.​

    Fixing these issues often requires a supervisory org redesign project: map current state, design future state with stakeholders, then execute the reorg in a controlled way.​

    When and how to use matrix organizations

    Matrix orgs solve the “I have two bosses” problem without forcing Workday into unnatural supervisory structures.​

    Good use cases:

    • Employees with a functional manager (for example, Engineering Manager) and a project manager (for example, Product X Lead).​
    • Sales or consulting roles reporting to a geographic leader and a practice/industry leader.​
    • Professional services where consultants report to a home office manager but work for multiple client engagement managers.

    How to design matrix orgs effectively:

    • Keep the primary reporting line in supervisory orgs for security, approvals and compensation processes.​
    • Use matrix orgs for secondary relationships that need visibility (dashboards, talent reviews, project reporting) but do not drive transactional workflows.​
    • Assign matrix managers appropriate security so they can see their matrix members’ data (performance, goals, compensation if needed) without conflicting with primary manager permissions.​
    • Use custom org hierarchies to roll up matrix orgs if you need aggregated views (for example, all Project X members across functional areas).​

    Matrix orgs are powerful but can become confusing if overused; reserve them for genuine dual-reporting scenarios, not every dotted-line relationship.​

    Custom organization hierarchies: the analytics layer

    Custom orgs are the most flexible: you define the grouping logic, membership and hierarchy to support specific business needs.​

    Common patterns:

    • Geographic or regional rollups
      • Group workers by country, region or market for talent analytics and cost reporting.​
    • Product, client or business line hierarchies
      • Track workers aligned to product lines, client accounts or business segments for revenue and utilization reporting.​
    • Functional or capability views
      • Group by function (Sales, Engineering, Finance) even if supervisory structure is organized differently (for example, by region).​

    Best practices:

    • Use custom orgs for reporting and analytics only, not for transactional security or business process routing.​
    • Keep custom org hierarchies aligned with actual business structures so they remain relevant and trusted.​
    • Document the purpose and maintenance owner for each custom org hierarchy so it does not drift into irrelevance.​

    Custom orgs are a powerful tool when used intentionally; they become clutter when created ad-hoc without clear purpose.​

    Practical steps to fix a broken org structure

    If your tenant has a broken or overly complex org design, here is how to approach the fix:

    1. Assess current state
      • Map the existing supervisory org structure, matrix orgs and custom hierarchies.​
      • Identify pain points: where do approvals break? Where do reports show the wrong hierarchy? Where do reorgs cause chaos?​
    2. Engage stakeholders
      • Work with HR, Finance, business leaders and IT to define the desired future state: how should the org actually look?​
      • Get agreement on principles: simplicity, alignment with real management lines, and scalability.​
    3. Design the target org model
      • Use Org Studio to visualize and validate the new hierarchy before making changes.​
      • Plan for supervisory orgs (primary hierarchy), matrix orgs (secondary relationships) and custom hierarchies (analytics views).​
    4. Execute via reorganization events
      • Use Reorganize Supervisory Organization to implement changes in a controlled, effective-dated way.​
      • Batch related changes together to minimize disruption and maintain clean historical data.​
    5. Test and validate
      • Test security, business processes, reports and dashboards against the new org structure before going live.​
      • Run parallel reporting to ensure analytics and history remain consistent.​
    6. Maintain discipline going forward
      • Establish governance for org changes: who can request, who approves, and how reorgs are executed.​
      • Regularly review org structures to catch drift and keep them aligned with the business.​

    Fixing broken orgs is not a quick task, but with a methodical approach and strong stakeholder engagement, it is possible to move from chaos to clarity.​

    When supervisory, matrix and custom organizations are used correctly and maintained intentionally, Workday’s org structures become a strength: they reflect how the business actually works, enable the right people to see and do the right things, and provide trusted views for analytics and decision-making.