Workday · The data model
Where are the tables in Workday?
There aren't any. Workday stores business objects, not tables you can query. The model, and how it translates into a warehouse you own.
◆From object to your table, left to right
01 · OBJECT
The business object
Worker · Position · Payroll Result
›
02 · SHAPE
Fields & instances
instance ≈ row · field ≈ column
›
03 · READ
The data source
what reports see · security applies here
›
04 · EXTRACT
Out, on a schedule
RaaS · WQL
›
05 · OWN
Your real tables
star schema · history kept
◆ The translation table— each Workday concept, its nearest relational idea, and the difference that matters.
| In Workday | Nearest relational idea | The difference that matters |
|---|---|---|
| Business object | A table | Objects reference each other natively. There is no schema diagram to read; you follow the defined paths. |
| Instance | A row | An instance carries its full effective-dated history; a row is one point in time. Rebuilding that history is the core of the extraction work. |
| Field | A column | A field can hold a value or a reference to another object. References are how you traverse, not joins you write. |
| Related object | A foreign key | Traversal paths are defined by Workday. You follow the paths that exist; you cannot join arbitrarily. |
| Data source | A view | The only thing reports and WQL actually read. Security, filtering, and performance live here, not on the object. See data sources & WQL. |
| Indexed data source | An indexed view | Pre-optimized for speed. Prefer it when one exists for your primary object. |
| Calculated field | A derived column | Logic defined in the tenant. It does not travel with most extracts; rebuild it as models you own. |
◆ The hub objects— a handful of objects anchor everything in the model.
| Object | What it anchors |
|---|---|
| Worker | The person: job, compensation, organization assignments, events. Nearly every people report resolves to Worker. |
| Position | The seat, filled or open. Position management ties headcount plans to real people. |
| Job Profile | What the work is: family, level, exempt status. The job architecture. |
| Supervisory Organization | Who reports to whom. A recursive tree, flattened before any BI tool can use it. |
| Compensation Plan | How pay is structured: base, bonus, allowance, merit. |
| Payroll Result | What was actually paid, line by line. The money spine, and the bridge to the general ledger. |
| Job Requisition | The opening: candidates, applications, offers hang off it. |
◆ How this becomes your warehouse— object to table, instance to row, effective-dated history to SCD2, plus the snapshot Workday does not keep.
| Move | What you build |
|---|---|
| Objects → dimensions | Worker, org, job, and location become dimension tables. Worker is SCD2: one row per effective-dated change, with from and to dates. |
| Events → facts | Hires, terminations, transfers, payroll lines, and applications become fact tables at their natural grain. |
| History → snapshots | A daily or monthly worker snapshot fact answers point-in-time questions instantly. Workday does not keep this table; you build it and keep it. |
| References → keys | Workday's object references become plain foreign keys. Now any BI tool can join anything to anything, which the report writer never could. |
◆ What to watch— security scopes what you see, references need flattening, and the model is effective-dated everywhere.
| Watch for | Why it matters |
|---|---|
| Domain security | The extract sees only what its ISU is granted. A missing field in your landing zone is usually a missing security grant. |
| Multi-instance fields | A worker can hold several values for one field, additional jobs for example. Flatten them deliberately, otherwise counts inflate. |
| Effective dating | Nearly every object is effective-dated. Extracting "current" and extracting "as of a date" are different pulls. See effective dating. |
| Contingent workers | Worker covers employees and contingent workers. Decide who counts in headcount once, and encode it in the model. |
Want the object model translated into tables you own?
We build the worker dimension with full history, the event facts, and the daily snapshot, reconciled against Workday, and you own every line.
Terms on this page
- business object
- Workday's unit of storage: fields plus instances, connected to other objects.
- instance
- One occurrence of an object, roughly a row, but carrying its full history.
- field
- An attribute on an object, roughly a column. Can hold a value or a reference.
- related object
- An object reachable from another through a defined reference, roughly a foreign key.
- data source
- The published set of instances and fields a report or WQL query reads. Security applies here.
- indexed data source
- A data source pre-optimized for fast retrieval.
- calculated field
- Report logic defined inside the tenant. Rebuild it in your warehouse or lose it.
- SCD2
- Slowly changing dimension, type 2: one row per change, with validity dates. How a warehouse keeps history.
- snapshot fact
- A table capturing the state on each day or month. Answers point-in-time questions instantly.
- ISU
- Integration System User, the read-only service account extracts run as.
- WQL
- Workday Query Language. Queries a data source over REST, with paging.
- RaaS
- Report-as-a-Service. A custom report published as a URL you can call for the rows.