Making Workday Changes That Have No API: How to Check, and What to Do Instead

Before you automate a Workday change, search Workday's public SOAP API explorer and REST API explorer for an operation that makes it. If one exists, use it. If none does, the change has to go through the task screen a person would use: by hand, with a recorded click script, or with an AI agent that works the screen under your own sign-in and reads the saved result back.

How to check whether a Workday change has an API

Workday publishes both of its main web service families:

• SOAP APIs, also called Workday Web Services. Workday describes them as "the foundation for enterprise-level, system-to-system integrations and large-scale data exchanges", suited to scheduled, batch-based work. The SOAP API explorer groups them by functional area, such as Absence Management, Benefits Administration and Compensation, and has a search box.
• REST APIs, which Workday describes as the data providers "for low-latency, self-service transactions". The REST API explorer lists them.

Search for the business object you want to change and read what each operation does. An operation that only returns data won't make the change. If you find one that does, you will also need an integration system user and an API client with the right security to call it; the ISU and API client guide walks through that.

Inside a Workday Extend app, Workday's own guidance sets an order for writing data: Graph API mutations first, then the Workday REST APIs, then "synchronous Workday SOAP web services through orchestrations". Workday also warns that Extend apps are meant for human, low-volume use and should not import or export large quantities of data.

When there is no operation, the task screen is the way in

Every configuration change a person makes in Workday runs through a task: a screen with fields, a Save or Submit button, and sometimes errors or warnings to answer before Workday accepts it. With no web service for the change, there are three ways to get it done.

By hand

Open the task, fill it in, submit, and check the result. It is the safest option for a handful of changes in one tenant, because you see every field and every warning. It doesn't scale: the same change across five tenants, or for forty records, is an afternoon of repetitive clicking where a typo is easy to miss.

A recorded click script

Browser test tools can record a session and replay it. That suits regression testing, where you want the same clicks every time. As a way to make changes, it has two weaknesses:

• A script replays the screen it was recorded against. Workday applies a Weekly Service Update, and when a task's screen changes, a script recorded against the old one needs re-recording.
• A script that runs unattended needs a stored sign-in, and someone has to decide whose access it uses and where that sign-in is kept.

An AI agent that works the screen

An AI agent can read the task, decide what each field needs, enter it, and handle the warning that a script would not expect. Before letting one change a tenant, insist on four things:

1. It signs in as you. Workday security then limits it to what your own account can do, and the change is recorded under your name, like any change you make.
2. It shows you the change before saving. You should see the tenant and the exact change, and nothing should be saved until you approve it.
3. It reads the result back. A screen that looks finished is not proof. The agent should open the saved record, or read Workday's confirmation, and compare it with what was intended.
4. You can watch it and stop it. The work should happen in a browser you can see.

kiweely, an AI agent for Workday, works this way and lets you choose how it enters a change. On screen: you watch each step happen in the browser, which is slower. Straight in: the change is entered straight into Workday, which is faster on tasks it has done before; each step is listed in the conversation, and the saved result opens in the browser when it's done. Either way, every change waits for your approval on a card that names the tenant and the change.

Check that the change really saved

Whichever way the change is made:

• Open the saved record and compare each value with what you intended.
• For an effective-dated change, check the effective date as well as the values.
• If the change affects what people see or can do, test it as one of them. In a non-production tenant, the Start Proxy task lets you act on someone's behalf; the multi-persona testing guide covers how.

Which method to use