The old way

Building a Workday Extend app today typically involves a chain of handoffs: a business stakeholder describes a need, a functional consultant translates it into requirements, a developer designs the app architecture, writes the metadata, validates it against Workday, debugs failures, publishes, deploys, tests, and iterates. Each handoff introduces delay, misunderstanding, and cost.

For consultants who aren't developers, the process stops at the requirements document. Everything after that is someone else's job — and someone else's timeline. Why Workday Extend doesn't need to be a developer-only tool makes the longer case.

The new way: a real conversation

Here's what building an Extend app looks like in kiweely. The scenario is realistic: a consultant needs an app that tracks equipment certifications for workers, with expiration alerts and a manager dashboard.

Step 1: say what you need

You open kiweely, start a new conversation, and type:

I need a Workday Extend app that tracks equipment certifications for workers. Each worker can have multiple certifications with expiration dates. Managers should see a dashboard showing their team's certification status, with alerts for certifications expiring in the next 30 days.

That's it. No requirements document. No technical specification. No file system setup.

Step 2: the agent designs the app

The AI agent — drawing on deep Workday Extend knowledge — responds with a proposed design: business objects for certification records, a WQL data source joining workers to their certifications, pages for worker self-service and a manager dashboard, security domains controlling access, and an orchestration for scheduled expiration notifications.

The agent explains each decision in plain language. You might adjust: "Actually, let's add a page where HR can bulk-upload certifications from a spreadsheet." The agent incorporates the change and explains what it revised.

Step 3: the agent builds it

Once you're aligned on the design, the agent creates the app. kiweely asks you to confirm the app name — a simple approval in the chat — then creates it in your real Workday Extend developer account.

The agent then writes every component: the AMD, PMD, SMD, business object definitions, WQL queries, widget configurations, scripts, and orchestrations. These are real Extend source files, written to your project folder on disk. You can see them anytime in the Files panel — but you never need to touch them.

Step 4: validate against Workday

Here's where kiweely diverges most sharply from "AI that generates code." The agent validates the app against Workday's actual remote validation service — not a local check, not a guess, not "this should work."

If validation passes, the agent tells you. If it doesn't, you see the errors in plain language: "Workday found two issues: the certification date field needs a display label, and the WQL query references a data source field that doesn't exist in your tenant. I'll fix both and re-validate."

The agent fixes the errors, resubmits to Workday, and continues until validation is clean. You don't copy error messages, paste them into a chat, or interpret cryptic validation codes. If a page still fails after it deploys, what's actually failing behind a Workday Extend page error explains where the fix belongs.

Step 5: publish and deploy

With validation passing, kiweely asks for your explicit consent — a clear approval in the chat showing exactly what will happen:

Publish Equipment Certification Tracker to your Development tenant (acme-dev1)?

You approve. The agent validates, uploads, builds, and deploys the app to your real Development tenant. You see the result — confirmed by Workday, not claimed by the AI.

Step 6: promote through environments

The agent can promote the app through Workday's environment pipeline — Development to Implementation, Implementation to Sandbox — with your consent at each step. For sensitive changes involving model components (business objects, tasks, security domains), kiweely raises a separate, mandatory approval showing exactly what changed and what the consequences are. This approval can't be skipped.

Production deployments stay where they belong: in the user's own hands, through the Workday Developer Site.

Step 7: test in a real browser

The agent opens a real browser already signed into your Workday tenant — using your existing authenticated session — to test the deployed app visually. No manual login, no separate browser tab.

The browser is visible and stoppable. The agent navigates to the app, checks that pages render correctly, verifies that data appears where expected, and takes screenshots as evidence. If something doesn't look right, it says so — with a screenshot — and offers to fix it. For the full method, including roles, saved-data readback and failure paths, see what a Workday Extend app test has to prove.

Step 8: iterate

You look at the screenshot and say: "The expiration column should show the number of days remaining, not just the date. And can we make the alert red instead of yellow when it's under 7 days?"

The agent makes the changes, re-validates, re-publishes, re-deploys, and re-tests — all in the same conversation, with full memory of every decision you've made.

What happened behind the scenes

From the user's perspective, this was a conversation. From a technical perspective, kiweely created a real Workday Extend app, generated valid source files, submitted to Workday's remote validation multiple times, diagnosed and fixed validation errors, published and deployed to a real tenant, promoted through environments with consent, opened an authenticated browser for visual QA, captured evidence at every step, maintained a continuous conversation thread, and automatically versioned every state of the app.

The user never saw a file path, a validation code, an HTTP status, or a stack trace. They saw plain language throughout.

Why this matters

The gap in Workday Extend adoption isn't about the platform's capability — Extend is powerful. The gap is about who can access that power.

Today, building an Extend app requires a developer who understands Extend's JSON metadata files (AMD, PMD, SMD), WQL syntax, orchestration graphs, Workday's validation system, and the publish/deploy lifecycle. That developer is expensive, scarce, and usually not the person who understands the business need.

kiweely closes the gap. The person who understands the business need describes what they want. The AI agent does the rest, with the user's authority and consent at every step that matters. It's not magic. It's integration: deep Workday knowledge, real tenant connectivity, honest verification, and a conversation that never forgets what you said.

The best app is the one that gets built. When building it takes one conversation instead of one project plan, more apps get built — and the people closest to the problem are the ones building them.