1.2 Business Objects, Data Model & Related Actions

1.2 Business Objects, Data Model & Related Actions

Quick Answer: Workday's data architecture is strictly object-oriented, replacing relational database tables, rows, and foreign keys with Business Objects, Instances, and Fields. When configuring reports or business processes, designers designate a Primary Business Object (PBO) as the anchor and navigate to Related Business Objects (RBOs) via single-instance and multi-instance fields. Contextual navigation is driven by the Related Actions menu (the iconic three-dot "twinkie" icon). Crucially, the Related Actions menu is dynamically security-trimmed: users only see the actions and view items their assigned security groups permit.

---

The Workday Object-Oriented Data Model vs. Relational Databases

To pass the Workday HCM certification exam, consultants must transition from relational database thinking (RDBMS) to an object-oriented data model.

Business Objects as Object Classes

In Workday, a Business Object (BO) represents an entity or abstract concept within the enterprise. A business object defines the blueprint, attributes, and relationships of that entity. It is conceptually equivalent to a class in object-oriented programming or a table in a relational database.

• Examples of Business Objects: Worker, Position, Supervisory Organization, Job Profile, Compensation Plan, Applicant.

Instances as Realized Records

An Instance is a concrete, individual occurrence of a Business Object. An instance is conceptually equivalent to an instantiated object in OOP or a single row/record in a relational table.

• If Worker is the Business Object, then "Logan McNeil (21001)" is an instance of that business object.
• If Supervisory Organization is the Business Object, then "Global Modern Services (GMS)" is an instance.

Relational vs. Workday Data Model Comparison

Because Workday connects instances through direct object pointers stored in memory rather than disk-bound relational joins, Workday applications avoid table locks and foreign key index rebuilds during large-scale transactions.

---

Primary vs. Related Business Objects

When creating custom reports in the Report Writer, configuring business process condition rules, or extracting data via EIBs, understanding object relationships is critical.

+-----------------------------------------------------------------------------------+
|                         PRIMARY BUSINESS OBJECT (PBO)                             |
|                                    WORKER                                         |
|   - One row per instance in the primary report results                            |
+-----------------------------------------------------------------------------------+
         |                                      |                                  |
         | Points to exactly ONE (1:1)          | Points to ONE or MANY (1:N)      |
         v                                      v                                  v
+-----------------------+              +----------------------+         +----------------------+
| RELATED OBJECT (RBO)  |              | RELATED OBJECT (RBO) |         | RELATED OBJECT (RBO) |
|  Supervisory Org      |              |      Dependents      |         |     Job History      |
| (Single-Instance Field|              | (Multi-Instance Field|         | (Multi-Instance Field|
+-----------------------+              +----------------------+         +----------------------+

The Anchor: Primary Business Object (PBO)

The Primary Business Object (PBO) is the starting point or anchor for a functional operation or report. The selection of the PBO determines the fundamental grain of the data:

• In a report where Worker is the PBO, each output row represents exactly one worker instance.
• In a report where Position is the PBO, each output row represents one position instance (even if a position is currently vacant and has no associated worker).

Linked Contexts: Related Business Objects (RBO)

A Related Business Object (RBO) is an object associated with the PBO through an object reference field. For example, on the Worker business object:

• Position is an RBO linked via the worker's primary position field.
• Supervisory Organization is an RBO linked via the worker's management assignment.
• Compensation Package is an RBO linked via the position's compensation details.

Directionality and Traversal

Object relationships in Workday have directionality:

• From Worker (PBO), navigating to Supervisory Organization yields a Single-Instance RBO (the worker reports to one primary supervisory organization).
• From Supervisory Organization (PBO), navigating to Worker yields a Multi-Instance RBO (the organization contains many workers). Choosing the wrong PBO is the single most common cause of duplicate rows or missing records in Workday reporting.

---

Workday Field Classifications

Fields represent the data stored on or derived for a business object. Workday categorizes fields into three structural types based on their underlying data storage and cardinality.

1. Simple Fields

Simple fields store a primitive data value directly associated with an instance. They do not point to other business objects.

• Data Types: Text, Number, Date, DateTime, Boolean, Currency.
• Examples on Worker: First Name (Text), Hire Date (Date), Age (Number), Is Manager (Boolean).

2. Single-Instance Fields

A Single-Instance field stores a reference pointer that links to exactly one instance of another business object (a one-to-one or many-to-one relationship).

• Characteristics: Can return zero (null) or exactly one instance, but never multiple instances.
• Examples on Worker: Manager (points to one Worker instance), Supervisory Organization (points to one Org instance), Gender (points to one Gender instance).

3. Multi-Instance Fields

A Multi-Instance field stores a collection of reference pointers linking to zero, one, or multiple instances of another business object (a one-to-many relationship).

• Characteristics: Returns a list or array of related object instances.
• Examples on Worker: Direct Reports (list of Worker instances), Dependents (list of Dependent instances), All Prior Job Profiles (list of Job Profile instances).

Field Types Classification Matrix

---

The Related Actions Menu ("The Twinkie")

In the Workday user interface, whenever a business object instance is displayed (as a link, header, or table entry), an icon featuring three dots inside a small rectangle or circle appears next to the object's name. This icon is universally known in the Workday ecosystem as the Related Actions icon (or colloquially, the "twinkie").

Contextual Interaction Mechanics

Clicking the Related Actions icon on an instance opens a context-sensitive dropdown menu containing all tasks, reports, and administrative workflows that can be executed specifically on that instance.

Logan McNeil  [ ... ]  <-- Related Actions Icon ("Twinkie")
                |
                +--> [ Action ]
                |      +--> Job Change > Transfer, Promote or Change Job
                |      +--> Compensation > Request Compensation Change
                |      +--> Security > View Security Groups for User
                |
                +--> [ View ]
                       +--> View Worker History
                       +--> View Profile
                       +--> View Support Roles

Action Actions vs. View Actions

Within the Related Actions menu, options are divided into two distinct functional categories:

1. Action Actions:

   • Definition: Menu items that initiate a state-changing transaction or trigger a business process event.
   • Operational Effect: Modifies data, updates records, or submits an approval request into workflow routing.
   • Examples: Job Change > Transfer Employee, Compensation > Request Base Pay Change, Organization > Move Workers.

2. View Actions:

   • Definition: Menu items that provide read-only access to historical data, configurations, or contextual audit logs.
   • Operational Effect: Does not modify data, create events, or alter system state.
   • Examples: View Worker History, View All Subordinates, View Effective Dated Compensation Details.

Action vs. View Comparison

---

Security Trimming & Contextual Visibility

A critical concept on the Workday certification exam is security trimming on Related Actions menus.

Dynamic Security Filtering

Related Actions menus are not static; they are dynamically assembled in real time based on the active user's effective security permissions:

• When User A clicks the Related Actions icon on Logan McNeil, they may see 25 actions (including Terminate, Change Compensation, and Promote).
• When User B clicks the Related Actions icon on the exact same instance of Logan McNeil, they may only see 2 actions (such as View Org Chart and Give Feedback).

Security Policy Enforcement

• Domain Security Policies: Control whether a user has View (Get) or Modify (Put) access to specific functional data fields.
• Business Process Security Policies: Control whether a user has permission to Initiate, Approve, or Cancel a specific business process type on that target instance.
• If a user's assigned security groups do not grant Initiate permission on the Transfer Employee business process policy for workers in that supervisory organization, the Job Change > Transfer action is completely suppressed from the menu. It does not appear greyed out; it is entirely invisible.

---

Business Object Audit Trails & History

Every instance of every business object in Workday maintains an immutable, system-generated audit record.

Built-in Audit Fields

Whenever an instance is created or modified, Workday automatically records:

• Created By: The user account that initially created the instance.
• Created Moment: The exact system timestamp (date, hour, minute, second, timezone) when the instance was committed to memory.
• Last Functionally Updated By: The user who completed the most recent approved functional transaction.
• Last Updated Moment: The timestamp of the most recent functional modification.

View Audit Trail Task

From the Related Actions menu of any business object instance, authorized administrators can select Audit > View Audit Trail. This displays the complete historical sequence of changes, detailing the previous field value, the new field value, the effective date of the change, and the user who committed the update. Because this audit trail is generated by the in-memory kernel, it cannot be tampered with or disabled.

---

Certification Pitfalls & Common Exam Traps

1. The "Missing Menu Option" Trap: An exam question often describes a manager who can initiate a Job Change on their direct reports, but cannot see the Job Change action when clicking on a peer or indirect report. The question will ask whether the business process definition is broken or if a system error occurred. The correct answer is always security permissions: the user lacks the required security group assignment or constrained role to initiate that business process on that specific target population.
2. Confusing Single-Instance and Multi-Instance in Condition Rules: In business process condition rules, selecting a multi-instance field (like Dependents) with a simple operator like equal to results in a rule validation error. Multi-instance fields require collection operators like any in selection or count greater than.
3. PBO Misalignment in Reports: If a report designed to show open positions produces multiple rows per position or only shows filled positions, the report author incorrectly chose Worker as the PBO instead of Position. Remember: Worker as PBO cannot report on vacant positions because vacant positions have no worker instance attached.