Workday's public API covers HR data well. It doesn't cover the operational workflows your teams run every day. Here's how to automate those without Selenium breaking on every update.
Workday has a well-documented REST and SOAP API. For core HR data — employee records, org structure, compensation data, time-off balances — the API is comprehensive. If you're building an integration that reads or writes employee data, the official API is the right choice.
The problem starts when you need to automate workflows that go beyond data access. Approval chains, procurement requests, expense report processing, custom business process steps that your organization has configured — these are UI workflows that the API doesn't expose in a way that's useful for automation. You can read that an approval is pending; you can't easily trigger the approval programmatically through the official API without significant configuration work.
These are the workflows that operations teams run manually, every day, in the Workday UI. They're repetitive, time-consuming, and perfect candidates for automation — if the API supported them.
Workday's frontend is a single-page application built on their proprietary framework. It's dynamic, heavily JavaScript-dependent, and updates frequently. Element IDs change between releases. The application uses complex shadow DOM structures that Selenium and Playwright struggle to navigate reliably. Timing issues are common — the automation clicks before an element is fully interactive.
Workday also deploys updates on a twice-yearly major release cycle plus continuous minor updates. Each release is a potential breaking change for UI-based automation. Maintaining Selenium scripts across Workday releases is a significant ongoing engineering burden.
Workday's UI communicates with its backend through a consistent set of HTTP requests. Those requests use Workday's internal API — not the public API, but the same endpoints the browser calls. These are stable in ways the UI is not: they're tied to Workday's data model and business process engine, not its frontend design.
By capturing and replaying those requests, you can automate Workday workflows that have no official API support. The automation sends the same requests the browser would send, with the same authentication tokens and session state, and Workday's backend processes them identically.
Almost every enterprise Workday deployment runs behind SSO — typically Okta, Azure AD, or PingFederate. The login flow involves SAML or OIDC redirects, token exchanges, and often MFA. You can't replicate this flow programmatically without essentially re-implementing your company's identity provider.
The practical solution: a user authenticates through their normal browser, the session is captured, and subsequent automated calls reuse that session. No passwords stored, no MFA bypassed, no service accounts. When the session expires, the user authenticates once more. Each team member's automation runs under their own Workday session, maintaining the audit trail your compliance team requires.
The fastest path to automating a Workday workflow: describe the business process — what you're doing in the UI today, step by step — and we'll map the underlying request chain. Most Workday operational workflows can be live within a week of that mapping work.
Tell us the business process. We'll tell you how long it takes to build.
Book a scoping call