The Extend paradox

Workday Extend exists to let organizations build custom applications that run natively inside Workday. Custom pages, custom business objects, orchestrations, security domains, WQL-powered data views — it's a full application platform embedded in the system that already runs your HR, finance, and payroll.

On paper, this should be transformative. The people who understand the business problems best — functional consultants and Workday admins — should be the ones building the solutions. In practice, they can't.

Building an Extend app today requires:

  • Writing JSON metadata files (AMD, PMD, SMD) with precise syntax and nesting rules
  • Understanding WQL — its data sources, field names, filters, and pagination
  • Managing a local project directory with a specific file structure
  • Running command-line validation tools configured with developer credentials
  • Reading and interpreting Workday's validation error messages
  • Understanding the publish/deploy lifecycle across environments
  • Navigating the Workday Developer Site for account management and promotion
  • Debugging orchestration flows using Builder graphs, runtime logs, and Insights data

Every one of these steps requires developer skills.

The tooling gap, not the knowledge gap

A senior Workday functional consultant already has most of the knowledge needed to design an Extend app. They understand business processes, security, data models, reporting, and user workflows.

What they don't have is the ability to express that knowledge in JSON metadata, WQL syntax, and command-line tooling. The gap isn't conceptual — it's mechanical. This is exactly the kind of gap that AI is built to close.

What accessible Extend looks like

Making Extend accessible to functional consultants doesn't mean dumbing it down. It means removing the mechanical barriers while preserving the platform's full power.

Natural language in, real Extend app out

The consultant describes what they need in plain language. The AI agent translates that into valid PMD widgets, WQL queries, business object references, and security configurations — all structurally correct Extend source that Workday will accept. The consultant never sees JSON, never types a WQL query, never manages a file directory.

Validation that speaks human

When Workday's validation returns an error, an accessible Extend tool translates it into plain language and fixes it automatically — keeping the consultant in the conversation, not in a debugging session.

The full lifecycle in one place

Today, building an Extend app requires moving between a code editor, a terminal, the Developer Site, a Workday tenant browser session, and a chat window. Each context switch costs time. An accessible Extend tool puts nearly the whole lifecycle — design, build, validate, publish, deploy, promote toward your working tenant, test — into a single conversation. The first install in a tenant and the move to Production stay your own steps in the Developer Site.

Testing in the real tenant

An accessible Extend tool connects directly to the consultant's Workday tenant, opens a browser already signed in, navigates to the deployed app, and reports what it finds — with screenshots and evidence. If something doesn't look right, the consultant says so in the same conversation, and the tool fixes, re-deploys, and re-tests.

Who benefits

Functional consultants

They go from "I need to write a requirements document and hand it to a developer" to "I can describe what I need and get a working app." The app isn't a prototype — it's a real, validated, deployed Extend app running in their tenant.

Extend developers

Developers gain leverage: the mechanical work of scaffolding apps, writing boilerplate, and debugging validation errors is automated. They can focus on the genuinely complex parts — intricate orchestration flows, performance optimization, custom security models — while the AI handles routine construction.

Workday customers

When the person closest to the business problem can build the solution, the handoff chain shrinks. Projects that took weeks can start producing working apps in hours. The bottleneck shifts from "we don't have enough Extend developers" to "we need to review and approve the apps our consultants are building." That's a much better problem to have.

What kiweely does

kiweely is built specifically to close this gap. It's a desktop application — macOS and Windows — that puts a non-technical Workday consultant in direct, conversational control of the full Extend lifecycle:

  • Describe an app in plain language and watch the AI agent design and build it
  • Validate against Workday's actual platform — not a local approximation
  • Publish and deploy with consent — seeing exactly which tenant and version
  • Promote through environments — with mandatory approvals for sensitive changes
  • Test in a real browser already signed into your tenant
  • Iterate in one conversation — every change, validation, deployment, and test
  • Access deep Workday knowledge — bundled documentation and live integration with Workday Community and the Developer Forum
  • Manage multiple clients — with credential isolation and per-conversation scoping

The bigger picture

The question isn't whether AI can write Workday Extend code. It clearly can. The question is whether the tooling around that capability is designed for the people who actually need it.

The shift that matters isn't "AI writes code." It's "a non-technical person can go from a business need to a deployed, tested Workday Extend app — and understand every step of how they got there." Full power, mechanical barriers removed.

The best platform features are the ones that get used. When Extend becomes accessible to the people who understand the business, more apps get built — and the apps that get built are closer to what the business actually needs.