Workday Extend: Code Mode vs Visual Mode in App Builder

When you start building a Workday Extend application, one of the first decisions you face is how to work inside App Builder. Workday's App Builder is the browser-based IDE on the Workday Developer Site, and it provides two distinct modes for authoring app components: Code Mode and Visual Mode. You can switch between them at any time using a toggle in the upper right corner of the interface.
This is not a cosmetic preference. The mode you choose affects your development speed, your ability to handle complex configurations, and how accessible the work is to different members of your team. This guide breaks down both modes, covers the platform constraints you need to keep in mind, and provides practical guidance for choosing the right approach.
Understanding App Builder
App Builder is where you create and edit every component of a Workday Extend application. An Extend app is composed of several component types:
- Business Objects — custom data structures with typed fields (
.businessobjectfiles) - Orchestrations — integration and automation flows with sync and async execution models
- Presentation components (PMD) — the UI layer that end users interact with
- Business Processes — approval and routing workflows
- Tasks and Reports — entry points surfaced within the Workday tenant
- Security Domains — access control definitions for your app's data
- Attachments — file handling configurations
Each of these components is ultimately represented as JSON, and App Builder gives you two ways to author that JSON: write it directly, or let App Builder generate it from form inputs.
Code Mode: Direct JSON Editing
In Code Mode, you work with the raw JSON that defines each component. App Builder provides a text editor where you type or paste JSON, and the platform validates it against the component schema as you work.
Code Mode is available for every app component type except orchestrations. Orchestrations must be authored using the visual orchestration editor.
Here is a Business Object definition for an equipment request tracker, written in the format you would enter in Code Mode:
{
"id": 1,
"name": "EquipmentRequest",
"label": "Equipment Request",
"defaultSecurityDomains": ["EquipmentManagement"],
"defaultCollection": {
"name": "equipmentRequests",
"label": "Equipment Requests"
},
"fields": [
{
"id": 1,
"name": "equipmentType",
"label": "Equipment Type",
"type": "TEXT",
"useForDisplay": true
},
{
"id": 2,
"name": "requestDate",
"label": "Request Date",
"type": "DATE",
"precision": "DAY"
},
{
"id": 3,
"name": "estimatedCost",
"label": "Estimated Cost",
"type": "CURRENCY"
},
{
"id": 4,
"name": "justification",
"label": "Justification",
"type": "RICH_TEXT",
"description": "Explain why this equipment is needed"
},
{
"id": 5,
"name": "requestedBy",
"label": "Requested By",
"type": "SINGLE_INSTANCE",
"target": "WORKER",
"secureByTarget": true
},
{
"id": 6,
"name": "approvers",
"label": "Approvers",
"type": "MULTI_INSTANCE",
"target": "WORKER"
},
{
"id": 7,
"name": "approved",
"label": "Approved",
"type": "BOOLEAN"
},
{
"id": 8,
"name": "quantity",
"label": "Quantity",
"type": "INTEGER"
}
]
}
A few things to note about this format. The type field on each entry determines the data type. Valid types include TEXT, RICH_TEXT, DECIMAL, CURRENCY, INTEGER, BOOLEAN, DATE, SINGLE_INSTANCE (a reference to another Business Object or a Workday-delivered object like WORKER), and MULTI_INSTANCE (a multi-valued reference). Fields have properties like isReferenceId, useForDisplay, enableIndex, and secureByTarget, but there is no required attribute at the Business Object level. Required-ness is enforced at the presentation layer in the PMD definition, not in the Business Object schema itself.
When Code Mode works best
- Complex configurations. When you need precise control over field ordering, security domain assignments, or advanced attribute settings, Code Mode lets you see and edit everything in one place.
- Copy-paste workflows. Building multiple Business Objects with similar field patterns is dramatically faster when you can duplicate and modify JSON rather than filling out forms repeatedly.
- Debugging. When something is not working, inspecting the raw JSON often reveals the issue faster than clicking through form sections.
- Experienced developers. If you are fluent in JSON and understand Extend's component schemas, Code Mode is the faster path for day-to-day development.
Visual Mode: Form-Based Authoring
Visual Mode presents app components through an interactive form interface. Instead of writing JSON, you fill in fields, select options from dropdowns, and toggle attribute switches. App Builder generates the JSON behind the scenes.
Visual Mode is available for the following model components: Attachment, Business Object, Business Process, Report, Security Domain, and Task. For presentation components, Visual Mode is also known as Page Builder and provides a point-and-click interface for constructing PMD pages with layout groups, fields, and interactive elements.
To add a field to a Business Object in Visual Mode, you click "Add Field," enter the name and label, select the type from a dropdown, and configure additional attributes through checkboxes and toggles. The form guides you through every available option, which means you do not need to memorize the schema to build a valid component.
When Visual Mode works best
- Learning the platform. Visual Mode shows you what options exist for each component type. It is an effective way to discover the schema without reading documentation.
- Page design. Building PMD pages with nested layout tags, field bindings, and interactive elements is significantly easier in Page Builder than managing nested JSON by hand.
- Quick prototyping. When you want to sketch out a component structure and validate your approach, Visual Mode reduces the friction of getting something functional.
- Non-developer contributors. Business analysts and functional consultants who understand the Workday domain but are not comfortable editing JSON can author components directly in Visual Mode.
Head-to-Head Comparison
| Aspect | Code Mode | Visual Mode |
|---|---|---|
| Input method | JSON text editor | Forms, dropdowns, toggles |
| Availability | All components except orchestrations | Model components + Page Builder for PMDs |
| Learning curve | Steeper — requires JSON fluency | Gentler — guided by the UI |
| Speed (experienced) | Faster for bulk edits and repetitive patterns | Slower for repetitive tasks |
| Speed (new developers) | Slower — must know the schema | Faster — schema is discoverable |
| PMD/page building | Tedious for complex nested layouts | Significantly easier via Page Builder |
| Copy-paste | Easy — duplicate and modify JSON | Not well supported |
| Debugging | See everything at once | Need to click through sections |
Platform Limits to Keep in Mind
Regardless of which mode you use, Workday enforces constraints on Extend app composition and execution. These limits are the same in both modes:
App composition limits:
- Maximum 30 Business Objects per app
- Maximum 5 Business Processes per app
- Maximum 40 fields per Business Object
- Maximum 10 relationship fields (SINGLE_INSTANCE or MULTI_INSTANCE) per Business Object
- Maximum 75 PMDs per app
Orchestration timeout limits:
- Synchronous from PMD: 25 seconds
- Synchronous: 5 minutes
- Asynchronous: 48 hours
- Individual process step (production): 60 minutes
- Individual process step (non-production): 45 minutes
These limits shape how you architect your app. If you are approaching 30 Business Objects, you may need to consolidate data models. If an orchestration triggered from a page must complete within 25 seconds, that constrains how much processing you can do synchronously.
Working with Expressions
When building orchestrations and presentation logic, you will use the Orchestrate Expression Language (OEL). OEL provides namespaced functions for common operations:
- Date functions:
date:now(),date:plusDays(),date:plusMonths() - String functions:
str:isEmpty(),str:length() - List functions:
list.size(),list.filter() - Conditional logic: ternary expressions like
condition ? trueValue : falseValue
OEL expressions appear in both Code Mode (as string values in JSON) and Visual Mode (as entries in expression fields). Understanding OEL is essential regardless of which authoring mode you prefer.
Deployment: App Hub Lifecycle
No matter which mode you use to author your app, the deployment path follows the same App Hub lifecycle:
- Development — author and test in your dev tenant
- Implementation — configure and validate in an implementation environment
- Sandbox — final testing in a production-like environment
- Production — live deployment
App Hub on the Workday Developer Site manages versioning and lifecycle promotion. You promote your app through each stage from the Developer Site console.
A Practical Workflow: Combine Both Modes
Most productive Extend developers use both modes in combination:
-
Start new components in Visual Mode. Let the form guide the initial structure, especially for Business Objects and pages. This ensures you do not miss available attributes.
-
Switch to Code Mode for refinement. Once the structure is in place, drop into Code Mode to fine-tune configurations, replicate field patterns, or adjust attributes that are faster to edit as JSON.
-
Use Page Builder for PMDs. Presentation components with nested layout groups and field bindings are almost always easier to build in Visual Mode's Page Builder.
-
Use Code Mode for bulk operations. When adding similar fields across multiple Business Objects or replicating configuration patterns, JSON editing is dramatically faster.
-
Use the orchestration editor for orchestrations. Since Code Mode is not available for orchestrations, the visual editor is your only option — but it is well-designed for building complex flows with steps, conditions, and integrations.
The toggle between modes is instant and non-destructive. Changes made in one mode are immediately reflected in the other.
Making the Choice
If your team is new to Extend, start in Visual Mode. It teaches the component model faster than any documentation can. As your team builds familiarity with the JSON schemas, shift to Code Mode for efficiency on components that support it.
If your team already has Extend experience, default to Code Mode for Business Objects, Security Domains, and other model components. Use Page Builder for presentation work. And remember that orchestrations are visual-only.
Tools like Knokit can further accelerate your Extend development by providing AI-powered guidance on component design, expression syntax, and platform constraints — but the foundation is understanding how to use App Builder's two modes effectively.
Either way, the underlying format is the same JSON. The choice is about which interface makes you most productive, not about different capabilities or trade-offs in functionality.