When designing a new feature or data capture requirement in Workday, solution architects face an immediate architectural decision: should the new attributes be added as Custom Fields on an existing core business object (such as Worker, Position, or Job Requisition), or modeled as a Custom Business Object (CBO) in a Workday Extend application?

Choosing the wrong storage pattern introduces long-term friction: bloated core objects can slow down custom report execution, while unnecessary Extend apps consume subscription resources and add integration overhead.

This guide provides a decision framework based on cardinality, audit requirements, security boundaries, and reporting patterns.

1. Architectural Comparison at a Glance

Architectural Dimension Core Custom Fields Extend Custom Business Object (CBO)
Cardinality 1:1 with an existing core business object 1:Many, Many:Many, or standalone
Data Ownership Lives directly on the core object instance Independent instance with optional reference keys
Reporting Access Standard Report Writer, WQL, and RaaS Workday Query Language (WQL) and Extend APIs
Security Model Core Domain Security Policies Extend Application Security and Object Policies
Storage & Retention Governed by core object purge policies Governed by Extend app lifecycle and retention rules
Deployment Model Object Transporter (OX) or Solution migration Extend application package deployment

2. When to Use Core Custom Fields

Use core custom fields when the requirement represents a direct, singular attribute of an existing Workday entity.

Ideal Scenarios

  1. Simple 1:1 Attributes: Adding a badge number, a parking permit identifier, or a specialized compliance flag to a Worker profile.
  2. Business Process Routing Inputs: You need a single field that condition rules in core business processes (such as Job Change or Requisition Approval) must evaluate immediately.
  3. Heavy Standard Reporting: The data needs to appear seamlessly in dozens of existing standard Report Writer custom reports alongside built-in fields without needing WQL joins.
  4. No Custom Workflow: The field is edited through standard Workday tasks (such as Edit Additional Data or Change Job) and requires no independent user interface.

Constraints to Watch

  • Flat Structure: Custom fields cannot represent child lists or complex relational structures on their own without creating multiple calculated fields.
  • Namespace Clutter: Adding dozens of custom fields to the Worker business object degrades Report Writer searchability and complicates calculated field maintenance.

3. When to Model a Custom Business Object (CBO)

Model a Custom Business Object in Workday Extend when the data has its own lifecycle, multiple records per worker, or requires a dedicated user interface.

Ideal Scenarios

  1. 1:Many or Many:Many Relationships: An employee can submit multiple equipment requests, hold multiple professional certifications with expiration histories, or log multiple mentorship pairings.
  2. Independent Lifecycles: The entity goes through its own status transitions (such as Draft, Submitted, Under Review, Archived) that are distinct from standard HR events.
  3. Dedicated User Interface: The requirement calls for a tailored multi-step digital experience built with Page Model Definition (PMD) or custom components rather than standard Workday task forms.
  4. Isolated Security & Auditing: The data is highly sensitive (for example, accommodation requests or health monitoring) and must be isolated from standard HR Partner security domains.
  5. Orchestrated External Integration: The records are created or updated automatically by an external system via Workday Orchestrate.

Constraints to Watch

  • Report Writer Availability: CBOs cannot always be added as primary business objects in standard custom reports without configuring reporting data sources and exposing WQL representations.
  • Immutability Rules: Once a CBO attribute is published and populated in a production tenant, modifying field types or deleting fields requires careful deprecation planning.

4. The 4-Question Decision Checklist

Run through these four questions before starting your build:

  1. Can one person or object have more than one of these records?
    • If yes: Choose a Custom Business Object (CBO).
  2. Does the data need a dedicated, branded screen for end users?
    • If yes: Choose an Extend App with a CBO.
  3. Will this field be used in core business process condition rules tomorrow?
    • If yes: A Core Custom Field is typically faster to configure and binds natively to core business process rules.
  4. Does this data need to be purged independently of the employee's standard personnel record?
    • If yes: Choose an Extend CBO, which allows custom data retention policies.

Sources checked