Using Involve Resume

Autofill, Step by Step: What Gets Filled and What Does Not

What happens between pressing fill and reading the result: the fields that get answered, the ones left for you, and where the tailored CV comes from.

Autofill means one specific thing here: the form is opened, your resume is tailored to that posting, the fields are filled to the last one the form will accept, and then it stops. The tab stays open. You read it and you press send.

This post is the mechanics of that, in order.

Two ways to start it

They run the same engine. There used to be two, and the older one drifted until it could not read half of what the queue could, so the button now runs the queue's engine with three options turned on: never overwrite what you typed, outline what it did on the page, and offer back the answers you write yourself.

The sequence, for one page

1. You open the employer's form and press the button.
2. Chrome is asked for permission for that one site, as the first statement inside the click. Without a gesture the question cannot be asked at all.
3. The background worker re-checks your plan against the server. The popup already drew an answer, but that was a drawing of the answer and this is the answer.
4. Your data is injected into an isolated world of its own, so the page cannot read it from a global and the filler cannot be tricked into using the page's data instead.
5. The stylesheet goes in, then the engine.
6. The engine reads the form, fills it, and reports back.

The result line says three numbers: fields filled, fields left blank on purpose, and fields for you to answer. The detail list underneath names the first few of each.

How a field is recognised

In order, and the order matters:

1. The autocomplete attribute. That is the page author telling machines what the field is, and where it exists it beats every guess below it.
2. The visible label, then aria-label, aria-labelledby, the placeholder, name, id and data-testid, read the way a person reads a form.

Selects and radio buttons are matched on their option text rather than typed into. A radio group is read from its fieldset legend, not from whichever option the walk happened to reach first.

The patterns are anchored more tightly than you might expect, and there is a reason. An unanchored pattern for "tel" once matched the word inside "Tell us about the largest team you have run", so a telephone number was typed into a screener answer box and recorded as filled, which meant the question never reached anybody. That class of error is worse than a blank field, because a blank field is visible.

What gets filled

The material comes from the resume you already parsed and from answers you have typed on earlier forms. Answers you write are remembered and offered on the next form, so each one is shorter than the last.

What is deliberately left for you

This list is shorter to read and more important than the one above.

• Work authorisation, visa and sponsorship, citizenship, security clearance. Never inferred. If you have answered one before, the previous answer is replayed only with a red outline and a note telling you to check it.
• Disability, veteran status, ethnicity, race, gender, pronouns, date of birth. Same rule.
• Consent boxes. The privacy notice, the terms, the confirmation that the above is accurate. Those are a statement by you, not a fact about you, and the toolbar button never ticks one.
• Any field you have already typed in. It is left exactly as you wrote it.
• Any required field with no answer. Left blank and marked with an amber note, because a silently wrong answer is worse than a visible gap.

There is one detail in the identity questions worth stating. An earlier version of the option matcher treated the phrase "I do not have a disability" as a refusal to answer, because it starts with a negation. That is not a refusal, it is an answer, and ticking it declared something about somebody's health in their own name. The matcher is now anchored on the verb of refusal, so an option that merely contains the word "not" cannot be mistaken for one. If no option matches, none is ticked and the question is reported as a gap.

What happens to the tab

It stays open.

On the queue, a tab is closed only on a confirmed send, and at no other time. Every other outcome, including every failure, leaves the tab exactly where it stopped, because the half-filled form is the thing you would need in order to finish the application by hand.

The run log records what actually happened rather than what was attempted. These are the statuses you will see most:

Those last three used to read as "sent", because the runner recorded a submission the moment it clicked. They are now reported as themselves.

Where the tailored CV comes from

Not from one master file, and not from a fresh document per job.

One resume is built per kind of role, from the single document you approved, reordered against what that kind of role asks for. The queue picks the variant using the key the app computed when the job was queued, because the app had the whole index row and the extension has four fields and a link.

Then two questions are settled before anything is written:

1. Is there an approved copy for this exact posting? If you have opened that job, read the document and pressed approve, that copy is a candidate. Both documents are then measured against the posting with the same classifier the screens use, and whichever matches more of the posting's keywords is the one that goes. Ties go to your approved copy, because a tie means the rebuild gained no ground. The run log names both numbers.
2. Is the design safe to upload? A two-column layout has its columns read out of order by a parser, so the sidebar design is swapped for a plain one on this route only, and the log says it happened. Your own downloads keep whatever you chose.

After that the document is cut to the page count you asked for using the same ladder the app uses: trim bullets, never below two on a role, then demote the oldest non-current role into other experience, then trim again, and stop the moment it fits. No role is deleted outright, because a missing role leaves a gap in the dates.

Finally the file is read the way an upload form will read it, on the exact object about to become bytes, and the run log carries that check. A run that says the application was sent and not that the file failed its own parser check is a run log hiding the one failure you could still act on.

The attachment, and the limit nobody can engineer away

Browsers forbid a script from attaching a file to an upload field. That is a real security boundary and no part of Involve tries to get around it.

So the files are produced once and used twice. They are staged into your Downloads folder unconditionally, and the same bytes are carried into the page so the engine can try the attach where the board allows it. Where the attach is refused, the file is already sitting in the folder the picker opens on, the report says which file is missing, and the run refuses to submit. A form that wants a CV and has an empty CV box is not an application.

Fill one form, read the result line, and check the two or three fields it flagged. Start at the apply queue.