Workday Developer Agent, generally available since Workday Rising on October 13, 2026, turns a plain-language request into custom agents, Workday Extend apps and orchestrations. Workday says it brings Workday's own tools, APIs and patterns into the build, which is exactly what general coding assistants lack.
Faster building moves the bottleneck to review. Whoever is accountable for the tenant still needs to check the result before it is deployed. Use this checklist on every Developer Agent build, from a small page to a custom agent.
1. The request was understood
- Ask Developer Agent to summarise what it built, in plain language, and compare it with what you asked for.
- Check the users: who is meant to use it, and is that what was built?
- Check the scope: did it build anything you did not ask for?
Small misunderstandings at this stage are cheap to fix. They are expensive once data exists.
2. Every field and object is real
Generic AI is known for inventing plausible Workday field names; see the hallucinated field trap. Developer Agent is grounded in Workday's own tools, which reduces this, but verification is still yours.
- Every business object, field and data source the build reads actually exists in the target tenant, including the client's custom fields.
- References use the right ID types for the tenant.
- Workday's own validation passes. Read any findings; do not suppress them.
3. Data model changes are deliberate
Developer Agent can extend Workday with new business objects and business processes. These are the hardest changes to undo.
- Each new business object is needed, and an existing object or a custom field would not do. See custom business objects vs. custom fields.
- Field names and types are final, or you accept the cost of changing them later. See safeguarding irreversible data model changes.
- New business processes have the right steps, approvals and routing for the customer.
4. Security is the narrowest that works
- The security domains the app or agent uses are the minimum its job needs.
- Nothing grants unconstrained access where constrained access would do. See constrained vs. unconstrained security groups.
- A custom agent's tools are limited to its job, with actions that change data listed separately.
5. Actions that change data have a human in front of them
- Every action that changes a worker's record, pay, job or organisation, or creates a financial transaction, pauses for a person's approval in the first release.
- The approval message says, in plain language, what will happen and to whom.
- The agent's behaviour when Workday rejects something is to explain and stop, not retry.
6. External connections are approved
Developer Agent can build orchestrations across Workday and third-party systems.
- Every external system the build connects to is approved by the customer.
- Credentials are held in Workday's managed connection settings, not in code or descriptions.
- Retry and rate-limit behaviour is defined for each external call. See calling external APIs from Workday Orchestrate.
7. Names and descriptions read well to users
- Page titles, field labels, prompts and error messages are written for the people who will use them, not for developers.
- Names follow the customer's conventions, so the app does not look foreign in their tenant.
8. It has been tested by persona in Development
- Tested in a Development or other non-production tenant, never first in Production.
- Tested as the intended user, as someone with less access and as someone from another part of the organisation. See multi-persona testing.
- For a custom agent: the number of actions per request is recorded for the Flex Credits budget.
9. Ownership is recorded
- The agent appears in the Agent System of Record (Workday registers agents built with Developer Agent automatically) with the right owner.
- Someone has agreed to review its activity in the first weeks.
Where kiweely fits
kiweely is a desktop co-pilot that does much of this checklist as part of the build. It reads the connected tenant before proposing anything, so fields and objects are checked against what really exists. It runs Workday's own validation and reads the findings back, deploys to the Development environment and tests the result in the browser. It asks for your consent before every change to a tenant. It is designed for consultants who know Workday but do not write code, and runs on the ChatGPT or Claude account you connect.