1.2 The Object Management Model & Business Objects

Workday Pro Platform Administrator Certification Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The Workday Platform

1.1 Workday Products, Functional Areas & Product Touchpoints 1.2 The Object Management Model & Business Objects 1.3 Navigation & Search Techniques 1.4 Organizations in Workday

2 Chapter 2: Tenants & Release Management

2.1 Tenant Types & Tenant Management Tasks 2.2 Releases, Adoption, System Testing & Support

3 Chapter 3: The Configurable Security Framework

3.1 Components of the Configurable Security Framework 3.2 Core Security Group Types: Workday-Assigned, User-Based & Role-Based 3.3 Advanced Security Group Types

4 Chapter 4: Security Policies, Assignment & Troubleshooting

4.1 Domain Security Policies & Permissions 4.2 Assigning Roles & Security Group Membership 4.3 Troubleshooting Security Access Issues

5 Chapter 5: Business Process Definitions & Steps

5.1 The Business Process Framework & Definitions 5.2 Business Process Step Types 5.3 Step Configuration, Order & the Completion Step

6 Chapter 6: BP Security, Condition Rules & Troubleshooting

6.1 Business Process Security Policies 6.2 Creating & Testing Condition Rules 6.3 Using Reports to Troubleshoot Business Processes

7 Chapter 7: Report Foundations & Custom Reports

7.1 Business Objects, Fields, Related Business Objects & Data Sources 7.2 Standard Reports, Custom Report Types & the Report Writer 7.3 Worklets, Dashboards & Sharing Reports

8 Chapter 8: Calculated Fields, Alerts & Report Administration

8.1 Identifying & Maintaining Calculated Fields 8.2 Configuring & Testing Alerts 8.3 Scheduling Reports, Report Groups & Transferring Ownership 8.4 Troubleshooting Report Data & Access Issues

9 Chapter 9: Integration Architecture & Security

9.1 Workday Integration Architecture & Web Services 9.2 Workday Integration Tools & Choosing the Right One 9.3 Integration System Users & Integration System Security Groups

10 Chapter 10: Enterprise Interface Builders

10.1 Creating & Launching an Inbound EIB 10.2 Creating & Launching an Outbound EIB 10.3 Troubleshooting EIB Data Loads & Access Issues

1.2 The Object Management Model & Business Objects

Key Takeaways Explain This Topic AI

Workday stores all customer data as in-memory business objects with fields and instances, not as rows in relational tables that users query directly.

A business object is comparable to a spreadsheet or table: fields are the columns and instances are the rows; Workday automatically links related objects into a web of relationships.

The primary business object of a report holds the data the report returns; related business objects are reachable through fields and can have one-to-one or one-to-many relationships with it.

Metadata is the Workday-delivered framework you cannot change; tenanted data is the configuration and data you add, which makes your instance unique.

The Object Management Services layer handles data encryption, persistence, security, and auditing, and includes the Object Transaction Service for transactions and Object Reporting Services for UI and background reporting.

Last updated: August 2026

Why the object model is worth real study time

The objective is describe the Workday object management model and the use of business objects . It sounds abstract, but it is the single most leveraged concept in the whole exam. If you understand objects, then report data sources, related business objects, calculated fields, security domains, and web services all stop being separate topics and become one topic seen from four angles.

Objects, fields, and instances

Workday stores customer data as business objects - organizations, workers, positions, job profiles, cost centers, expense reports, journals. Workday's courseware makes the analogy explicit: a business object is like a database table or a spreadsheet worksheet.

Spreadsheet term Workday term Example
Worksheet / table Business object Worker
Column Field Hire Date, Job Profile, Employee ID
Row Instance Logan McNeil, Gail Bradley

An instance is one specific occurrence of the object. "Worker" is the business object; "Logan McNeil" is an instance of it. Workday prompts return instances, filters compare instances, and security constrains you to a subset of instances.

The power of objects

Workday automatically links related business objects together, creating a web of interrelated objects. This is what the courseware calls the power of objects : because data is contextual, when you see something in Workday you can usually act on it or drill into related data directly.

A worked example from Workday's own material: ┌──────────────────┐
│ Worker │ ← primary business object
└────────┬─────────┘
┌───────────────┼────────────────┐
▼ ▼ ▼
┌──────────┐ ┌─────────────┐ ┌──────────────┐
│ Position │ │ Supervisory │ │ Personal │
│ │ │Organization │ │ Data │
└────┬─────┘ └─────────────┘ └──────────────┘
▼
┌─────────────┐
│ Job Profile │
└──────┬──────┘
▼

Management Level, Job Classification, Exempt Status...

A worker is associated with a position; that position is associated with a job profile; that job profile carries a management level, job classification, exempt status, and more. You never have to write a join - Workday already knows the path.

Related Actions is the user-facing consequence. The Related Actions menu on an object exposes the tasks and reports available for that object, filtered by your security. If Related Actions is missing or short, that is a security symptom, not a data symptom.

Primary and related business objects

When you build a report, you choose a data source, and the data source determines the primary business object (PBO) . The PBO holds the data the report returns - one row of output per instance of the PBO.

Related business objects (RBOs) are objects associated with the primary object through fields. They let you pull fields into a report that do not belong to the PBO itself. An RBO may have a one-to-one relationship with the PBO (a worker has one primary position) or a one-to-many relationship (a worker has many dependents).

High-yield distinction: a single-instance RBO can be used directly as a column. A multi-instance RBO returns a set, so you either accept a multi-line cell, use a calculated field to extract a single instance, or build the report on the other object as the PBO. Report designers who ignore this produce reports that look "duplicated" or "blank" - and the exam tests exactly that symptom.

Metadata versus tenanted data

Workday's courseware uses a leased-apartment analogy that is worth keeping:

What it is Can you change it?

Metadata The Workday-delivered framework - business object definitions, delivered fields, domains, business process types No

Tenanted data Your configuration and your data - organizations, security groups, custom reports, calculated fields, business process definitions, workers Yes

Metadata is the plumbing and the walls. Tenanted data is the furniture. This distinction is the reason customers cannot invent a new business object type or a new domain: those are metadata.

Underneath: Object Management Services

Workday stores customer data as in-memory objects. Originally a suite of business services called the Object Management Server (OMS) maintained the relationships and integrity of those objects; over time it has evolved into a set of microservices that scale with transaction and reporting demand. OMS handles data encryption, data persistence, security, and auditing , and it includes these subservices:

Subservice Role

Object Transaction Service (OTS) The transactional workhorse - holds tenant business data, performs read and update transactions

Object Reporting Service (ORS) for the UI Offloads fast UI-driven traffic, used heavily by customers with many users

Object Reporting Service (ORS) for reporting Runs long-running, memory-intensive, background and scheduled reports, plus Reports as a Service (RaaS) and direct web service reads

Application Object Database (AOD) Synchronizes OTS, ORS, and the database; handles indexing and search

You will not be asked to draw this architecture, but two consequences are examinable. First, background and scheduled reports run on a different service from interactive UI work - which is precisely why Workday tells you to schedule heavy reports rather than run them interactively. Second, search and indexing are handled by AOD , which is why a newly created object can occasionally be actionable before it is findable by search.