From Business Brief to Tested Workday Extend App: Why Zero Validation Errors Is Not Proof

Passing Workday Extend validation in App Builder or the Workday Developer CLI (wdcli) proves that your application metadata (AMD), page metadata (PMD), and static bindings are syntactically well-formed, but it does not prove that the application works for the people who will use it. A deployed Extend app with zero validation errors can still fail on its first click in the tenant when a regular employee lacks domain security on a WQL data source, a manager's constrained security group cannot read a Custom Business Object (CBO) instance, or an orchestration writes an incomplete status back to the record.

With the arrival of AI coding tools and Workday's Developer CLI, generating the source files for a Workday Extend app has never been faster. You can describe a multi-page request app in plain English, watch an assistant write out a dozen .pmd and .script files, run validation, see 0 errors, and deploy the build to your Development tenant in minutes.

It is tempting to stop there and call the app finished.

Then a real user opens the app in Workday. The home page grid spins and throws a 403 Forbidden or returns an empty table. The submit button fires, the confirmation banner appears, and nothing ever lands in the manager's inbox. Or the manager returns the request with a comment, and the employee's resubmission form overwrites the original request date with a null value.

Every one of those failures happened in an app with zero validation errors. Here is why static validation is only the starting line in Workday Extend—and what real behavioral testing requires.

What Static Validation Checks vs. What Runtime Demands

Workday's remote validator is essential: it verifies that your JSON structure conforms to the Extend schema, that widget types exist, that page endpoints reference declared AMD services, and that your PMD script expressions parse cleanly.

What the validator cannot know is how your app behaves when it meets your tenant's live data, security policies, and business processes.

The Four Failures That Only Show Up in the Browser

When you test a newly deployed Extend app as the real personas who will use it, four classes of bugs surface that static validation never sees.

1. The Admin-Illusion Security Trap

Developers almost always preview and test their apps while signed in as a powerful administrative or implementer account (such as lmcneil or wd-implementer in a personal developer tenant, or an unconstrained developer role in a client's Development tenant). Under that account, every WQL query and every CBO endpoint succeeds.

The moment you run Start Proxy as an ordinary employee (Employee As Self), two things break:

• Missing WQL Field Permissions: Your PMD onLoad endpoint runs a WQL query against workers that includes a field—such as a manager's organizational attribute or a job profile attribute—that Employee As Self does not have Get access to on the underlying security domain. The entire page load fails.
• Over-Permissive List Queries: Conversely, if your "My Requests" page fetches records from a Custom Business Object without filtering by the signed-in worker's workdayID (or enforcing instance-level security), Employee A opens their dashboard and sees Employee B's confidential remote-work or tuition request.

2. Constrained Manager Visibility Gaps

Most Extend apps involve a manager step: approving a new-hire equipment request, reviewing a remote work arrangement, or viewing peer recognitions for direct reports.

A manager holds a role-based constrained security group (Manager), scoped strictly to their Supervisory Organization. If your app's "Team Requests" page resolves the team list by querying a relationship or CBO field that is not linked to the worker's current supervisory hierarchy, the manager either sees an empty queue or gets blocked when opening a direct report's request detail page. You only catch this by proxying as the actual manager of the employee who submitted the test request—and also proxying as a second manager from a different department to prove they cannot see or approve the first manager's request.

3. The "Return for Revision" State Machine Breakdown

In a demo, people only test the happy path: Employee submits -> Manager approves -> Status reads Approved.

In a real enterprise, managers send requests back. When a manager clicks Return or Send Back with a comment asking the employee to change a start date or pick a standard laptop model, the app's state machine is put to the test:

• Does the returned request appear clearly in the employee's queue with the manager's exact comment displayed beside the form?
• When the employee edits one field and resubmits, does the PATCH payload preserve all the other fields (such as software selections or building access notes) that they did not touch?
• Does the resubmitted request route back to the manager and clear the old rejection state?

Without stepping through the full submit -> return -> edit -> resubmit -> approve loop in the browser across both personas, state-transition bugs go straight to UAT.

4. Asynchronous Orchestration and Fulfilment Drift

When an Extend page triggers a Workday Business Process or an Orchestration for Integration, the HTTP call that starts the flow returns 200 OK or 201 Created in milliseconds. The page shows a green confirmation banner.

Meanwhile, the orchestration runs asynchronously in the background. Five seconds later, a downstream step in the orchestration fails because a date format was rejected by a Workday web service, an empty optional field wasn't guarded against null, or a loop hit a pagination boundary. If nobody checks the saved outcome in the UI and inspects the app's runtime logs and Orchestrate run history, the developer thinks the submission succeeded while the record sits half-written.

What Real End-to-End Extend Testing Looks Like

Proving that an Extend app actually works requires a disciplined end-to-end testing loop in the live tenant:

1. Create and Submit as the Initiator: Use Start Proxy to sign in as a real employee. Fill out the form, test required-field validations, submit the request, and reopen "My Requests" to confirm every field was saved and the initial status is accurate.
2. Verify Negative Access: Proxy as a peer employee or an unrelated manager and confirm they cannot view or act on the request.
3. Review, Return, and Approve as the Manager: Proxy as the initiator's actual manager. Test returning the request with a comment, proxy back to the employee to correct and resubmit, and then proxy as the manager to approve it.
4. Complete Downstream Fulfilment or Admin Views: Proxy as the functional owner (IT, HR Partner, or Compliance) to update item progress, filter company-wide queues, and verify aggregate totals.
5. Confirm Final Readback and Logs: Reopen the completed record as the employee and manager to verify the final state, and check the app's logs to confirm zero silent runtime errors occurred.

How kiweely Builds, Tests as Real People, and Fixes What Fails

In kiweely, building a Workday Extend app does not stop when Workday's validator says zero errors.

When you describe the app you need, kiweely designs the data model, pages, WQL queries, and orchestrations, has Workday validate every version, and asks for your approval before deploying to your Development tenant. Once deployed, kiweely opens a visible browser window on this computer, runs Start Proxy as the real personas who will use the app—the employee, their manager, IT, or HR—and clicks through the live app in Workday.

When a proxy test uncovers a permission error, a blank grid, a broken filter, or a state bug on a returned request, kiweely sees the failure on the page, reads Workday's application logs and orchestration run history, fixes the root cause in the app, deploys the updated version, and runs the browser test again until every check passes. Every test case, run, and result is recorded in the project's Testing panel beside your conversation. Watch kiweely build and test full Extend apps on camera on What it does.

Kiweely Personal is free for your Workday personal developer account and its tenant. Any other tenant needs a Personal licence, $99 a month, or a seat in your firm.