1.2 The Object Management Model & Business Objects
Key Takeaways
- 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.
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.
In a Workday custom report, a designer needs a field that does not exist on the object the data source returns. What is the correct concept to reach that field?
Which pair correctly matches a Workday concept to its spreadsheet analogy?
An administrator wants to add a brand-new business object type to hold data that Workday does not deliver. What is the correct assessment?