Building a Travel Request App with Workday Extend

Workday Extend gives organizations the ability to build custom applications that live natively inside the Workday platform. Rather than stitching together external tools and dealing with integration headaches, you can create purpose-built apps that leverage Workday's security model, data layer, and user experience framework out of the box.

In this tutorial, we will build a Travel Request application from scratch. Employees will be able to submit travel requests with destination, dates, estimated cost, and a business justification. Managers will approve or deny them through a standard Business Process. The app will enforce validation rules, run an orchestration for post-approval processing, and present everything through a clean Presentation Model Definition (PMD).

By the end, you will have a working understanding of the five core Extend building blocks: Business Objects, Business Processes, validation rules, orchestrations, and PMDs.

Prerequisites

Before you begin, make sure you have:

• Access to a Workday Extend sandbox tenant
• The Workday Extend developer role assigned to your account
• Familiarity with App Builder on the Workday Developer Site
• A basic understanding of Workday's security and domain model

Step 1: Design the Data Model with Business Objects

Every Extend app starts with Business Objects (BOs). These are custom data entities stored in the Workday data layer. Think of them as your database tables, except they automatically inherit Workday's multi-tenancy, audit logging, and security infrastructure.

For our travel request app, we need one primary Business Object:

Creating the TravelRequest Business Object

Open App Builder on the Workday Developer Site, navigate to your app project, and create a new Business Object called TravelRequest. Define the following fields:

Field Name	Type	Description
employee	SINGLE_INSTANCE	Reference to WORKER — the worker submitting the request
destination	TEXT	Travel destination city/country
departureDate	DATE	Start date of travel
returnDate	DATE	End date of travel
estimatedCost	CURRENCY	Estimated total cost in USD
businessJustification	RICH_TEXT	Reason for travel
status	TEXT	Pending, Approved, Denied

In App Builder's Code Mode, the Business Object definition is a JSON file:

{
  "id": 1,
  "name": "TravelRequest",
  "label": "Travel Request",
  "defaultSecurityDomains": [
    "ManageTravelRequests"
  ],
  "defaultCollection": {
    "name": "travelRequests",
    "label": "All Travel Requests"
  },
  "fields": [
    {
      "id": 1,
      "name": "destination",
      "type": "TEXT",
      "label": "Destination",
      "useForDisplay": true,
      "description": "Travel destination city or country"
    },
    {
      "id": 2,
      "name": "departureDate",
      "type": "DATE",
      "label": "Departure Date",
      "precision": "DAY",
      "description": "Start date of travel"
    },
    {
      "id": 3,
      "name": "returnDate",
      "type": "DATE",
      "label": "Return Date",
      "precision": "DAY",
      "description": "End date of travel"
    },
    {
      "id": 4,
      "name": "estimatedCost",
      "type": "CURRENCY",
      "label": "Estimated Cost",
      "description": "Estimated total cost in USD"
    },
    {
      "id": 5,
      "name": "businessJustification",
      "type": "TEXT",
      "label": "Business Justification",
      "description": "Reason for travel"
    },
    {
      "id": 6,
      "name": "employee",
      "type": "SINGLE_INSTANCE",
      "label": "Employee",
      "target": "WORKER",
      "secureByTarget": true,
      "description": "The worker submitting the request"
    }
  ]
}

A few things to note:

• The employee field uses a SINGLE_INSTANCE relationship targeting WORKER, which links directly to Workday's HCM data. This means you do not need to duplicate employee information. The secureByTarget flag ensures access respects the worker's existing security context.
• Business Object names must be UpperCamelCase, and field names must be lowerCamelCase.
• Each field and the Business Object itself require a numeric id (1-32767) that must be unique within the object.

Optional: TravelExpenseLine Business Object

For a more robust app, you could create a child Business Object called TravelExpenseLine to break down costs (flights, hotel, meals, etc.) and link it back to TravelRequest via a reference field. We will keep things simple here, but the pattern is the same.

Step 2: Define the Business Process

Business Processes (BPs) are the workflow engine of Workday. They define who needs to approve, review, or be notified when something happens. For our travel request, we want a straightforward approval flow.

Creating the Travel Request Approval BP

Create a new Business Process called TravelRequestApproval with the following steps:

1. Initiation — The employee submits the travel request.
2. Manager Approval — The request routes to the employee's direct manager for approval.
3. Finance Review (conditional) — If estimatedCost exceeds $5,000, route to the Finance team for secondary approval.
4. Completion — The request is marked as Approved and downstream processing begins.

A Business Process definition in Extend is a JSON file that specifies the target Business Object, an approval step (with actions like APPROVE, DENY, and optionally SEND_BACK), and action steps for additional workflow logic. Each BP requires a targetBusinessObject, security domains, and page routes that link to PMD pages for each step's UI.

Key design decisions here:

• Conditional routing keeps the process lightweight for low-cost trips. A $200 conference registration should not require the same scrutiny as a $12,000 international trip.
• Escalation ensures requests do not sit indefinitely in an absent manager's queue. After 5 days, the system escalates according to your tenant's escalation rules.
• Delegation support lets managers delegate approvals when they are on vacation—something Workday handles natively.

Denial Handling

When a request is denied at any step, the Business Process framework handles it through the DENY action configured in the approval step. You can add action steps that execute on denial to update the status field to "Denied" and notify the employee. Workday's BP framework routes denial notifications through the same inbox and notification system used by core processes.

Step 3: Add Validation Rules

Validation rules catch bad data before it enters the system. They run when the Business Object is created or updated. In Workday Extend, validations can be implemented through derived fields, orchestration logic, or conditions on Business Process steps.

Rule 1: Return Date Must Be After Departure Date

Ensure the return date comes after the departure date. This can be expressed as a condition:

returnDate > departureDate

Rule 2: Estimated Cost Must Be Positive

estimatedCost > 0

Rule 3: Business Justification Minimum Length

Using the Orchestrate Expression Language (OEL) string functions:

str:length(businessJustification) >= 20

Rule 4: No Travel Requests More Than 6 Months in Advance

departureDate < date:plusMonths(date:now(), 6)

Note that the Orchestrate Expression Language (OEL) uses colon-namespaced functions — for example, date:now() for the current timestamp, date:plusMonths() for date arithmetic, and str:length() for string length.

These validation rules give you server-side enforcement that cannot be bypassed by a clever user editing form submissions. They also provide clear, actionable error messages so employees know exactly what to fix.

Step 4: Build the Orchestration

Orchestrations let you automate multi-step processes that fire after a Business Process completes. They are Workday Extend's answer to backend automation—think of them as serverless workflows.

For our travel request, we want an orchestration that runs after approval:

Travel_Request_PostApproval Orchestration

This orchestration will:

1. Use a SendWorkdayApiRequest node to interact with Workday's REST APIs (for example, creating a notification)
2. Use a SendHttpRequest node to call an external travel booking API (optional)
3. Use CreateValues nodes to prepare and transform data between steps

Orchestrations in Workday Extend are authored in App Builder as .orchestration JSON files. They define a flow with typed nodes, each connected by transitions. The most common node types from Workday's sample apps include:

• CreateValues — create or transform data variables (the most frequently used node type)
• SendWorkdayApiRequest — call Workday's own REST APIs
• SendHttpRequest — call external HTTP endpoints
• BranchOnConditions — route the flow based on conditions
• Log — write diagnostic information for troubleshooting
• Loop — iterate over collections of data

An orchestration can be triggered by a Business Process step, an integration framework event, or called as a subflow from another orchestration.

A few important patterns:

• Error handling is critical for external API calls. Use BranchOnConditions after HTTP steps to check response codes and route to error-handling logic if needed.
• Subflows (via CallSubflow nodes) let you compose reusable orchestration pieces. Extract common patterns — like "call external API with retry" — into subflows.
• Each orchestration flow has a defined type: synchronous (FlowSync), asynchronous, or Business Process-triggered.

Step 5: Create the Presentation Model Definition

The Presentation Model Definition (PMD) is the UI layer of your Extend app. It defines what users see and interact with—forms, lists, detail views, and dashboards. PMDs use a declarative model that Workday renders natively, so your app looks and feels like a built-in Workday feature.

The Submission Form

PMDs are JSON files that define the page layout using a presentation schema with nested tags. For the submission form, you would define a page with field sets, input fields bound to your Business Object fields, and submit actions. PMDs support tags for text inputs, date pickers, currency fields, rich text editors, and more.

You can build this in App Builder's Visual Mode — which is the recommended approach for page design. Visual Mode lets you add tags, configure field bindings, and arrange layout groups through a graphical interface. App Builder generates the PMD JSON in the background.

Key elements for the submission form:

• Field sets group related fields (trip details, cost and justification) into visual sections
• Field bindings connect each input to the corresponding Business Object field (destination, departureDate, returnDate, estimatedCost, businessJustification)
• Submit actions tie the form submission to the Business Process

The Dashboard View

Create a second PMD page that shows employees their submitted requests. This page would use:

• A grid or list tag to display TravelRequest instances
• Column definitions showing destination, dates, cost, and status
• Navigation actions linking to the submission form for new requests
• Conditional formatting on the status field to visually distinguish Pending, Approved, and Denied states using Workday's standard visual conventions

Putting It All Together

Here is the full lifecycle of a travel request in our app:

1. Employee opens the Travel Request app from their Workday home page and fills out the submission form (PMD).
2. Validation rules check the data: dates make sense, cost is positive, justification is detailed enough.
3. The Business Process kicks off, routing the request to the employee's manager.
4. If the cost exceeds $5,000, the Finance team gets a secondary approval step.
5. On approval, the orchestration fires: the request details are retrieved, an optional external booking API is called, and the status is updated.
6. The employee sees their request status update to "Approved" on the dashboard.

Common Pitfalls and Tips

• Security domains: Make sure your Business Object is assigned to the correct security domain. If users cannot see the app, this is almost always the reason.
• Testing Business Processes: Use the "Test Business Process" feature in your sandbox before deploying. It simulates the full approval chain without sending real notifications.
• Orchestration timeouts: External API steps have a default timeout. Configure retries and fallback behavior for any integration step that calls outside Workday.
• Field indexing: If your dashboard will be used by hundreds of employees, add indexes to the employee and status fields on your Business Object to keep query performance snappy.
• Version management: Extend apps support versioning. Use App Hub to promote your app through the lifecycle (Dev, Sandbox, Production). Always increment your version before promoting to production so you can roll back if something goes wrong.

Next Steps

Once you have the basic travel request app running, there are several natural extensions:

• Expense reconciliation: After the trip, prompt the employee to submit actual expenses and compare them against the estimate.
• Policy enforcement: Add validation rules that enforce per-diem limits by destination using a lookup table Business Object.
• Analytics: Build a reporting PMD that shows travel spend by department, average approval time, and request volume trends.
• Mobile optimization: Workday Extend apps work on mobile by default, but you can fine-tune the PMD layout for smaller screens.

Building on Workday Extend means your travel app benefits from the same infrastructure that runs core HCM, Financials, and Planning—single security model, unified audit trail, and zero integration tax. Tools like Knokit can help your team navigate the nuances of Extend development faster, but the fundamentals covered here will serve you well regardless of how you approach the build.

The patterns in this tutorial—Business Objects for data, Business Processes for workflow, validation rules for integrity, orchestrations for automation, and PMDs for presentation—apply to virtually any custom Workday Extend application. Master them once, and you can build anything from expense approvals to asset tracking to employee onboarding workflows.