Skip to content

Teaching the assistant to fill in ADP job applications (plain version)

Engineer version: ../technical/scraper-automation-learnings-adp.md

Some employers run their job applications on a system called ADP (ADP Workforce Now / ADP Recruiting). It's built differently from Workday, UKG, and Paycom (three other big ones), so we built a practice range to teach the assistant how to fill in ADP applications without ever touching a real one.

Everything here is a safe practice dummy

The practice range runs entirely on your own computer. There is no real ADP website, no real internet connection, and no real "submit" button that sends anything to an employer. It's a pretend copy of an ADP application that only exists on your machine.

No account is ever created, anywhere. Real ADP applications ask you to sign in or create a candidate account (ADP calls this a "myADP" account). Our practice copy has a pretend version of that screen, but "creating an account" there does nothing except move to the next pretend page — it never talks to any real website, so there is no actual myADP account sitting out there anywhere.

The most important rule: the assistant never actually submits. When it reaches the final "Submit Application" screen, it stops, writes down "I would submit here — but I won't," and starts over with a fresh pretend application. The submit button is wired to do nothing.

Why ADP needed a different trick than Workday, UKG, or Paycom

Think of filling in a form as finding each box by a label on the back of it.

  • On Workday, every box has a neat, permanent barcode sticker.
  • On UKG, there's no barcode, but nearly every box has a screen-reader tag that works almost as well.
  • On Paycom, there's no barcode and the screen-reader tags are hit-or-miss, but the box's plain id and name turned out to be dependable.
  • On ADP, the app is built with a particular web framework (Angular) that leaves its own kind of sticker: a formcontrolname tag that ties the box to the code behind the page. That tag turns out to be the most dependable one on ADP — more dependable than the box's own id, which on ADP is often auto-generated by the framework and can change between page loads.

So on ADP, the assistant flips its usual order: it looks for the framework's own tag first, then the box's id, then its name, then the printed label, then the screen-reader tag as a last resort. This is the opposite priority from Paycom, where the plain id came first — proof that each system needs its own strategy, not a copy-pasted one.

The tricky part: figuring out which page you're on

Just like Paycom, ADP applications sometimes put the optional demographic questions (gender, veteran status, disability — always optional, never required, called "Voluntary Disclosures" on ADP) on their own page, and sometimes tuck them onto the very last "review everything" page instead. Different employers set it up differently.

We already knew from building the Paycom practice range that this kind of "which page am I on" question is easy to get wrong — the review page and the dedicated question page can share the exact same "gender" box, which fools a naive check into thinking it's in the wrong place. So this time, we built the ADP assistant with that fix already baked in from the start: it checks for a box that only shows up on the dedicated question page (not the shared one), and it checks using both the box's id and its framework tag, so the pretend site can't trick it by hiding the id.

Because that lesson carried over cleanly, the ADP practice range ran clean the first time — no extra bugs needed to be found and fixed the way they were for Paycom. That's exactly the payoff of practicing on a fake, shifting copy of a form: fixes learned on one system's practice range transfer to the next one, as long as you check that the underlying trick is really the same shape.

Other ADP quirks the assistant learned to handle

  • "Upload your resume" screens. ADP pushes resume upload even harder than Paycom or UKG — it's the default path most of the time. The assistant instead clicks "Enter manually" and types the details in.
  • Custom questions with no fixed pattern. Every employer using ADP can add their own screening questions ("Additional Questions" — earliest start date, desired salary, willingness to relocate, or something else entirely). There's no way to know ahead of time which ones will show up, so the assistant looks for whichever ones are actually there each time, fills in the ones it recognizes from your profile, and simply moves on if there aren't any.
  • Slow-loading screens. ADP's app rebuilds parts of the page as you move through it (it's a full in-browser app, not just a series of separate pages), so some screens appear a beat late while the page finishes setting itself up. The assistant waits patiently for each screen to actually show up before trying to type.

One thing it deliberately does not guess

Just like with Workday, UKG, and Paycom, there's a tricky spot around your degree. Your profile says "Bachelor of Science" in one box and "Game Development" in another — but some ADP employers have a single box that wants them combined, like "B.S. in Game Development." Rather than guess the format, the assistant flags it as a judgement call and (in the real app) would pause to ask you, then remember your answer for next time.

What we ran

We ran 20 practice applications back to back. Every single one finished, every one stopped safely at the submit screen without submitting, and no account was ever created anywhere. The practice range kept score of which "ways to find a box" worked and which failed, confirming the framework's own tag (formcontrolname) really was the most reliable one to check first on ADP.

How to run a long practice session

If you want to leave it running to keep hardening the assistant:

dotnet run --project tools/WorkWingman.ScraperLab.Adp -- --minutes 60

It will keep running fresh pretend applications for an hour, logging what it learns — and never submitting anything, and never creating any account, ever.