The Complete Guide to Workday Extend Development

What Is Workday Extend?

Workday Extend is a platform-native development framework that allows organizations to build custom applications directly on top of the Workday platform. Unlike external integrations that bolt functionality onto Workday from the outside, Extend apps run inside the Workday environment, leveraging the same security model, data layer, and user experience that core Workday modules use.

This distinction matters. When you build on Extend, your custom apps inherit Workday's tenant-level security, participate in its transactional model, and appear seamlessly within the Workday user interface. There is no separate authentication layer to manage, no data synchronization to maintain, and no external hosting infrastructure to provision.

Workday Extend development centers around four core building blocks: Business Objects (BOs), Business Processes (BPs), Orchestrations, and Presentation Model Definitions (PMDs), tied together by expression languages and scripts. Understanding how these components interact is the foundation of effective Extend development.

Core Concepts

Business Objects (BOs)

Business Objects are the data backbone of any Extend application. A Business Object defines a structured data entity -- its fields, relationships, validations, and security constraints. Think of BOs as database tables with built-in governance.

Every BO in Workday Extend has:

• Fields with defined data types (TEXT, DATE, BOOLEAN, INTEGER, DECIMAL, CURRENCY, SINGLE_INSTANCE, MULTI_INSTANCE)
• Security domains that control who can read, create, or modify records
• Referential relationships to other Business Objects or to Workday delivered objects (like WORKER)
• A default collection that defines how instances are grouped and labeled

Here is an example of a Business Object definition for tracking equipment requests, shown in the actual JSON format used by App Builder:

{
  "id": 1,
  "name": "EquipmentRequest",
  "label": "Equipment Request",
  "defaultSecurityDomains": [
    "ManageEquipmentRequests"
  ],
  "defaultCollection": {
    "name": "equipmentRequests",
    "label": "All Equipment Requests"
  },
  "fields": [
    {
      "id": 1,
      "name": "equipmentType",
      "type": "TEXT",
      "label": "Equipment Type",
      "useForDisplay": true,
      "isReferenceId": true,
      "description": "Type of equipment requested"
    },
    {
      "id": 2,
      "name": "justification",
      "type": "TEXT",
      "label": "Justification",
      "description": "Reason for the equipment request"
    },
    {
      "id": 3,
      "name": "costEstimate",
      "type": "CURRENCY",
      "label": "Cost Estimate",
      "description": "Estimated cost of the equipment"
    },
    {
      "id": 4,
      "name": "requestedFor",
      "type": "SINGLE_INSTANCE",
      "label": "Requested For",
      "target": "WORKER",
      "description": "The worker this equipment is requested for"
    },
    {
      "id": 5,
      "name": "requestDate",
      "type": "DATE",
      "label": "Request Date",
      "description": "Date the request was submitted"
    }
  ]
}

A few important design considerations for Business Objects:

• Plan your references carefully. References to core Workday objects (like Worker, Organization, or Cost Center) give your app rich context without duplicating data. However, each reference adds coupling to the core data model, so be intentional about what you link.
• Leverage Business Processes for status tracking. Rather than manually managing status fields on your BO, use Business Process steps and completion logic to drive state transitions. This keeps your workflow and status in sync and makes reporting more reliable.
• Think about reporting from the start. BOs can surface data in Workday reports and dashboards. Structure your fields with reporting use cases in mind -- avoid deeply nested objects where flat structures would serve better.

Business Processes (BPs)

Business Processes in Workday Extend define the workflow logic around your data. A BP specifies what happens when a record is created or modified: who needs to approve it, what notifications fire, and what downstream actions trigger.

If Business Objects are your data model, Business Processes are your state machine.

A typical BP for the equipment request example above might include:

1. Initiation step -- the requester submits the request
2. Manager approval -- routed to the requester's manager based on supervisory org
3. Finance review -- conditional step, configured declaratively to trigger only when the cost estimate exceeds a threshold
4. Fulfillment action -- notifies the IT procurement team
5. Completion -- updates the BO status to "Fulfilled"

Key concepts within Business Processes:

• Steps are the individual stages of the workflow. Each step can be an approval, review, notification, or action.
• Conditions control whether a step executes. Conditions evaluate field values, security group membership, or custom expressions.
• Routing determines who receives a step. Workday supports role-based routing (e.g., "the requester's manager"), security-group-based routing, and explicit routing to named individuals.
• Parallel and sequential flows allow you to model complex multi-track approvals where some steps happen concurrently.

One of the most powerful aspects of Extend BPs is that they participate in the same approval framework as core Workday processes. This means your custom app's approvals appear in the same inbox, use the same delegation rules, and follow the same escalation policies that employees already know.

Orchestrations

Orchestrations handle the integration and automation layer. Where Business Processes manage human-centric workflows, Orchestrations manage system-centric logic: calling external APIs, transforming data, executing conditional branching, and coordinating multi-step automated sequences.

An Orchestration consists of:

• A trigger -- what kicks off the orchestration (a BP step, a scheduled event, or an API call)
• Integration steps -- HTTP calls to external services with configurable methods, headers, authentication, and payloads
• Data transformation steps -- mapping and reshaping data between systems
• Conditional logic -- branching based on response codes, field values, or computed expressions
• Error handling -- retry policies, fallback paths, and alerting

Here is a practical example. Suppose your equipment request, once approved, needs to create a purchase order in an external procurement system:

Orchestration: Create_External_PO
Trigger: Equipment_Request BP reaches "Fulfillment" step

Step 1: Build Payload
  - Map Equipment_Request fields to external PO schema
  - Convert currency to vendor's expected format

Step 2: Call Procurement API
  - POST https://procurement.example.com/api/v2/purchase-orders
  - Auth: OAuth 2.0 (client credentials)
  - Body: mapped payload from Step 1

Step 3: Handle Response
  - If 201 Created:
      Update Equipment_Request.external_po_id with response.po_number
      Update status to "Fulfilled"
  - If 4xx/5xx:
      Log error details
      Route to IT support queue for manual resolution

Orchestrations are where Workday Extend apps connect to the outside world. Design them defensively: always handle failure cases, implement idempotency where possible, and log enough context to debug issues without exposing sensitive data.

Presentation Model Definitions (PMDs)

Presentation Model Definitions govern the user interface layer. A PMD defines what the user sees and interacts with: pages, fields, layouts, navigation, and interactive behaviors.

PMDs in Workday Extend use a declarative model. Rather than writing HTML or CSS, you define UI components and their bindings to Business Object fields. The platform handles rendering, responsiveness, and accessibility.

Core PMD concepts include:

• Pages -- the top-level UI containers (list views, detail views, dashboards)
• Field bindings -- connecting UI elements to BO fields with read/write behavior
• Layout groups -- organizing fields into logical sections with headers and collapsibility
• Actions -- buttons and links that trigger Business Processes, navigate to other pages, or invoke Orchestrations
• Conditional visibility -- showing or hiding UI elements based on field values, security roles, or application state

A well-designed PMD for the equipment request might include:

• A list page showing all requests with filters for status and date range
• A detail page with sections for request information, approval history, and fulfillment status
• A submission form with field validation and dynamic fields (showing different options based on equipment type)
• A dashboard widget showing pending approvals for managers

Expressions and Scripts

Workday Extend uses different expression systems depending on the component:

Orchestrate Expression Language (OEL) is used within Orchestrations for data transformations, conditional logic, and value creation. OEL functions use namespace prefixes — for example, str:defaultIfEmpty() for null handling, str:length() for string length, date:now() for the current timestamp, and date:plusMonths() for date arithmetic. String concatenation uses the + operator.

PMD Scripting is used within presentation components (PMDs) for conditional visibility, computed values, and page logic. PMD scripts use <% %> tags and have access to page context, field values, and navigation actions. Note: the older Expression Language using ${} syntax was retired in September 2023 and replaced by PMD Scripting.

Business Process conditions are configured declaratively to control whether a step executes, based on field values, security group membership, or other criteria.

These expression systems appear throughout an Extend app:

• BP conditions -- controlling workflow routing and step execution
• PMD scripts -- dynamically adjusting the UI, computing display values
• Orchestration steps -- transforming data between systems, branching on conditions
• Calculated fields -- deriving values from other fields without storing redundant data

Development Workflow

Workday Extend development follows a structured workflow that balances agility with governance.

1. Design in App Builder

App Builder is the browser-based development environment on the Workday Developer Site where you define BOs, BPs, Orchestrations, and PMDs. It offers two modes: Visual Mode provides a form-based experience for straightforward configurations, while Code Mode gives you direct access to the underlying JSON for advanced scenarios. You can also use the Workday Extend Plugin for IntelliJ for local development with full IDE features.

2. Develop Iteratively in Sandbox

All development happens in a sandbox tenant. This is non-negotiable -- you never develop directly in production. Workday provides implementation and sandbox tenants specifically for this purpose.

A typical iteration cycle:

• Define or modify a Business Object
• Create or update the associated Business Process
• Build the PMD for user interaction
• Test the end-to-end flow within the sandbox
• Refine based on testing feedback

3. Test Thoroughly

Testing in Workday Extend requires attention to several dimensions:

• Functional testing -- does the app behave correctly for the happy path?
• Security testing -- do security groups and instance-level permissions behave as expected?
• Edge case testing -- what happens with null values, boundary conditions, or unexpected input?
• Integration testing -- if Orchestrations call external systems, do they handle timeouts, errors, and retries correctly?
• User acceptance testing -- do actual business users find the workflow intuitive?

4. Deploy Through App Hub

Once validated, you save your app to App Hub on the Workday Developer Site, then deploy it to a Development tenant for testing. When ready, you promote the app through the lifecycle — from Development to Implementation, Sandbox, and finally Production — using the Developer Site console. Each promotion step is controlled and auditable.

Common Patterns and Best Practices

Pattern: Request-Approval-Fulfillment

The most common Extend pattern is a three-phase workflow: a user submits a request (creates a BO instance), the request routes through an approval chain (BP), and upon approval an automated action fires (Orchestration). The equipment request example above follows this pattern.

Pattern: External System Sync

When Workday Extend apps need to stay synchronized with external systems, use Orchestrations with scheduled triggers. Poll for changes at a reasonable interval, use timestamps or version markers for incremental sync, and always handle conflicts explicitly.

Pattern: Dashboard Aggregation

Build reporting dashboards by defining calculated BO fields that aggregate data, then bind those to PMD dashboard widgets. This avoids expensive client-side computation and leverages Workday's reporting engine.

Best Practices

• Start with the Business Object model. Get your data model right before building workflows and UI. Changing BOs after they have production data is significantly harder than changing BPs or PMDs.
• Use security groups deliberately. Define custom security groups for your Extend app rather than reusing broad existing groups. This gives you granular control and clearer audit trails.
• Keep Orchestrations focused. Each Orchestration should handle one logical integration task. Chain them through BP steps rather than building monolithic orchestrations with dozens of steps.
• Version your expressions. Scripts and expressions embedded in BPs and PMDs can be difficult to track over time. Maintain documentation of complex expressions and their business logic rationale.
• Design for the mobile experience. Workday's mobile app renders Extend apps, but the screen real estate is limited. Test your PMD layouts on mobile and use conditional visibility to simplify the mobile view where appropriate.
• Monitor Orchestration failures. Set up alerting for failed Orchestration steps. Silent failures in integrations can lead to data drift between systems that is painful to reconcile later.
• Leverage tools that understand the platform. AI-assisted development tools like Knokit that are purpose-built for the Workday ecosystem can accelerate the development cycle, particularly when navigating the relationships between BOs, BPs, and Orchestrations.

When to Use Workday Extend vs. External Integrations

Workday Extend is the right choice when:

• The application's primary users already work in Workday daily
• The data model is closely tied to core Workday objects (workers, orgs, cost centers)
• You need to participate in Workday's approval and security framework
• You want a single-pane-of-glass experience without context switching

An external integration or standalone app may be better when:

• The application serves users who do not have Workday access
• The UI requirements exceed what PMDs can express (complex visualizations, real-time collaboration)
• The data volume or processing requirements exceed what the Extend platform supports
• You need offline or disconnected functionality

Moving Forward

Workday Extend development rewards careful upfront design and iterative refinement. The platform's strength lies in its tight integration with the Workday ecosystem -- your custom apps inherit enterprise-grade security, familiar UX patterns, and a robust deployment pipeline.

Start with a clear understanding of your Business Objects, map your workflows through Business Processes, automate with Orchestrations, and build intuitive interfaces with PMDs. The concepts are straightforward; the craft is in the details of how you compose them.

The Workday Extend ecosystem continues to mature, with each release expanding what is possible on the platform. Investing in fluency with these core building blocks positions your team to deliver high-impact custom applications that feel native to the Workday experience.