Workday's hidden field types and how to actually fill them

If you've ever watched an autofill extension confidently type the right answer into the wrong Workday field, you've seen the problem this post is about. Workday isn't HTML; it's a rendered tree of widget IDs, and the easy way to fill it is wrong.

What “tenant” means in Workday

Each Workday customer (Salesforce, Walmart, NVIDIA, your local bank) runs in a separate tenant. Tenants configure their own field set, their own validators, their own dropdowns. The field labelled “Phone Number” on Salesforce's tenant takes a different format than on Walmart's. There's no standard schema you can target.

This is why a generic LazyApply-style filler succeeds on the first three Workday tenants you try, then fails on the fourth. The field labels look identical. The underlying widgets aren't.

The eight widgets we resolve

After about 800 distinct Workday applications, the same eight widget types account for 95% of the surface area:

1. Plain text input. The easy one. The catch: server-side validators check format (phone, ZIP, email) and quietly reject submission without flagging the field. Always normalise before typing.
2. Date picker. Three sub-types. Some accept typed dates (MM/DD/YYYY). Some require clicking through a calendar widget. Some are masked inputs that reject anything but digits-as-typed. Detect by probing for the calendar button before typing.
3. Searchable dropdown (PromptSelect).The widget that breaks 80% of naive fillers. You can't set the value; you must type into it, wait for the async menu to render, and click the matching option. Fail mode: typing “California” matches “California” AND “Lower California Sur” — pick the wrong one and the form silently saves both your visible text and an unrelated internal ID.
4. Multi-select with chips.Used for skills, languages, and “how did you hear about us.” Each addition triggers a re-render. Don't batch — drive one at a time and wait for the chip to materialise before moving on.
5. File upload. Looks like a button. Actually a hidden <input type="file"> two DOM levels above where you think it is. After upload, Workday parses the résumé and pre-fills downstream fields — frequently with garbage. Always re-verify the next page.
6. Yes/No radio with conditional reveal.“Are you legally authorised to work in the US?” — clicking yes reveals nothing; clicking no reveals a sponsorship-status sub-form. If you fill in the wrong order, fields you can't see fail validation.
7. Free-text question.“Why do you want to work here?” Workday gives you 4000 characters and a panic attack. Most tenants don't actually validate length, but some do. Ask for the maxLength attribute on the textarea before generating an answer.
8. Disclosure / EEO panel.Race, gender, veteran status, disability — federal-compliance fields. They come last and they're skippable. Most fillers handle them poorly because the labels are unusual. Default to “decline to self-identify” unless the user has explicitly stored a preferred answer.

The invariants that hold across all tenants

Three things stay constant no matter the tenant:

• Section navigation is sequential.You can't jump to page 4 without satisfying page 3's validators. Filling has to be ordered.
• Server-side validation can lie. A field can show no error and still be invalid; the error surfaces on the next-section button click. Always verify post-click that the page actually advanced.
• The session can expire. A 30-minute fill is a real risk on a long Workday application. Periodically poll a benign endpoint to keep the session alive.

How we resolve fields

Our approach is two-tier. First pass: a deterministic resolver matches widget structure (DOM shape, ARIA attributes, label text) to known patterns. Second pass: if the deterministic pass returns “unknown widget,” we ask an LLM to classify it from a snapshot of the surrounding DOM and the visible label. The LLM never picks the value — it only picks the widget category, which is a closed set of about 12 categories. Then a deterministic typed handler does the actual fill.

The reason for the split: LLMs are bad at consistent low-level fill (typing speed, key sequencing, async waits). They're good at fuzzy classification. Use each for what it's good at.

What still goes wrong

Honestly, two things. International phone-number formatting is a nightmare — different tenants want +1-555-555-5555, (555) 555-5555, or 5555555555, and the regex is rarely surfaced. We have a fallback that retries with three formats and picks the one that doesn't error. And the “import from LinkedIn” widget some tenants embed: it pre-fills with stale data, our overwrite is partial, and the user ends up with a Frankenstein form. We disable it and warn the user when we see it.

If you're building anything that touches Workday: read the source of truth (the Workday-Common JavaScript that ships with the page) before you write a single CSS selector. The widget IDs are documented. Treat selectors as last-resort.