The Architecture of Workday Extend (2026)

Understanding the architecture of Workday Extend is essential for anyone planning to build or evaluate a Workday Extend application. This guide covers the four core components of a Workday Extend application — data model, user interface, business logic, and security — and explains how they work together.

---

What Is the Workday Extend Architecture?

A Workday Extend application is built from four architectural components:

1. Data Model — Custom Business Objects (CBOs) that store application data
2. User Interface — Screens and components built with the Extend UI framework
3. Business Logic — Orchestrations that define application behavior
4. Security — Roles and policies that control access

These four components are configured and deployed within the Workday tenant. They use Workday's native infrastructure — the same servers, databases, and security model as the rest of Workday. There is no separate infrastructure to manage.

For an introduction to Workday Extend, see our What Is Workday Extend guide.

---

Key Concepts

Workday Extend Studio: The integrated development environment (IDE) for building Workday Extend applications. It provides a visual designer for UI components, a code editor for orchestrations, a data model designer for CBOs, and a testing environment.

Custom Business Objects (CBOs): CBOs are the data layer of a Workday Extend application. They are custom data structures stored in Workday's database. CBOs can have fields of any type (text, number, date, boolean, reference), can reference native Workday objects (workers, organizations, cost centers), and can be related to each other.

Workday Extend UI Framework: The UI framework provides a library of Workday-native UI components — forms, tables, buttons, charts, navigation elements. Applications built with the Extend UI framework look identical to native Workday features.

Orchestrations: Orchestrations are the business logic layer. They are event-driven workflows that execute when a user takes an action (submits a form, clicks a button) or when a scheduled trigger fires. Orchestrations can read and write Workday data, call external APIs, trigger Workday business processes, send notifications, and execute conditional logic.

Workday APIs in Extend: Orchestrations can call Workday's REST APIs to read and write native Workday data. They can also call external REST APIs to integrate with third-party systems.

---

Component Deep Dive

Data Model (Custom Business Objects)

CBOs are the foundation of a Workday Extend application's data architecture. Each CBO is a custom data type with a defined set of fields. For example, an Equipment Management application might have a CBO called "Equipment" with fields for serial number, model, purchase date, assigned employee, and maintenance schedule.

CBOs support:

• Simple fields: Text, number, date, boolean, currency
• Reference fields: Links to native Workday objects (workers, organizations, cost centers, projects)
• Related objects: Links to other CBOs
• Calculated fields: Fields whose values are derived from other fields

CBO data is stored in Workday's database and is subject to the same backup, recovery, and security policies as native Workday data.

User Interface

The Extend UI framework provides a component library that matches Workday's native design system. Developers use these components to build application screens — data entry forms, data display tables, dashboards, and navigation menus.

Key UI components include:

• Rich Text Input: For text data entry
• Date Picker: For date selection
• Lookup: For selecting a value from a list (including Workday reference data)
• Table: For displaying lists of records
• Chart: For displaying analytics

The UI framework is responsive — applications work on both desktop and mobile browsers.

Business Logic (Orchestrations)

Orchestrations are the most powerful component of a Workday Extend application. They define what happens when a user takes an action or when a scheduled trigger fires.

Orchestrations can:

• Read and write CBO data
• Read and write native Workday data via APIs
• Trigger Workday business processes (approvals, notifications)
• Call external REST APIs
• Execute conditional logic (if/then/else)
• Loop over collections of data
• Handle errors and exceptions

Orchestrations are written in Workday's proprietary scripting language, which is similar to JavaScript. Developers with JavaScript experience can learn the Extend scripting language relatively quickly.

Security

Workday Extend applications use Workday's native security model. Access to application features is controlled by security roles and domain policies — the same mechanism used to control access to native Workday features.

Developers define:

• Security roles: Who can access the application
• Domain policies: What actions each role can perform (view, create, edit, delete)
• Data visibility: What data each role can see

---

Best Practices

Design the data model first. Before building any UI or orchestrations, design the CBO data model. A well-designed data model makes the rest of the application easier to build and maintain.

Use native Workday data wherever possible. Reference native Workday objects (workers, organizations, cost centers) rather than duplicating data in CBOs. This ensures data consistency and reduces maintenance burden.

Keep orchestrations focused. Each orchestration should do one thing well. Complex orchestrations that try to handle multiple scenarios become difficult to debug and maintain. Break complex logic into multiple focused orchestrations.

Test in sandbox before production. Always test Workday Extend applications in a sandbox tenant before deploying to production. Workday's twice-yearly updates can affect application behavior.

---

Frequently Asked Questions

What programming skills are needed to build Workday Extend applications? The Extend UI framework and CBO data model can be configured without writing code. Orchestrations require scripting skills — Workday's scripting language is similar to JavaScript. Developers with JavaScript or TypeScript experience can learn it quickly.

How are Workday Extend applications deployed? Applications are developed in a sandbox tenant and deployed to production using Workday's migration tools. The deployment process is similar to deploying other Workday configuration changes.

Can Workday Extend applications access data outside of Workday? Yes. Orchestrations can call external REST APIs to read and write data in third-party systems. This allows Workday Extend applications to integrate with external systems without building a separate Workday integration.

How are Workday Extend applications maintained? Applications require maintenance when Workday releases major updates (twice per year). Developers should test applications in a sandbox tenant before each Workday update is applied to production.

---

Key Takeaways

• A Workday Extend application has four architectural components: data model (CBOs), user interface (Extend UI framework), business logic (orchestrations), and security.
• CBOs store application data in Workday's database, using the same infrastructure as native Workday data.
• The Extend UI framework provides native Workday UI components that make custom applications look identical to built-in features.
• Orchestrations are the most powerful component — they define application behavior and can interact with Workday data, external APIs, and Workday business processes.
• Applications are deployed using Workday's standard migration tools and require maintenance with each Workday update.

---

AssistNow builds Workday Extend applications for enterprise clients. Contact us to discuss your architecture requirements.