Workday FDM (Federated Data Model) Structure

Overview

Workdays Federated Data Model (FDM) is the backbone that enables the cloudbased enterprise system to store, validate, and share data across all functional areas. Unlike a monolithic data model, FDM separates logical data definitions from the physical storage mechanisms, allowing a single source of truth to be used by HR, Finance, Planning, and other modules. The model is built around reusable business objects, each representing a realworld entity such as Worker, Cost Center, or Project.

Core Principles

• Federation: Data is defined once and then made available across all Workday applications without duplication.
• Extensibility: Customers can extend standard objects with custom fields, validation rules, and business processes.
• Referential Integrity: Relationships between objects are enforced by the platform, ensuring consistency.
• SecurityCentric Design: Access to data is controlled at the object and field level through security groups and domain policies.
• Configurability: Most behavioursuch as default values, derived fields, and calculated metricscan be configured without code.

Object Model

Workday objects fall into three broad categories:

1. Core Objects Fundamental entities that exist in every implementation (e.g., Worker, Organization).
2. Reference Objects Lookup tables that supply codevalue pairs (e.g., Country, Currency, Job Profile).
3. Transactional Objects Capture events and changes over time (e.g., Job Change, Payroll Run, Expense Report).

Standard Object Example: Worker

Custom Extensions

Tenants can add custom fields to any object. For instance, a global firm may add Regional_Manager_Code to the Worker object. Extensions keep the same security and validation framework as standard fields.

Relationships Between Objects

Relationships are defined as either onetomany or manytomany. Workday uses a parentchild terminology for hierarchical structures such as Organizations. The platform automatically creates reverse navigation paths so developers can query in either direction.

OnetoMany Example: Organization Worker

• Parent: Organization
• Child: Worker
• Each organization can have many workers, but a worker belongs to a single primary organization.

ManytoMany Example: Workers Projects

The association is captured by the junction object Project Assignment, which stores start/end dates, role, and allocation percentage.

Derived and Calculated Fields

Some fields are not stored physically but are derived at runtime, such as Tenure_Years (current date minus Hire_Date) or Full_Name (concatenation of first and last names). These calculations respect security filters, ensuring only authorized users see the result.

Integration Points

The FDM is exposed to external systems through a set of welldefined APIs:

• Web Services (SOAP/REST) Standard CRUD operations on objects.
• Report-as-a-Service (RaaS) Allows consumption of custom reports as JSON, XML, or CSV.
• Workday Studio Graphical integration builder that can map FDM objects to inbound/outbound data flows.
• Enterprise Interfaces (EIB) Simple filebased import/export tools for batch loads.

Sample API Call (GET Worker)

GET https://wd5-impl.myworkday.com/ccx/api/v1/workers/12345Authorization: Bearer <access_token>Accept: application/json

The response respects the calling users security domain, and only fields the user has permission to view are returned.

Best Practices for Designing with FDM

1. Start with the Standard Model Use outofthebox objects wherever possible. Custom objects increase maintenance overhead.
2. Leverage Reference Data Populate lookup tables (e.g., Country, Currency) early to avoid validation errors later.
3. Plan Security Early Define domain policies before loading data so that security filters apply during initial imports.
4. Use Derived Fields for Calculations Instead of storing redundant values, create calculated fields where the logic is simple and performant.
5. Document Extensions Maintain a datadictionary spreadsheet that records every custom field, its purpose, and its security group.
6. Test Integration Scenarios Verify that API consumers can retrieve both standard and custom fields and that error handling respects Workdays business rules.
7. Monitor Data Quality Enable Workdays data validation rules and set up periodic data quality reports to catch orphaned records.

Conclusion

The Workday Federated Data Model provides a unified, secure, and highly configurable foundation for enterprise data. By understanding its object hierarchy, relationship patterns, and integration capabilities, architects and functional consultants can design solutions that are both robust and adaptable to future business needs. Remember to prioritize the use of standard objects, enforce security at the domain level, and keep a clear record of any customizationspractices that together ensure a clean, maintainable Workday environment.